Re: static array with inferred size

[Andrei Alexandrescu via Digitalmars-d]

On 9/19/17 8:47 PM, Steven Schveighoffer wrote:

This needs to happen.

e.g.:

char[$] arr = "hello"; // syntax up for debate, but I like this.

I can't think of a correct way to do this that doesn't heap-allocate and 
is DRY.


D is so powerful, it's a huge shame it can't figure this one out.

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

Fix that was merged: https://github.com/dlang/dmd/pull/3615

And then reverted: https://github.com/dlang/dmd/pull/4373

Maybe there was an issue with the implementation? Can it be redone?

-Steve


The argument was it can be done trivially with a library solution. -- Andrei

Re: D for Android

[Andrei Alexandrescu via Digitalmars-d]

On 9/18/17 11:25 PM, Joakim wrote:
Almost four years ago, I asked where Android was at, in this thread 
about supporting ARM, and decided to take up the port:


http://forum.dlang.org/thread/yhulkqvlwnxjklnog...@forum.dlang.org

After releasing linux/x64 cross-compilers for the last couple years, I 
finally got all my patches upstream and ldc 1.4 is the first official 
release to fully support cross-compiling for Android/ARM from linux, 
Windows, and hopefully macOS:


https://github.com/ldc-developers/ldc/releases/tag/v1.4.0

As noted there, I've written up full instructions on using the official 
release to write D apps for Android, employing the simple OpenGLES C/C++ 
sample apps that used to come with the NDK but ported to D, including 
demonstrating calling Java methods through JNI:


https://wiki.dlang.org/Build_D_for_Android

If someone can try it out on a mac and either update that wiki page with 
the required brew/port steps and any other mac-isms or post them here, 
we can make it easier for mac users too.


Next up, 32-bit ARM Android devices are now supported, I'm looking at 
getting 64-bit AArch64 Android up and running.


Congratulations, that's terrific news! -- Andrei

mysqln - tagged bugfix release v1.1.1

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

https://github.com/mysql-d/mysql-native

Native D client driver for MySQL/MariaDB, works with or without Vibe.d

Tagged bugfix release v1.1.1:

- Fixed: #116: Prevent segfault on copying ResultRange. (@schveiguy)
- Fixed: #120: Fix typos / grammars in documentation (@Marenz)
- Fixed: #124: Fix deprecations: Change deprecated std.string.munch to 
std.algorithm.skipOver. (@Kozzi11)

Re: What the hell is wrong with D?

[nkm1 via Digitalmars-d-learn]

On Wednesday, 20 September 2017 at 02:16:16 UTC, EntangledQuanta 
wrote:
Your an idiot, I know about how operator precedence works far 
more than you do. Wanna bet? how much? Your house? your wife? 
Your life? It's about doing things correctly, you seem to fail 
to understand, not your fault, can't expect a turd to 
understand logic.


Ok, you win. I see now that you're very smart :)

Re: D std.regex is so slow

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 19 September 2017 at 19:52:57 UTC, Daniel Kozak wrote:

Is there a plan to make BitNFA back?


Yes, the moment we have CTFE that doesn't leak.


Is possible that newCTFE will improve problem with memory?


It should but it doesn't support classes and exceptions. I need 
them.



Or it is possible to improve those slow cases?


There are many other things but BitNFA is a nobrainer - all the 
work has been already done and it is super fast where applicable.


---
Dmitry Olshansky

Re: What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

On Wednesday, 20 September 2017 at 02:57:21 UTC, jmh530 wrote:
On Wednesday, 20 September 2017 at 02:36:50 UTC, Jonathan M 
Davis wrote:


Please try to be civil. It's fine if you're unhappy about some 
aspect of how D works and want to discuss it, but we do not 
condone personal attacks here.


- Jonathan M Davis


He seemed to be threatening the guy's life over operator 
precedence. Ridiculous...


Are you an idiot? Seriously, you must be. You just want to create 
drama instead of supply an actual logical argument(which I read 
your argument and it is pathetic). Show me where I threatened the 
guys life! Fucking moron. You must be some TSA goon or DHS 
wannabe.

Re: How to list all process directories under /proc/

[Ky-Anh Huynh via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 18:32:06 UTC, Matt Jones wrote:
On Tuesday, 19 September 2017 at 13:32:29 UTC, Ky-Anh Huynh 
wrote:




Btw, is that a bit weird that range is not supported in glob 
pattern :) Is there a design reason for this?


That is strange. But then again, every glob library I've seen 
works a little bit differently.


I see. Maybe I'm using Linux and Ruby too much. Missing character 
range doesn't really hurt, but the feature should be documented. 
Should we improve the documentation? To be fair, the syntax 
specification is clear after I read it twice, but the link to 
Wiki page is confusing, because Wiki page mentions the popular 
(FIXME) implementation with character range.

Re: What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

On Wednesday, 20 September 2017 at 02:36:50 UTC, Jonathan M Davis 
wrote:
On Wednesday, September 20, 2017 02:16:16 EntangledQuanta via 
Digitalmars-d- learn wrote:

On Tuesday, 19 September 2017 at 21:17:53 UTC, nkm1 wrote:
> On Tuesday, 19 September 2017 at 17:40:20 UTC, 
> EntangledQuanta

>
> wrote:
>> [...]
>
> There are two issues there; operator precedence and booleans
> (_win[0] == '@') being a valid operands to +.
> If someone is too stupid to learn how precedence works, they
> should consider a different career instead of blaming others.
> OTOH, booleans converting to numbers is a very questionable
> feature. I certainly have never seen any good use for it. 
> This

> is just an unfortunate legacy of C, which didn't even have
> booleans for a long time.

Your an idiot, I know about how operator precedence works far 
more than you do. Wanna bet? how much? Your house? your wife? 
Your life? It's about doing things correctly, you seem to fail 
to understand, not your fault, can't expect a turd to 
understand logic.


Please try to be civil. It's fine if you're unhappy about some 
aspect of how D works and want to discuss it, but we do not 
condone personal attacks here.


- Jonathan M Davis



But, of course, It's ok for him to come me an idiot. Let me 
quote, not that it matters, since you are biased and a hypocrite:


">> > If someone is too stupid to learn how precedence works, they
> should consider a different career instead of blaming 
> others."


But when I call him an idiot, I'm put in the corner.

I see how it works around here. What a cult!

Re: static array with inferred size

[Steven Schveighoffer via Digitalmars-d]

On 9/19/17 10:46 PM, Meta wrote:
With all due respect to Andrei, I think he overreacted a bit and it was 
a mistake to revert static array length deduction (although the array/aa 
type deduction on steroids was probably overly complicated so that was a 
good call). Maybe now that @nogc and betterC are squarely in focus we 
can revisit array length deduction.


The length deduction is so obviously needed, especially when you want to 
avoid heap allocations.


char["hello".length] = "hello";

It's just so terrible. I can't figure out a good way around it.

Deducing types is probably reasonable as a request, but I don't see how 
one requires the other. There is no need to repeat the entire literal to 
form the type, and you aren't specifying the type anyway. At most you 
have to enter the type one more time (in the case of explictly typing an 
element).


But having to manually count all the elements in an array literal? That 
is torture! D should be better than that.


-Steve

Re: static array with inferred size

[jmh530 via Digitalmars-d]

On Wednesday, 20 September 2017 at 02:46:53 UTC, Meta wrote:


[snip]


I also favor making arr[..] equivalent to arr[0..$] and allowing 
overloading of \ (for inverse, similar syntax as Matlab).

Re: What the hell is wrong with D?

[jmh530 via Digitalmars-d-learn]

On Wednesday, 20 September 2017 at 02:36:50 UTC, Jonathan M Davis 
wrote:


Please try to be civil. It's fine if you're unhappy about some 
aspect of how D works and want to discuss it, but we do not 
condone personal attacks here.


- Jonathan M Davis


He seemed to be threatening the guy's life over operator 
precedence. Ridiculous...

Re: What the hell is wrong with D?

[B4s1L3 via Digitalmars-d-learn]

On Wednesday, 20 September 2017 at 02:16:16 UTC, EntangledQuanta 
wrote:
Your an idiot, I know about how operator precedence works far 
more than you do. Wanna bet? how much? Your house? your wife? 
Your life? It's about doing things correctly, you seem to fail 
to understand, not your fault, can't expect a turd to 
understand logic.


You should swallow your ego a bit. In first place you've made an 
error. Just recognize this error, it's not so serious finally. 
You are discrediting yourself for nothing.

Re: static array with inferred size

[Meta via Digitalmars-d]

On Wednesday, 20 September 2017 at 01:29:39 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 19, 2017 20:47:25 Steven Schveighoffer 
via Digitalmars-d wrote:

This needs to happen.

e.g.:

char[$] arr = "hello"; // syntax up for debate, but I like 
this.


I can't think of a correct way to do this that doesn't 
heap-allocate and is DRY.


D is so powerful, it's a huge shame it can't figure this one 
out.


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

Fix that was merged: https://github.com/dlang/dmd/pull/3615

And then reverted: https://github.com/dlang/dmd/pull/4373

Maybe there was an issue with the implementation? Can it be 
redone?


All in all, I think that it would be cleanest if this were just 
implemented in the language. I recall there being discussions 
about adding it with the syntax you showed, and on reflection, 
I _think_ that I recall Walter objecting to it for some reason, 
which is why it was reverted, but I don't remember the details 
at all at this point, so I could easily be remembering 
incorrectly.


That was the main reason it was reverted. A contributing factor 
is that Beadophile had been trying to push this feature for a 
long time, and once it got in (against W's reservations, 
although they eventually gave the okay) he started pushing harder 
for the []s syntax for static array literals, arguing that now 
that we had static array length deduction syntax we needed static 
array literal syntax as well. This was the straw that broke the 
camel's back for Andrei and he decided to revert the length 
deduction PR citing concerns over feature bloat. There was also 
other functionality tied up with the deduction syntax - see this 
post: 
https://forum.dlang.org/post/wagryggxehnbsbyhw...@forum.dlang.org


With all due respect to Andrei, I think he overreacted a bit and 
it was a mistake to revert static array length deduction 
(although the array/aa type deduction on steroids was probably 
overly complicated so that was a good call). Maybe now that @nogc 
and betterC are squarely in focus we can revisit array length 
deduction.

Re: Specifying @nogc on structs seems to have no effect

[B4s1L3 via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
I've recently tried coding in D again after some years.  One of 
my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.  
So I want guarantees that certain sections of code and certain 
structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc 
and free and emplace, but I find it troubling that you still 
need to tell the GC to scan your allocation. What I would like 
is, for example, to be able to write a @nogc templated struct 
that guarantees that none of its members require GC scanning.  
Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}


I've implemented data annotation in iz, if you want to take a 
look.

It's quite near from what you descibed in a more recent answer:


/+ dub.sdl:
   name "dub_script"
   dependency "iz" version="0.6.0"
+/
module dub_script;

import iz.memory;

// defines a class that has a member
// which is usually handled by the GC
class Foo {void* looks_gc_managed;}
// defines a class and marks member as nogc-"trusted"
class Bar {@NoGc Foo foo;}
// defines a class without annotation
class Baz {Foo foo;}

// verified statically
static assert(!MustAddGcRange!Bar);
static assert( MustAddGcRange!Baz);

void main(string[] args)
{
Foo foo = construct!Foo;
destruct(foo);
}


It's another way of doing things. It's less strict than checking 
all the functions.


note: the script can be run directly by passing the file to DUB 
(single file package).

Re: What the hell is wrong with D?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, September 20, 2017 02:16:16 EntangledQuanta via Digitalmars-d-
learn wrote:
> On Tuesday, 19 September 2017 at 21:17:53 UTC, nkm1 wrote:
> > On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta
> >
> > wrote:
> >> Yeah, that is really logical! No wonder D sucks and has so
> >> many bugs! Always wants me to be explicit about the stuff it
> >> won't figure out but it implicitly does stuff that makes no
> >> sense. The whole point of the parenthesis is to inform the
> >> compiler about the expression to use. Not use everything to
> >> the left of ?.
> >
> > There are two issues there; operator precedence and booleans
> > (_win[0] == '@') being a valid operands to +.
> > If someone is too stupid to learn how precedence works, they
> > should consider a different career instead of blaming others.
> > OTOH, booleans converting to numbers is a very questionable
> > feature. I certainly have never seen any good use for it. This
> > is just an unfortunate legacy of C, which didn't even have
> > booleans for a long time.
>
> Your an idiot, I know about how operator precedence works far
> more than you do. Wanna bet? how much? Your house? your wife?
> Your life? It's about doing things correctly, you seem to fail to
> understand, not your fault, can't expect a turd to understand
> logic.

Please try to be civil. It's fine if you're unhappy about some aspect of how
D works and want to discuss it, but we do not condone personal attacks here.

- Jonathan M Davis

Re: What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 22:11:44 UTC, Jesse Phillips 
wrote:
On Tuesday, 19 September 2017 at 19:16:05 UTC, EntangledQuanta 
wrote:
The D community preaches all this safety shit but when it 
comes down to it they don't seem to really care(look at the 
other responses like like "Hey, C does it" or "Hey, look up 
the operator precedence"... as if those responses are 
meaningful).



jmh530 points out why you're met with such non-agreement of the 
issue. You're not open do discussion of why it is implemented 
in the fashion it is. Instead it is an attack on the community 
and Walter as though there is no logical reason it is 
implemented in the way that it is.


I'm not open to discussion because it is not a discussion. There 
is no point. What could would it do to explain the short 
commings? You see the responses, the mentality. People think 
doing something wrong is valid because it was done. Two wrongs 
don't make a right no matter how you justify it. When someone 
takes on the task of doing a job and pretends the results to a 
community then refuse to accept responsibility for the failure to 
do the job properly and perpetuate ignorance(invalid logic that 
creates confusing, wastes peoples times, etc) then they deserve 
to be criticized, it's a two way street. When they then make up 
excuses to try to justify the wrong and turn it in to a right, 
they deserved to be attacked. It not just a harmless mistake. 
Peoples lives could be a jeopardy, but do they care? Do they 
REALLY care? Of course not. They don't see it as a significant 
issue. Simply learn how D works exactly and you'll be fine! Of 
course, for someone that programs in about 20 different languages 
regularly, having logical consistency is important.


It's one thing to say "Well, I made a mistake, lets try to remedy 
it the best we can" than to say "Well, too bad, we can't break 
backwards compatibility!". People want to perpetuate 
insanity(which is what being illogical is).



Sure you can express that it is illogical to have made that 
choice, but that requires first know what used to make that 
decision.


No, it doesn't logic is not based on circumstances, it's based on 
something that is completely independent of us... which is why it 
is called logic... because it is something we can all agree on 
regardless of our circumstances or environment... it is what math 
and hence all science is based on and is the only real thing that 
has made steady progress in the world. Illogic is what all the 
insanity is based on... what wars are from, and just about 
everything else, when you actually spend the time to think about 
it, which most people don't.



For example one of the original principles for D was:
If it looks like C it should have the same semantics or be a 
compiler error (note this was not completely achieved)


Now if we look at other languages we see, they implement it the 
same as C or they don't implement it at all. Just based on this 
it would make sense to choose to implement it like C if it is 
desired to have.


The suggestion I made fulfills this, but it also slightly 
defeats one purpose of the operator, being terse.


We also now need to keep backwards compatibility, this fails.


Again, two wrongs don't make a right. What is the point of 
reimplementing C exactly as C is done? There is already a C, why 
have two? Was the whole point of D not to improve upon C? Doesn't 
D claim to be a "better C"? So, if you are claiming that the 
choice for the ternary operator's issue of ambiguity was to be 
consistent with C then that directly contradicts the statements 
that D is suppose to be safer and better. I'm fine with this AS 
long as it is clearly stated as such and people don't try to 
justify or pretend that it is a good thing, which is exactly the 
opposite of what they. Most are followers of the cult and cannot 
make any rational decision on their own but simply parrot the 
elders. So, when they do that, I have no desire or reason to be 
logical with them(again, it takes two to tango).


For example, you have been rational, so I will be rational with 
you. To be rational, you must argue logically which you have 
done. Even though you haven't really argued the issue(of course, 
I didn't state it clear on purpose because this isn't really a 
discussion thread... I knew that the trolls/cult members would 
spew there stupid shit so I was just trolling them. Of course, I 
always hope that there would be some light in the tunnel, which 
you provided a glimmer... still all meaningless, nothing will 
change, at least not with the cult members, but someone that is 
not so brainwashed might be semi-enlightened if they implement 
their own language and not make the same mistakes).


e.g., my attack is on the claims that D attempts to be *safe* and 
a *better C* and yet this(the ternary if) is just another 
instance of them contradicting themselves. Presenting something 
as safer when it is not gives the perception of 

Re: Andrei Alexandrescu - i am proud

[useroruser via Digitalmars-d-announce]

On Tuesday, 19 September 2017 at 22:54:32 UTC, roman wrote:

I am absolutely proud of your government:

http://madworldnews.com/illegal-muslim-shore-coast-guard/

they keep the ...


lol, he's an US citizen [1] :slap:

[1] 
https://www.reddit.com/r/pics/comments/2di6ik/sixteen_years_ago_at_28_i_landed_in_new_york_with/

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 20:57:17 UTC, Neia Neutuladh 
wrote:
On Tuesday, 19 September 2017 at 15:11:31 UTC, Craig Black 
wrote:

[...]


You want to ensure that it can never refer to GC memory. The 
type system does not contain that information. It doesn't say 
whether an object was allocated on the GC heap, on the stack, 
using malloc, using a whole page of memory with mmap, using 
hardware addresses directly on an embedded system with manually 
planned memory layout, using a well-known address range like 
VGA, as part of the binary's static data segment...


[...]


Thank you for the information. I hadn't thought of using 
templates like that.  That might accomplish what I'm trying to 
do.  Much appreciated!


-Craig

Re: A potential danger to dub

[solidstate1991 via Digitalmars-d]

On Saturday, 16 September 2017 at 17:09:34 UTC, David Gileadi 
wrote:
Let me preface this by saying I love package managers and think 
dub is one of the best things with dlang. However they can also 
sometimes be dangerous, as this PyPI incident[1] shows: several 
Python packages were uploaded that contained names similar to 
the standard library, and had an extra semi-malicious payload. 
They are apparently now part of live software.


You could of course expect developers to do due diligence with 
the things they download, but of course they don't. It's 
probably worth paying attention to what the PyPI devs do to 
help mitigate this, and perhaps repeat some of those things 
with dub.


[1] 
https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/


We have the strength of being a mostly unknown language, but it 
still sounds scary.


I usually download all the stuff, and only use dub to compile the 
libraries, then mostly rely on the IDE's build system, and wrote 
a PowerShell script to recompile the libraries I use in case if I 
update the compiler.

Re: What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 21:17:53 UTC, nkm1 wrote:
On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:
Yeah, that is really logical! No wonder D sucks and has so 
many bugs! Always wants me to be explicit about the stuff it 
won't figure out but it implicitly does stuff that makes no 
sense. The whole point of the parenthesis is to inform the 
compiler about the expression to use. Not use everything to 
the left of ?.


There are two issues there; operator precedence and booleans 
(_win[0] == '@') being a valid operands to +.
If someone is too stupid to learn how precedence works, they 
should consider a different career instead of blaming others.
OTOH, booleans converting to numbers is a very questionable 
feature. I certainly have never seen any good use for it. This 
is just an unfortunate legacy of C, which didn't even have 
booleans for a long time.


Your an idiot, I know about how operator precedence works far 
more than you do. Wanna bet? how much? Your house? your wife? 
Your life? It's about doing things correctly, you seem to fail to 
understand, not your fault, can't expect a turd to understand 
logic.

[Issue 17842] [scope] array append allows for escaping references

[d-bugmail--- via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 17842] New: [scope] array append allows for escaping references

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17842
   Summary: [scope] array append allows for escaping references
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Reported by Mathias Lang:

void main () @safe
{
Object o = test();
assert(o !is null);
}

Object test() @safe
{
scope Object obj = new Object;
scope Object[] arr;
arr ~= obj;
Object[] array;
array ~= arr;// should be an error
return array[0];
}

--

Re: What the hell is wrong with D?

[rikki cattermole via Digitalmars-d-learn]

On 19/09/2017 9:22 PM, Neia Neutuladh wrote:

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta wrote:


writeln(x + ((_win[0] == '@') ? w/2 : 0));
writeln(x + (_win[0] == '@') ? w/2 : 0);

The first returns x + w/2 and the second returns w/2!


Yeah, it sucks to have bugs like this crop up. I have enough trouble 
remembering operator precedence, so I end up using parentheses 
everywhere and pretending the ternary operator doesn't exist. I also 
tend to break up complex expressions a lot. It's just safer, and usually 
clearer.


Agreed, no surprises is the best surprise!

Re: static array with inferred size

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 19, 2017 20:47:25 Steven Schveighoffer via 
Digitalmars-d wrote:
> This needs to happen.
>
> e.g.:
>
> char[$] arr = "hello"; // syntax up for debate, but I like this.
>
> I can't think of a correct way to do this that doesn't heap-allocate and
> is DRY.
>
> D is so powerful, it's a huge shame it can't figure this one out.
>
> issue: https://issues.dlang.org/show_bug.cgi?id=481
>
> Fix that was merged: https://github.com/dlang/dmd/pull/3615
>
> And then reverted: https://github.com/dlang/dmd/pull/4373
>
> Maybe there was an issue with the implementation? Can it be redone?

There have been previous attempts to implement this as a library solution.
IIRC, I was able to come up with a solution that would have been equivalent,
but I hit this issue with the compiler that prevented it:

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

My solution would work so long as you gave up on VRP, and there are other
solutions which work in some cases but not all (e.g. requiring that all of
the elements of the array be known at compile time and thus disallowing
stuff like [42, a, 7, 9, b] where a and b are variables). I'm not aware of
any library solution which would infer the size that would have the full
functionality that you can get now when initializing a static array without
trying to infer the size.

All in all, I think that it would be cleanest if this were just implemented
in the language. I recall there being discussions about adding it with the
syntax you showed, and on reflection, I _think_ that I recall Walter
objecting to it for some reason, which is why it was reverted, but I don't
remember the details at all at this point, so I could easily be remembering
incorrectly.

Regardless, if we want the full functionality, we need improvements to the
compiler/language - be it implementing my enhancement request with regards
to VRP so that a library solution could work and/or by actually adding the
static array size inference feature to the language itself.

- Jonathan M Davis

static array with inferred size

[Steven Schveighoffer via Digitalmars-d]

This needs to happen.

e.g.:

char[$] arr = "hello"; // syntax up for debate, but I like this.

I can't think of a correct way to do this that doesn't heap-allocate and 
is DRY.


D is so powerful, it's a huge shame it can't figure this one out.

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

Fix that was merged: https://github.com/dlang/dmd/pull/3615

And then reverted: https://github.com/dlang/dmd/pull/4373

Maybe there was an issue with the implementation? Can it be redone?

-Steve

Re: floating point value rounded to 6digits

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 8:04 PM, Jonathan M Davis wrote:

On Tuesday, September 19, 2017 19:35:15 Steven Schveighoffer via
Digitalmars-d-learn wrote:

On 9/19/17 7:28 PM, Ivan Kazmenko wrote:

On Tuesday, 19 September 2017 at 22:44:06 UTC, greatsam4sure wrote:

On Tuesday, 19 September 2017 at 21:52:57 UTC, Ivan Kazmenko wrote:

On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure wrote:

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write or
format. How do I change this default


The default when printing floating-point numbers is to show six most
significant digits.
You can specify the formatting manually with writefln, for example,

 writefln ("%.10f", value);

will print the value with 10 digits after the decimal point.
The writef/writefln function behaves much like printf in C.

See here for a reference on format strings:
https://dlang.org/library/std/format/formatted_write.html#format-strin
g

Ivan Kazmenko.


I don't  want to use write,writefln or format. I just want to change
the default


Unlikely to be possible.  The built-in data types, such as float or
double, by definition should not be customizable to such degree.

Anyway, under the hood, write uses format with the default format
specifier "%s" for the values it takes.  So perhaps I'm not quite
getting what exactly are you seeking to avoid.


What he's looking for is a way to globally set "I want all floating
point values to print this way, unless a more specific specifier is
given."

It's not a terrible idea, as any code that's using %s most of the time
doesn't really care what the result looks like.

I imagine an API like this:

import std.format: setDefaultFormat;
setDefaultFormat!float("%.10f");


The big problem with that is that it does not play nicely at all with pure.
For writeln, that doesn't matter much, since it can't be pure anyway,
because it's doing I/O, but it would matter for stuff like format or
formattedWrite, which IIRC, writeln uses internally.


That's a perfectly acceptable tradeoff. So:

stdout.setDefaultFormat!float("%.10f");

-Steve

Re: floating point value rounded to 6digits

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 19, 2017 19:35:15 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 9/19/17 7:28 PM, Ivan Kazmenko wrote:
> > On Tuesday, 19 September 2017 at 22:44:06 UTC, greatsam4sure wrote:
> >> On Tuesday, 19 September 2017 at 21:52:57 UTC, Ivan Kazmenko wrote:
> >>> On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure wrote:
>  double  value = 20.89766554373733;
>  writeln(value);
>  //Output =20.8977
> 
>  How do I output the whole value without using writfln,write or
>  format. How do I change this default
> >>>
> >>> The default when printing floating-point numbers is to show six most
> >>> significant digits.
> >>> You can specify the formatting manually with writefln, for example,
> >>>
> >>> writefln ("%.10f", value);
> >>>
> >>> will print the value with 10 digits after the decimal point.
> >>> The writef/writefln function behaves much like printf in C.
> >>>
> >>> See here for a reference on format strings:
> >>> https://dlang.org/library/std/format/formatted_write.html#format-strin
> >>> g
> >>>
> >>> Ivan Kazmenko.
> >>
> >> I don't  want to use write,writefln or format. I just want to change
> >> the default
> >
> > Unlikely to be possible.  The built-in data types, such as float or
> > double, by definition should not be customizable to such degree.
> >
> > Anyway, under the hood, write uses format with the default format
> > specifier "%s" for the values it takes.  So perhaps I'm not quite
> > getting what exactly are you seeking to avoid.
>
> What he's looking for is a way to globally set "I want all floating
> point values to print this way, unless a more specific specifier is
> given."
>
> It's not a terrible idea, as any code that's using %s most of the time
> doesn't really care what the result looks like.
>
> I imagine an API like this:
>
> import std.format: setDefaultFormat;
> setDefaultFormat!float("%.10f");

The big problem with that is that it does not play nicely at all with pure.
For writeln, that doesn't matter much, since it can't be pure anyway,
because it's doing I/O, but it would matter for stuff like format or
formattedWrite, which IIRC, writeln uses internally.

If what the OP wants is to change what writeln does for floating point
values, the easiest way would be for them to create their own writeln and
use that instead. Then, it can forward to std.stdio.writeln for everything
but floating point values, and for floating point values, it can call
writefln with whatever format specifier gives the desired number of decimal
places.

- Jonathan M Davis

Re: floating point value rounded to 6digits

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 7:28 PM, Ivan Kazmenko wrote:

On Tuesday, 19 September 2017 at 22:44:06 UTC, greatsam4sure wrote:

On Tuesday, 19 September 2017 at 21:52:57 UTC, Ivan Kazmenko wrote:

On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure wrote:

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write or 
format. How do I change this default


The default when printing floating-point numbers is to show six most 
significant digits.

You can specify the formatting manually with writefln, for example,

    writefln ("%.10f", value);

will print the value with 10 digits after the decimal point.
The writef/writefln function behaves much like printf in C.

See here for a reference on format strings:
https://dlang.org/library/std/format/formatted_write.html#format-string

Ivan Kazmenko.


I don't  want to use write,writefln or format. I just want to change 
the default


Unlikely to be possible.  The built-in data types, such as float or 
double, by definition should not be customizable to such degree.


Anyway, under the hood, write uses format with the default format 
specifier "%s" for the values it takes.  So perhaps I'm not quite 
getting what exactly are you seeking to avoid.


What he's looking for is a way to globally set "I want all floating 
point values to print this way, unless a more specific specifier is given."


It's not a terrible idea, as any code that's using %s most of the time 
doesn't really care what the result looks like.


I imagine an API like this:

import std.format: setDefaultFormat;
setDefaultFormat!float("%.10f");

-Steve

Re: floating point value rounded to 6digits

[Ivan Kazmenko via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 22:44:06 UTC, greatsam4sure 
wrote:
On Tuesday, 19 September 2017 at 21:52:57 UTC, Ivan Kazmenko 
wrote:
On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure 
wrote:

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write 
or format. How do I change this default


The default when printing floating-point numbers is to show 
six most significant digits.
You can specify the formatting manually with writefln, for 
example,


writefln ("%.10f", value);

will print the value with 10 digits after the decimal point.
The writef/writefln function behaves much like printf in C.

See here for a reference on format strings:
https://dlang.org/library/std/format/formatted_write.html#format-string

Ivan Kazmenko.


I don't  want to use write,writefln or format. I just want to 
change the default


Unlikely to be possible.  The built-in data types, such as float 
or double, by definition should not be customizable to such 
degree.


Anyway, under the hood, write uses format with the default format 
specifier "%s" for the values it takes.  So perhaps I'm not quite 
getting what exactly are you seeking to avoid.


For example, consider a helper function to convert the values, 
like the following:


import std.format, std.stdio;
string fmt (double v) {return v.format !("%.10f");}
void main () {
double x = 1.01;
writeln (x.fmt); // 1.01
}

Alternatively, you can wrap your floating-point numbers in a thin 
struct with a custom toString():


import std.format, std.stdio;
struct myDouble {
double v;
alias v this;
this (double v_) {v = v_;}
string toString () {return v.format !("%.10f");}
}
void main () {
myDouble x = 1.01, y = 2.02, z = x + y;
writeln (z); // 3.03
}

Ivan Kazmenko.

Re: floating point value rounded to 6digits

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 6:44 PM, greatsam4sure wrote:


I don't  want to use write,writefln or format. I just want to change the 
default


It's not a bad idea for an enhancement request -- provide default format 
specifiers for a given type.


Currently, there isn't a mechanism for that.

-Steve

Re: opEquals code generation

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 4:28 PM, Neia Neutuladh wrote:


Could be a bit simpler than that, depending on your needs:

bool opEquals(Object other) const nothrow @nogc
{
     auto f = cast(typeof(this)) other;
     if (f is null) return false;
     return this.tupleof == other.tupleof;
}


That doesn't compare floating point in the way he wants.

-Steve

Re: formattedRead can't work with tab delimiter input

[Ky-Anh Huynh via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 20:04:36 UTC, kdevel wrote:
On Tuesday, 19 September 2017 at 13:28:22 UTC, Ky-Anh Huynh 
wrote:

Hi,

I want to read two fields from STDIN

string key;
double value;
line_st.formattedRead!"%s %f"(key, value);


Well it's so different from C. I would use this:

---
auto t = line_st.split.join (' ');
t.formattedRead!"%s %f"(key, value);
---


Yes it's possible.

It's a little weird and it seems the "feature" (or bug) is not 
documented on https://dlang.org/phobos/std_format.html. Why a tab 
(`\t`) isn't considered as a space?

Andrei Alexandrescu - i am proud

[roman via Digitalmars-d-announce]

I am absolutely proud of your government:

http://madworldnews.com/illegal-muslim-shore-coast-guard/

they keep the ...

Re: floating point value rounded to 6digits

[greatsam4sure via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 21:52:57 UTC, Ivan Kazmenko 
wrote:
On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure 
wrote:

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write or 
format. How do I change this default


The default when printing floating-point numbers is to show six 
most significant digits.
You can specify the formatting manually with writefln, for 
example,


writefln ("%.10f", value);

will print the value with 10 digits after the decimal point.
The writef/writefln function behaves much like printf in C.

See here for a reference on format strings:
https://dlang.org/library/std/format/formatted_write.html#format-string

Ivan Kazmenko.


I don't  want to use write,writefln or format. I just want to 
change the default

Re: What the hell is wrong with D?

[Jesse Phillips via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 19:16:05 UTC, EntangledQuanta 
wrote:
The D community preaches all this safety shit but when it comes 
down to it they don't seem to really care(look at the other 
responses like like "Hey, C does it" or "Hey, look up the 
operator precedence"... as if those responses are meaningful).



jmh530 points out why you're met with such non-agreement of the 
issue. You're not open do discussion of why it is implemented in 
the fashion it is. Instead it is an attack on the community and 
Walter as though there is no logical reason it is implemented in 
the way that it is.


Sure you can express that it is illogical to have made that 
choice, but that requires first know what used to make that 
decision.


For example one of the original principles for D was:
If it looks like C it should have the same semantics or be a 
compiler error (note this was not completely achieved)


Now if we look at other languages we see, they implement it the 
same as C or they don't implement it at all. Just based on this 
it would make sense to choose to implement it like C if it is 
desired to have.


The suggestion I made fulfills this, but it also slightly defeats 
one purpose of the operator, being terse.


We also now need to keep backwards compatibility, this fails.

[Issue 11886] "cannot access frame" error on lambda in lambda

[d-bugmail--- via Digitalmars-d-bugs]

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

Alex  changed:

   What|Removed |Added

 CC||sascha.or...@gmail.com

--- Comment #9 from Alex  ---
Is #17841 a related issue?

--

[Issue 17841] New: cannot access frame of function

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17841
   Summary: cannot access frame of function
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

Given this code


import std.algorithm.iteration : sum, cumulativeFold;
void main()
{
double[5] a;
auto asum = 1.23;
auto jProbs = a[].cumulativeFold!((a, b) => (a + b)/asum);
}


The last line does not compile. 
See
https://forum.dlang.org/post/mplrntaplbtsoyxkw...@forum.dlang.org
probably related to 
https://issues.dlang.org/show_bug.cgi?id=11886 ? 

Used compiler: 
DMD64 D Compiler v2.076.0
on a Mac.

--

Re: floating point value rounded to 6digits

[Ivan Kazmenko via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 20:47:02 UTC, greatsam4sure 
wrote:

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write or 
format. How do I change this default


The default when printing floating-point numbers is to show six 
most significant digits.
You can specify the formatting manually with writefln, for 
example,


writefln ("%.10f", value);

will print the value with 10 digits after the decimal point.
The writef/writefln function behaves much like printf in C.

See here for a reference on format strings:
https://dlang.org/library/std/format/formatted_write.html#format-string

Ivan Kazmenko.

Re: What the hell is wrong with D?

[nkm1 via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:
Yeah, that is really logical! No wonder D sucks and has so many 
bugs! Always wants me to be explicit about the stuff it won't 
figure out but it implicitly does stuff that makes no sense. 
The whole point of the parenthesis is to inform the compiler 
about the expression to use. Not use everything to the left of 
?.


There are two issues there; operator precedence and booleans 
(_win[0] == '@') being a valid operands to +.
If someone is too stupid to learn how precedence works, they 
should consider a different career instead of blaming others.
OTOH, booleans converting to numbers is a very questionable 
feature. I certainly have never seen any good use for it. This is 
just an unfortunate legacy of C, which didn't even have booleans 
for a long time.

Re: What the hell is wrong with D?

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 20:00:40 UTC, Brad Anderson 
wrote:


If you want to help, I suggest trying to come up with a DIP 
that addresses it while being conscious of how to avoid 
breaking an enormous amount of code. I suspect it's a hard and 
maybe impossible problem but if you are up for the challenge 
I'm sure your efforts would be welcome.


Changing the operator precedence would certainly lead to enormous 
breakage.


Most use of the ternary operator is something like
result = a > b ? x : y;
and what he wants is to be forced to say
result = (a + b) ? x : y;
instead of
result = a + b ? x : y;

The problem is that addition/multiplication is above logical 
operators in the operator precedence. So if you were to do 
something like move conditional ternary above 
addition/multiplication, then you also move it above logical 
operators and you'd have to use

result = (a > b) ? x : y;
instead of
result = a > b ? x : y;
which kind of defeats the purpose.

Re: Specifying @nogc on structs seems to have no effect

[Neia Neutuladh via Digitalmars-d]

On Tuesday, 19 September 2017 at 15:11:31 UTC, Craig Black wrote:
Thank you for the information.  What I would like to do is to 
create an Array template class that doesn't use GC at all.


You want to ensure that it can never refer to GC memory. The type 
system does not contain that information. It doesn't say whether 
an object was allocated on the GC heap, on the stack, using 
malloc, using a whole page of memory with mmap, using hardware 
addresses directly on an embedded system with manually planned 
memory layout, using a well-known address range like VGA, as part 
of the binary's static data segment...


So @nogc can't help you. You could, however, replace the GC 
implementation with one that throws an AssertError whenever the 
GC runs a collection, allocates memory, etc. Or you could just 
add @nogc to your main function.


If you want to forbid all reference types, you could write a 
`containsReferenceTypes` template, something like:


enum containsReferenceTypes(T) =
  is(T == class) ||
  is(T == interface) ||
  isDynamicArray!T ||
  isDelegate!T ||
  (isStruct!T && hasReferenceField!T);

bool hasReferenceField(T)()
{
  static foreach (t; Fields!T)
  {
if (containsReferenceTypes!t) return true;
  }
  return false;
}

struct Array(T) if (!containsReferenceTypes!T)
{
}

Unfortunately I don't think this is possible with D in its 
current state, at least not safely anyway.  As it is, I can't 
prevent someone using my Array template to create an array of 
objects that reference the GC heap.  This means that in order 
to not break the language and avoid memory leaks, I am forced 
to tell the GC to scan all of my allocations.  There seems to 
be no way to avoid this unnecessary overhead.


That's use-after-free, not memory leaks. The GC doesn't watch to 
see when things go out of scope; it periodically scans the world 
to see what's still in scope.



I realize that the GC will not collect during a @nogc function.
 This is a good guarantee, but I want to reduce the amount of 
time it takes to perform a collection, and there doesn't seem 
to be a good way to do this.


The GC is smart enough to not scan something for pointers if it 
doesn't contain pointers. So if you have `new Vec4[100]`, for 
instance, the GC isn't going to waste time scanning the memory it 
points to.


So if you have an Array!int variable in a GC'd object, it's 
basically a pointer and a length. The GC will note that the block 
of memory it points to has a reference to it and should not be 
disposed of. It will at some point consider doing a scan on that 
block of memory, see that it has no pointers in it, and skip over 
it.

floating point value rounded to 6digits

[greatsam4sure via Digitalmars-d-learn]

double  value = 20.89766554373733;
writeln(value);
//Output =20.8977

How do I output the whole value without using writfln,write or 
format. How do I change this default

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #4)
> 
> This is how you track the 'this' pointer for mmap to the frame of
> printstuffs.
> 

Also note that you can't trust toParent2() here, as it returns the function the
template was declared in. Parent access should be done through toParent() to
properly inspect whether a template comes from another template instance
(declared in another context).

--

[Issue 17836] ICE with custom 'map' template

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Iain Buclaw  ---
Note to anyone looking.

For function call to mmap(...).


Given that:

FuncDeclaration fd = void mmap(T...);

fd.toParent2() == main();
fd.parent.isTemplateInstance() == template mmap(T...);
fd.parent.isTemplateInstance().tinst == template printstuffs(T...);
fd.parent.isTemplateInstance().tinst.toAlias() == void printstuffs(T...);

This is how you track the 'this' pointer for mmap to the frame of printstuffs.

Fix for gdc will happen soon.  Someone will have to look at dmd.

--

Re: opEquals code generation

[Neia Neutuladh via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 13:18:04 UTC, drug wrote:

19.09.2017 15:38, Steven Schveighoffer пишет:

On 9/19/17 8:01 AM, drug wrote:
I iterate over struct members and check against equality 
depending on member type. is there more simple/cleaner/better 
way to achieve this functionality? Especially without string 
mixins?


Why not just use tupleof directly instead of having to find 
the member name and using mixins?


-Steve


Hmm, I'm sure I had tried it before and failed, but now I've 
managed to do so and it's really simpler


Could be a bit simpler than that, depending on your needs:

bool opEquals(Object other) const nothrow @nogc
{
auto f = cast(typeof(this)) other;
if (f is null) return false;
return this.tupleof == other.tupleof;
}

Re: What the hell is wrong with D?

[Neia Neutuladh via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:


writeln(x + ((_win[0] == '@') ? w/2 : 0));
writeln(x + (_win[0] == '@') ? w/2 : 0);

The first returns x + w/2 and the second returns w/2!


Yeah, it sucks to have bugs like this crop up. I have enough 
trouble remembering operator precedence, so I end up using 
parentheses everywhere and pretending the ternary operator 
doesn't exist. I also tend to break up complex expressions a lot. 
It's just safer, and usually clearer.

Re: How to compile for Win64 with Visual D? Optlink error?

[Rainer Schuetze via Digitalmars-d-learn]

On 19.09.2017 13:47, Timothy Foster wrote:
I'm trying to compile my project as a Win64 application but this is 
happening:


Building C:\Users\me\test\test.exe...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 183: Extension not .RES : 
obj\debug\dummy\test\..\source\c.obj

obj\debug\dummy\test\..\source\b.obj(1) : Error 52: .DEF Syntax Error
d†š
öñÀY$@

^
Building C:\Users\me\test\test.exe failed!


I'm on a Win64 machine and compiling Win32 works fine. I'm using Visual 
Studio 17 Community with Visual D. DMD is up to date as is Visual D.


I added a x64 "solution platform" to the configuration manager which 
added a -m64 flag to my linker options. I'm not sure what else I'm meant 
to do to get it to compile as x64?


That usually happens if the DMD bin folder is searched first in the PATH 
variable (unfortunately the linker and other tools have the same name as 
the Microsoft programs).


You should verify that the VC folder is listed first in 
Tools->Options->Projects and Solutions->Visual D Settings->DMD 
Directories->x64->Executable Paths, i.e.


$(VCTOOLSINSTALLDIR)bin\HostX86\x86

should be listed before

$(DMDInstallDir)windows\bin

Re: What the hell is wrong with D?

[Brad Anderson via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 19:16:05 UTC, EntangledQuanta 
wrote:

[snip]

I'm just glad there is at least one sane person that decided to 
chime in... was quite surprised actually. I find it quite 
pathetic when someone tries to justify a wrong by pointing to 
other wrongs. It takes away all credibility that they have.


I have no doubt that had someone thought to propose addressing 
this when the language was new it would have been seriously 
considered and likely accepted (given how frequently this causes 
bugs). D tried to fix a lot of behavior from C that was bug prone 
but it didn't catch everything.


If you want to help, I suggest trying to come up with a DIP that 
addresses it while being conscious of how to avoid breaking an 
enormous amount of code. I suspect it's a hard and maybe 
impossible problem but if you are up for the challenge I'm sure 
your efforts would be welcome.

Re: formattedRead can't work with tab delimiter input

[kdevel via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 13:28:22 UTC, Ky-Anh Huynh wrote:

Hi,

I want to read two fields from STDIN

string key;
double value;
line_st.formattedRead!"%s %f"(key, value);


Well it's so different from C. I would use this:

---
auto t = line_st.split.join (' ');
t.formattedRead!"%s %f"(key, value);
---

Re: What the hell is wrong with D?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 1:40 PM, EntangledQuanta wrote:


The first returns x + w/2 and the second returns w/2!


Did you mean (x + w) / 2 or x + (w / 2)? Stop being ambiguous!

-Steve

Re: D std.regex is so slow

[Daniel Kozak via Digitalmars-d]

Is there a plan to make BitNFA back? Is possible that newCTFE will improve
problem with memory? Or it is possible to improve those slow cases?

On Tue, Sep 19, 2017 at 8:12 PM, Dmitry Olshansky via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Tuesday, 19 September 2017 at 16:27:51 UTC, jmh530 wrote:
>
>> On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
>>
>>> https://github.com/mariomka/regex-benchmark#performance
>>>
>>> Do you know why?
>>>
>>> Here is a code:
>>> https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
>>>
>>> I have try it with ldc too, but is still much slower (10x) than PHP
>>>
>>
>> Looks like they added ldc to it. I'm seeing 3x slower than PHP on Email
>> and URI, but roughly par on IP. It really stands out on the DMD one how
>> much better it does on the IP one than the Email/URI ones.
>>
>
> IP is detected to be "semi-fixed" thus hitting a nice fast path.
>
> Others would have worked with BitNFA, a patch that we had to revert
> because auto-tester run out of memory.
>
>
>
>

Re: What the hell is wrong with D?

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 19:16:05 UTC, EntangledQuanta 
wrote:


()?: is not ambiguous!

The D community preaches all this safety shit but when it comes 
down to it they don't seem to really care(look at the other 
responses like like "Hey, C does it" or "Hey, look up the 
operator precedence"... as if those responses are meaningful).




I sympathize that it was a difficult to find problem. Happens to 
me a lot. Nevertheless, I pretty much never use ternary operators 
because Matlab was my first language was it doesn't have them. 
I'm always writing out if() { } else { }. So it's not really an 
error that happens for me.


The point that others and myself were making about C is that your 
initial post was very critical of D and Walter. Unduly, IMO. You 
were blaming D for the problem, when it turns out that in 
virtually every language that uses this syntax it works this way 
(and I checked like 10, just to be sure). Harshly criticizing 
Walter for something that is a generally accepted way of doing 
things across many programming languages is unreasonable. D never 
promised to be the greatest language ever whose users never ever 
write any buggy code at all. It's aims are a bit more limited 
than that.


There's an easy solution to your problem: use more parentheses 
with conditional ternary operators.

Re: What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 18:51:51 UTC, Jesse Phillips 
wrote:
On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:
I assume someone is going to tell me that the compiler treats 
it as


writeln((x + (_win[0] == '@')) ? w/2 : 0);

Yeah, that is really logical!


Yeah, I've been bitten by that in languages like C#. I wish D 
didn't follow in C#'s footsteps and chosen a different syntax: 
`()? :`


That way if there aren't any parentheses the compiler could 
throw out an error until you specify what the operating is 
working with. It would make for a little overhead but these 
complex ternary expressions can be confusing.


Yes, it's not that they are confusing but illogical.

a + b ? c : d

in a complex expression can be hard to interpret if a and b are 
complex. The whole point of parenthesis is to disambiguate and 
group things. To not use them is pretty ignorant.


1 + 2 ? 3 : 4

That is ambiguous. is it (1 + 2) ? 3 : 4 or 1 + (2 ? 3 : 4)?

Well,

()?: is not ambiguous!

The D community preaches all this safety shit but when it comes 
down to it they don't seem to really care(look at the other 
responses like like "Hey, C does it" or "Hey, look up the 
operator precedence"... as if those responses are meaningful).


I'm just glad there is at least one sane person that decided to 
chime in... was quite surprised actually. I find it quite 
pathetic when someone tries to justify a wrong by pointing to 
other wrongs. It takes away all credibility that they have.

Re: Specifying @nogc on structs seems to have no effect

[ag0aep6g via Digitalmars-d]

On 09/19/2017 08:06 PM, Craig Black wrote:
This wouldn't 
be allowed for classes or class references, since they are always 
pointing to GC data


That's not true. You can put class objects into other places than the GC 
heap.

Re: Trial v0.4.0 and visual-trial v0.1.0 are out

[Anton Fediushin via Digitalmars-d-announce]

On Monday, 18 September 2017 at 20:50:55 UTC, Szabo Bogdan wrote:

Hi!

I want to announce that I managed to release a new version of 
Trial, the DLang test runner.


Great news, it works just fine now!

Re: What the hell is wrong with D?

[Jesse Phillips via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:
I assume someone is going to tell me that the compiler treats 
it as


writeln((x + (_win[0] == '@')) ? w/2 : 0);

Yeah, that is really logical!


Yeah, I've been bitten by that in languages like C#. I wish D 
didn't follow in C#'s footsteps and chosen a different syntax: 
`()? :`


That way if there aren't any parentheses the compiler could throw 
out an error until you specify what the operating is working 
with. It would make for a little overhead but these complex 
ternary expressions can be confusing.

Re: What the hell is wrong with D?

[Ali Çehreli via Digitalmars-d-learn]

On 09/19/2017 11:34 AM, Brad Anderson wrote:
> On Tuesday, 19 September 2017 at 18:17:47 UTC, jmh530 wrote:

>> Pretty sure it would be exactly the same thing in C...
>
> It is (and Java and C# and pretty much every other C style language
> though the nicer implicit conversion rules means it gets caught more
> easily). It is a big source of programmer mistakes. It comes up
> frequently in PVS Studio's open source analysis write ups.

Just a random Google find for some entertainment. :)


http://twistedoakstudios.com/blog/Post5273_how-to-read-nested-ternary-operators

  string result = i % 2 == 0 ? "a" : i % 3 == 0 ? "b" : i % 5 == 0 ? 
"c" : i % 7 == 0 ? "d" : "e";


Ali

Re: What the hell is wrong with D?

[Brad Anderson via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 18:17:47 UTC, jmh530 wrote:
On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:


Thanks for wasting some of my life... Just curious about who 
will justify the behavior and what excuses they will give.


Pretty sure it would be exactly the same thing in C...


It is (and Java and C# and pretty much every other C style 
language though the nicer implicit conversion rules means it gets 
caught more easily). It is a big source of programmer mistakes. 
It comes up frequently in PVS Studio's open source analysis write 
ups.

Re: How to list all process directories under /proc/

[Matt Jones via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 13:32:29 UTC, Ky-Anh Huynh wrote:



Btw, is that a bit weird that range is not supported in glob 
pattern :) Is there a design reason for this?


That is strange. But then again, every glob library I've seen 
works a little bit differently.

Re: Specifying @nogc on structs seems to have no effect

[Steven Schveighoffer via Digitalmars-d]

On 9/19/17 2:06 PM, Craig Black wrote:
Thank you for the clarification. I understand mow that @nogc is only for 
functions and not for data types.  Thinking out loud, it would seem 
beneficial if there was a way to mark a pointer or data structure as not 
pointing to the GC heap. A guarantee to the compiler and run-time to 
ignore it during GC sweeps.  Now I know that pointer arithmetic breaks 
every kind of guarantee that would have with pointers, but aside from 
that it would seem to me that the compiler could help to enforce data 
marked as non-GC to not be assigned GC heap allocations.  This wouldn't 
be allowed for classes or class references, since they are always 
pointing to GC data, but perhaps for pointers and structs.  It seems 
like it would be a helpful feature, but maybe I'm way off base.


In order for that to work, we would first need a precise scanner, as the 
current scanner scans ALL values in a block to see if any point at any 
heap memory, regardless of whether it is truly a pointer or not.


Also, if a pointer points to something outside the heap, there is no 
scanning of that data, since the GC doesn't know about it. The cost of 
having a pointer that points to a non-GC memory location is small (not 
entirely trivial, but it's just a few comparisons). The only true 
benefit would be to avoid scanning the entire block. This means that 
along with precise scanning, you couldn't have any GC pointers in the block.


As with most things, we need to prove the benefit with profiling before 
spending any time thinking about how to implement, and certainly before 
adding any language/library features.


-Steve

Re: What the hell is wrong with D?

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:


Thanks for wasting some of my life... Just curious about who 
will justify the behavior and what excuses they will give.


Pretty sure it would be exactly the same thing in C...

Re: D std.regex is so slow

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 19 September 2017 at 16:27:51 UTC, jmh530 wrote:
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak 
wrote:

https://github.com/mariomka/regex-benchmark#performance

Do you know why?

Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d

I have try it with ldc too, but is still much slower (10x) 
than PHP


Looks like they added ldc to it. I'm seeing 3x slower than PHP 
on Email and URI, but roughly par on IP. It really stands out 
on the DMD one how much better it does on the IP one than the 
Email/URI ones.


IP is detected to be "semi-fixed" thus hitting a nice fast path.

Others would have worked with BitNFA, a patch that we had to 
revert because auto-tester run out of memory.

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 15:15:05 UTC, Steven 
Schveighoffer wrote:

On 9/19/17 10:22 AM, Craig Black wrote:
On Tuesday, 19 September 2017 at 13:59:27 UTC, Jonathan M 
Davis wrote:
On Tuesday, September 19, 2017 13:11:03 Craig Black via 
Digitalmars-d wrote:
I've recently tried coding in D again after some years.  One 
of my earlier concerns was the ability to code without the 
GC, which seemed difficult to pull off.  To be clear, I want 
my programs to be garbage collected, but I want to use the 
GC sparingly so that the mark and sweep collections will be 
fast.
 So I want guarantees that certain sections of code and 
certain structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using 
malloc and free and emplace, but I find it troubling that 
you still need to tell the GC to scan your allocation. What 
I would like is, for example, to be able to write a @nogc 
templated struct that guarantees that none of its members 
require GC scanning.  Thus:


@nogc struct Array(T)
{
   ...
}

class GarbageCollectedClass
{
}

void main()
{
   Array!int intArray; // fine


}


@nogc is a function attribute. It has no effect on types 
except on their member functions. All it does is guarantee 
that a function marked with @nogc cannot call any function 
which is not @nogc and cannot do any operation which is not 
considered @nogc. It's to guarantee that a function does not 
use the GC and has nothing more to do with types than 
attributes like @safe or nothrow do.



Thank you for your response.  The @nogc attribute is good, but 
in my opinion it is incomplete if all types still require 
scanning. The purpose of not employing GC in certain sections 
of code is performance, and we are sacrificing performance 
with every allocation unit that is needlessly scanned.




From your posts and responses, it looks like you misunderstand 
still what the @nogc attribute does.


Note that a type does not bear any relation to whether the 
memory it lives in is scanned or not -- EXCEPT -- whether the 
type has indirections (pointers or arrays). A type which 
contains indirections is scanned, one that does not contain 
them is not scanned. There is no way to mark a type such that 
it:


1. Cannot be allocated on the GC*
2. Would not be scanned if it has pointers.

You can manually allocate it elsewhere, and you can manually 
tell the GC not to scan that block, but those are low-level 
tools that normally aren't used except by experts.


The @nogc attribute is used to PREVENT any operation that could 
cause a scan to occur. The idea is to mark areas of your code 
in such a way that you can predict the execution expense of 
that code. That is, if you have a tight loop or are in the 
middle of rendering frames to the screen in a game or 
something, you want to have the compiler ensure no GC cycles 
happen. It does not mean "don't ever store this in the GC."


-Steve

* There is a deprecated feature of D that allows specifying how 
to allocate classes other than heap allocation, but I wouldn't 
recommend using it. See: 
https://dlang.org/spec/class.html#allocators


Thank you for the clarification. I understand mow that @nogc is 
only for functions and not for data types.  Thinking out loud, it 
would seem beneficial if there was a way to mark a pointer or 
data structure as not pointing to the GC heap. A guarantee to the 
compiler and run-time to ignore it during GC sweeps.  Now I know 
that pointer arithmetic breaks every kind of guarantee that would 
have with pointers, but aside from that it would seem to me that 
the compiler could help to enforce data marked as non-GC to not 
be assigned GC heap allocations.  This wouldn't be allowed for 
classes or class references, since they are always pointing to GC 
data, but perhaps for pointers and structs.  It seems like it 
would be a helpful feature, but maybe I'm way off base.


-Craig

Re: What the hell is wrong with D?

[Eugene Wissner via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta 
wrote:


writeln(x + ((_win[0] == '@') ? w/2 : 0));
writeln(x + (_win[0] == '@') ? w/2 : 0);

The first returns x + w/2 and the second returns w/2!

WTF!!! This stupid bug has caused me considerable waste of 
time. Thanks Walter! I know you care so much about my time!


I assume someone is going to tell me that the compiler treats 
it as


writeln((x + (_win[0] == '@')) ? w/2 : 0);

Yeah, that is really logical! No wonder D sucks and has so many 
bugs! Always wants me to be explicit about the stuff it won't 
figure out but it implicitly does stuff that makes no sense. 
The whole point of the parenthesis is to inform the compiler 
about the expression to use. Not use everything to the left of 
?.


Thanks for wasting some of my life... Just curious about who 
will justify the behavior and what excuses they will give.


Why do you claim that a bug in your code is a compiler bug? Check 
"Operator precedence" [1]. There is really no reason why the 
current precedence is less "logical" than what you're awaiting.


And try to think about things you're writing, nobody forces you 
to use D.


[1] https://wiki.dlang.org/Operator_precedence

What the hell is wrong with D?

[EntangledQuanta via Digitalmars-d-learn]

writeln(x + ((_win[0] == '@') ? w/2 : 0));
writeln(x + (_win[0] == '@') ? w/2 : 0);

The first returns x + w/2 and the second returns w/2!

WTF!!! This stupid bug has caused me considerable waste of time. 
Thanks Walter! I know you care so much about my time!


I assume someone is going to tell me that the compiler treats it 
as


writeln((x + (_win[0] == '@')) ? w/2 : 0);

Yeah, that is really logical! No wonder D sucks and has so many 
bugs! Always wants me to be explicit about the stuff it won't 
figure out but it implicitly does stuff that makes no sense. The 
whole point of the parenthesis is to inform the compiler about 
the expression to use. Not use everything to the left of ?.


Thanks for wasting some of my life... Just curious about who will 
justify the behavior and what excuses they will give.

Re: Assertion Error

[Vino.B via Digitalmars-d-learn]

On Wednesday, 13 September 2017 at 15:27:30 UTC, Moritz Maxeiner 
wrote:

On Wednesday, 13 September 2017 at 15:12:57 UTC, Vino.B wrote:
On Wednesday, 13 September 2017 at 11:03:38 UTC, Moritz 
Maxeiner wrote:

On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:

 [...]


[...]

---
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
  MSresult.get ~= coSizeDirList(Fs.strip, SizeDir);
}
---


Hi Max,


It's Moritz, not Max. ;)



 Below is the explanation of the above code.

[...]


AFAICT that's a reason why you want parallelization of 
coSizeDirList, but not why you need to spawn another thread 
inside of an *already parallelelized" task. Try my shortened 
parallel foreach loop vs your longer one and monitor system 
load (threads, memory, etc).


Hi Moritz,

 Thank you very much, it was very helpful and time saving and 
fast.


From,
Vino.B

Re: D std.regex is so slow

[12345swordy via Digitalmars-d]

On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:

https://github.com/mariomka/regex-benchmark#performance

Do you know why?

Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d

I have try it with ldc too, but is still much slower (10x) than 
PHP


Irc a rewrite is in the work.

Re: D std.regex is so slow

[jmh530 via Digitalmars-d]

On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:

https://github.com/mariomka/regex-benchmark#performance

Do you know why?

Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d

I have try it with ldc too, but is still much slower (10x) than 
PHP


Looks like they added ldc to it. I'm seeing 3x slower than PHP on 
Email and URI, but roughly par on IP. It really stands out on the 
DMD one how much better it does on the IP one than the Email/URI 
ones.

[Issue 129] DDoc downgrades enum to their integer initializers

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #12 from Iain Buclaw  ---
(In reply to Timothee Cour from comment #10)
> https://dlang.org/library/std/process/pipe_process.html
> shows:
> 
> ProcessPipes pipeProcess( 
>   const(char[][]) args, 
>   Redirect redirect = cast(Redirect)7, 
>   const(string[string]) env = cast(const(string[string]))null, 
>   Config config = cast(Config)0, 
>   const(char[]) workDir = null 
> ) @safe; 
> 
> 
> with
> 
> cast(Redirect)7, 
> 
> instead of 
> 
> Redirect redirect = Redirect.all,
> 
> as in source code

Interestingly, when compiling a minimal test - just the enum declarations and
the pipeProcess function - the ddoc generated looks fine.


---

Declaration

@safe ProcessPipes pipeProcess(in char[][] args, Redirect redirect =
Redirect.all, const string[string] env = null, Config config = Config.none, in
char[] workDir = null);

---

I think this should be closed, and other issues stemming from handled in their
respective report numbers.

--

Re: D std.regex is so slow

[Daniel Kozak via Digitalmars-d]

I have tried it, but does not change anything

On Tue, Sep 19, 2017 at 6:05 PM, Jon Degenhardt via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
>
>> https://github.com/mariomka/regex-benchmark#performance
>>
>> Do you know why?
>>
>> Here is a code:
>> https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
>>
>> I have try it with ldc too, but is still much slower (10x) than PHP
>>
>
> Might get some gain by compiling with '-flto-full'. Was faster on a regex
> test I ran, though not nearly the deltas shown.
>
> --Jon
>

Re: D std.regex is so slow

[Jon Degenhardt via Digitalmars-d]

On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:

https://github.com/mariomka/regex-benchmark#performance

Do you know why?

Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d

I have try it with ldc too, but is still much slower (10x) than 
PHP


Might get some gain by compiling with '-flto-full'. Was faster on 
a regex test I ran, though not nearly the deltas shown.


--Jon

Re: Specifying @nogc on structs seems to have no effect

[Steven Schveighoffer via Digitalmars-d]

On 9/19/17 10:22 AM, Craig Black wrote:

On Tuesday, 19 September 2017 at 13:59:27 UTC, Jonathan M Davis wrote:
On Tuesday, September 19, 2017 13:11:03 Craig Black via Digitalmars-d 
wrote:
I've recently tried coding in D again after some years.  One of my 
earlier concerns was the ability to code without the GC, which seemed 
difficult to pull off.  To be clear, I want my programs to be garbage 
collected, but I want to use the GC sparingly so that the mark and 
sweep collections will be fast.
 So I want guarantees that certain sections of code and certain 
structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc and 
free and emplace, but I find it troubling that you still need to tell 
the GC to scan your allocation. What I would like is, for example, to 
be able to write a @nogc templated struct that guarantees that none 
of its members require GC scanning.  Thus:


@nogc struct Array(T)
{
   ...
}

class GarbageCollectedClass
{
}

void main()
{
   Array!int intArray; // fine


}


@nogc is a function attribute. It has no effect on types except on 
their member functions. All it does is guarantee that a function 
marked with @nogc cannot call any function which is not @nogc and 
cannot do any operation which is not considered @nogc. It's to 
guarantee that a function does not use the GC and has nothing more to 
do with types than attributes like @safe or nothrow do.



Thank you for your response.  The @nogc attribute is good, but in my 
opinion it is incomplete if all types still require scanning. The 
purpose of not employing GC in certain sections of code is performance, 
and we are sacrificing performance with every allocation unit that is 
needlessly scanned.




From your posts and responses, it looks like you misunderstand still 
what the @nogc attribute does.


Note that a type does not bear any relation to whether the memory it 
lives in is scanned or not -- EXCEPT -- whether the type has 
indirections (pointers or arrays). A type which contains indirections is 
scanned, one that does not contain them is not scanned. There is no way 
to mark a type such that it:


1. Cannot be allocated on the GC*
2. Would not be scanned if it has pointers.

You can manually allocate it elsewhere, and you can manually tell the GC 
not to scan that block, but those are low-level tools that normally 
aren't used except by experts.


The @nogc attribute is used to PREVENT any operation that could cause a 
scan to occur. The idea is to mark areas of your code in such a way that 
you can predict the execution expense of that code. That is, if you have 
a tight loop or are in the middle of rendering frames to the screen in a 
game or something, you want to have the compiler ensure no GC cycles 
happen. It does not mean "don't ever store this in the GC."


-Steve

* There is a deprecated feature of D that allows specifying how to 
allocate classes other than heap allocation, but I wouldn't recommend 
using it. See: https://dlang.org/spec/class.html#allocators

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 14:34:10 UTC, Mike Parker wrote:
On Tuesday, 19 September 2017 at 14:22:21 UTC, Craig Black 
wrote:


Thank you for your response.  The @nogc attribute is good, but 
in my opinion it is incomplete if all types still require 
scanning.  The purpose of not employing GC in certain sections 
of code is performance, and we are sacrificing performance 
with every allocation unit that is needlessly scanned.


-Craig


As I wrote in my previous post, *no* GC activity will happen 
inside a @nogc function. The only time any scanning or 
collections can take place is when a allocation is requested. 
If none are requested, there's no activity.


Aside from that, there are other options. If you don't want 
your Foo member variable to be scanned, then allocate it 
outside the GC heap (see Mallocator in std.allocator). You can 
call GC.disable whenever you want (but be wary of the impact 
performance when you later call GC.collect). You can allocate 
outside of your hot loops and use stack allocation where 
possible.


I suggest you take a look at the ongoing GC series on the D 
Blog. The next post (coming later this week) covers heap 
allocations.


https://dlang.org/blog/the-gc-series/


Thank you for the information.  What I would like to do is to 
create an Array template class that doesn't use GC at all.  
Unfortunately I don't think this is possible with D in its 
current state, at least not safely anyway.  As it is, I can't 
prevent someone using my Array template to create an array of 
objects that reference the GC heap.  This means that in order to 
not break the language and avoid memory leaks, I am forced to 
tell the GC to scan all of my allocations.  There seems to be no 
way to avoid this unnecessary overhead.


I realize that the GC will not collect during a @nogc function.  
This is a good guarantee, but I want to reduce the amount of time 
it takes to perform a collection, and there doesn't seem to be a 
good way to do this.


-Craig

Re: Specifying @nogc on structs seems to have no effect

[Mike Parker via Digitalmars-d]

On Tuesday, 19 September 2017 at 14:22:21 UTC, Craig Black wrote:

Thank you for your response.  The @nogc attribute is good, but 
in my opinion it is incomplete if all types still require 
scanning.  The purpose of not employing GC in certain sections 
of code is performance, and we are sacrificing performance with 
every allocation unit that is needlessly scanned.


-Craig


As I wrote in my previous post, *no* GC activity will happen 
inside a @nogc function. The only time any scanning or 
collections can take place is when a allocation is requested. If 
none are requested, there's no activity.


Aside from that, there are other options. If you don't want your 
Foo member variable to be scanned, then allocate it outside the 
GC heap (see Mallocator in std.allocator). You can call 
GC.disable whenever you want (but be wary of the impact 
performance when you later call GC.collect). You can allocate 
outside of your hot loops and use stack allocation where possible.


I suggest you take a look at the ongoing GC series on the D Blog. 
The next post (coming later this week) covers heap allocations.


https://dlang.org/blog/the-gc-series/

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:59:27 UTC, Jonathan M Davis 
wrote:
On Tuesday, September 19, 2017 13:11:03 Craig Black via 
Digitalmars-d wrote:
I've recently tried coding in D again after some years.  One 
of my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.
 So I want guarantees that certain sections of code and 
certain structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using 
malloc and free and emplace, but I find it troubling that you 
still need to tell the GC to scan your allocation. What I 
would like is, for example, to be able to write a @nogc 
templated struct that guarantees that none of its members 
require GC scanning.  Thus:


@nogc struct Array(T)
{
   ...
}

class GarbageCollectedClass
{
}

void main()
{
   Array!int intArray; // fine


}


@nogc is a function attribute. It has no effect on types except 
on their member functions. All it does is guarantee that a 
function marked with @nogc cannot call any function which is 
not @nogc and cannot do any operation which is not considered 
@nogc. It's to guarantee that a function does not use the GC 
and has nothing more to do with types than attributes like 
@safe or nothrow do.


- Jonathan M Davis


Thank you for your response.  The @nogc attribute is good, but in 
my opinion it is incomplete if all types still require scanning.  
The purpose of not employing GC in certain sections of code is 
performance, and we are sacrificing performance with every 
allocation unit that is needlessly scanned.


-Craig

Re: Specifying @nogc on structs seems to have no effect

[John Colvin via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
I've recently tried coding in D again after some years.  One of 
my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.  
So I want guarantees that certain sections of code and certain 
structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc 
and free and emplace, but I find it troubling that you still 
need to tell the GC to scan your allocation. What I would like 
is, for example, to be able to write a @nogc templated struct 
that guarantees that none of its members require GC scanning.  
Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}


@nogc has nothing to do with whether something needs scanning. It 
guarantees that code will never allocate with the GC or trigger a 
GC collection (because the only way to do that is to allocate or 
to call the functions in core.memory.GC, which are deliberately 
not marked @nogc).

[Issue 17832] std.random.choice cannot be used with other random generators

[d-bugmail--- via Digitalmars-d-bugs]

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

Anton Fediushin  changed:

   What|Removed |Added

 CC||fediushin.an...@yandex.ru

--

Re: Specifying @nogc on structs seems to have no effect

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 19, 2017 13:11:03 Craig Black via Digitalmars-d wrote:
> I've recently tried coding in D again after some years.  One of
> my earlier concerns was the ability to code without the GC, which
> seemed difficult to pull off.  To be clear, I want my programs to
> be garbage collected, but I want to use the GC sparingly so that
> the mark and sweep collections will be fast.  So I want
> guarantees that certain sections of code and certain structs will
> not require the GC in any way.
>
> I realize that you can allocate on the non-GC heap using malloc
> and free and emplace, but I find it troubling that you still need
> to tell the GC to scan your allocation. What I would like is, for
> example, to be able to write a @nogc templated struct that
> guarantees that none of its members require GC scanning.  Thus:
>
> @nogc struct Array(T)
> {
>...
> }
>
> class GarbageCollectedClass
> {
> }
>
> void main()
> {
>Array!int intArray; // fine
>
>
> }

@nogc is a function attribute. It has no effect on types except on their
member functions. All it does is guarantee that a function marked with @nogc
cannot call any function which is not @nogc and cannot do any operation
which is not considered @nogc. It's to guarantee that a function does not
use the GC and has nothing more to do with types than attributes like @safe
or nothrow do.

- Jonathan M Davis

Re: Specifying @nogc on structs seems to have no effect

[ag0aep6g via Digitalmars-d]

On 09/19/2017 03:46 PM, Craig Black wrote:

struct MyStruct
{
@nogc:
public:
   Foo foo; // This does not produce an error, but it still requires a 
GC scan


@nogc is about GC allocations. `Foo foo;` doesn't cause a GC allocation.

@nogc doesn't control what memory is scanned by the GC.

Re: Specifying @nogc on structs seems to have no effect

[Mike Parker via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:46:20 UTC, Craig Black wrote:

Thanks, I didn't know you could to that but it still doesn't 
give me the behavior that I want:


class Foo
{
}

struct MyStruct
{
@nogc:
public:
  Foo foo; // This does not produce an error, but it still 
requires a GC scan

  void Bar()
  {
foo = new Foo; // This produces an error
  }
}


@nogc applies to functions, not to types or variables. It 
prevents actions that allocate, like calls to new, appending to 
or concatenating arrays, and so on, inside the annotated 
function. By extension, no sort of GC scanning or collections 
will occur in such functions because that sort of thing can only 
happen during an allocation.

Re: Specifying @nogc on structs seems to have no effect

[drug via Digitalmars-d]

19.09.2017 16:46, Craig Black пишет:

class Foo
{
}

struct MyStruct
{
@nogc:
public:
   Foo foo; // This does not produce an error, but it still requires a 
GC scan

   void Bar()
   {
     foo = new Foo; // This produces an error
   }
}


it produces an error for me https://run.dlang.io/is/PbZE5i

Re: Specifying @nogc on structs seems to have no effect

[drug via Digitalmars-d]

19.09.2017 16:49, drug пишет:

19.09.2017 16:48, drug пишет:

19.09.2017 16:46, Craig Black пишет:

class Foo
{
}

struct MyStruct
{
@nogc:
public:
   Foo foo; // This does not produce an error, but it still requires 
a GC scan

   void Bar()
   {
 foo = new Foo; // This produces an error
   }
}


it produces an error for me https://run.dlang.io/is/PbZE5i

sorry, wrong link, this one
https://run.dlang.io/is/UwTCXu


Oh no, today is not my day, sorry for noise)

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:32:59 UTC, Eugene Wissner 
wrote:
On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black 
wrote:
I've recently tried coding in D again after some years.  One 
of my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.
 So I want guarantees that certain sections of code and 
certain structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using 
malloc and free and emplace, but I find it troubling that you 
still need to tell the GC to scan your allocation. What I 
would like is, for example, to be able to write a @nogc 
templated struct that guarantees that none of its members 
require GC scanning.  Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}



struct Array(T)
{
@nogc:
  ...
}
?


Thanks, I didn't know you could to that but it still doesn't give 
me the behavior that I want:


class Foo
{
}

struct MyStruct
{
@nogc:
public:
  Foo foo; // This does not produce an error, but it still 
requires a GC scan

  void Bar()
  {
foo = new Foo; // This produces an error
  }
}

Re: Specifying @nogc on structs seems to have no effect

[drug via Digitalmars-d]

19.09.2017 16:48, drug пишет:

19.09.2017 16:46, Craig Black пишет:

class Foo
{
}

struct MyStruct
{
@nogc:
public:
   Foo foo; // This does not produce an error, but it still requires a 
GC scan

   void Bar()
   {
 foo = new Foo; // This produces an error
   }
}


it produces an error for me https://run.dlang.io/is/PbZE5i

sorry, wrong link, this one
https://run.dlang.io/is/UwTCXu

Re: Specifying @nogc on structs seems to have no effect

[Eugene Wissner via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
I've recently tried coding in D again after some years.  One of 
my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.  
So I want guarantees that certain sections of code and certain 
structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc 
and free and emplace, but I find it troubling that you still 
need to tell the GC to scan your allocation. What I would like 
is, for example, to be able to write a @nogc templated struct 
that guarantees that none of its members require GC scanning.  
Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}



struct Array(T)
{
@nogc:
  ...
}
?

Re: Specifying @nogc on structs seems to have no effect

[Andrea Fontana via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:13:48 UTC, Craig Black wrote:

@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine
  Array!GarbageCollectedClass classArray; // Error: struct 
Array is @nogc


}


If you want to enforce that behaviour I guess you can use 
reflection to check if T has attribute @nogc.


Andrea

Re: How to list all process directories under /proc/

[Ky-Anh Huynh via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 06:35:18 UTC, Matt Jones wrote:
On Sunday, 17 September 2017 at 08:37:33 UTC, Ky-Anh Huynh 
wrote:



[...]


The problem with matching "[0123456789]*" is that it will match 
files like "1blah" and "8stuff". It looks like glob patterns 
are not robust enough to handle match patterns you want. A 
regex would probably be enough. Something like this works:


[...]



I understand. Thanks a lot.

Btw, is that a bit weird that range is not supported in glob 
pattern :) Is there a design reason for this?

formattedRead can't work with tab delimiter input

[Ky-Anh Huynh via Digitalmars-d-learn]

Hi,

I want to read two fields from STDIN

string key;
double value;
line_st.formattedRead!"%s %f"(key, value);

However, if the input line contains \t and it doesn't contain any 
space, the code doesn't work as expected. If there is a space, it 
works well


   a[space]1 # work, key => a, value => 1
   b[space][tab]2# work, key => b, value => 2
   c[tab]3   # not work, key => c[tab]3, value => nan

Can you please help? Thanks a lot.


PS: My program is found here

https://github.com/icy/dusybox/blob/master/src/plotbar/main.d#L59

Re: opEquals code generation

[drug via Digitalmars-d-learn]

19.09.2017 15:38, Steven Schveighoffer пишет:

On 9/19/17 8:01 AM, drug wrote:
I iterate over struct members and check against equality depending on 
member type. is there more simple/cleaner/better way to achieve this 
functionality? Especially without string mixins?


Why not just use tupleof directly instead of having to find the member 
name and using mixins?


-Steve


Hmm, I'm sure I had tried it before and failed, but now I've managed to 
do so and it's really simpler (https://run.dlang.io/is/GJkokW):

```
auto opEquals()(auto ref const(typeof(this)) rhs)
{
import std.math : approxEqual, isNaN;
import std.traits : isFloatingPoint, isIntegral;

static foreach(i; 0..this.tupleof.length)
{
{
alias FType = typeof(this.tupleof[i]);

// a field of this structure
auto tf = this.tupleof[i];
// a field of other structure
auto of = rhs.tupleof[i];

static if (isFloatingPoint!FType)
{
if (!tf.isNaN || !of.isNaN)
{
if (!approxEqual(tf, of))
return false;
}
}
else static if (isIntegral!FType)
{
if (tf != of)
return false;
}
else
static assert (0);
}
}
return true;
}
```

Thank you, Steven!

Re: Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
I've recently tried coding in D again after some years.  One of 
my earlier concerns was the ability to code without the GC, 
which seemed difficult to pull off.  To be clear, I want my 
programs to be garbage collected, but I want to use the GC 
sparingly so that the mark and sweep collections will be fast.  
So I want guarantees that certain sections of code and certain 
structs will not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc 
and free and emplace, but I find it troubling that you still 
need to tell the GC to scan your allocation. What I would like 
is, for example, to be able to write a @nogc templated struct 
that guarantees that none of its members require GC scanning.  
Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}


I don't know why send this message out when I was just in the 
middle of typing it out: But the example should read like this:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine
  Array!GarbageCollectedClass classArray; // Error: struct Array 
is @nogc


}

Specifying @nogc on structs seems to have no effect

[Craig Black via Digitalmars-d]

I've recently tried coding in D again after some years.  One of 
my earlier concerns was the ability to code without the GC, which 
seemed difficult to pull off.  To be clear, I want my programs to 
be garbage collected, but I want to use the GC sparingly so that 
the mark and sweep collections will be fast.  So I want 
guarantees that certain sections of code and certain structs will 
not require the GC in any way.


I realize that you can allocate on the non-GC heap using malloc 
and free and emplace, but I find it troubling that you still need 
to tell the GC to scan your allocation. What I would like is, for 
example, to be able to write a @nogc templated struct that 
guarantees that none of its members require GC scanning.  Thus:


@nogc struct Array(T)
{
  ...
}

class GarbageCollectedClass
{
}

void main()
{
  Array!int intArray; // fine


}

Re: D for Android

[Johannes Pfau via Digitalmars-d]

Am Tue, 19 Sep 2017 12:38:15 +
schrieb twkrimm :

> On Tuesday, 19 September 2017 at 07:44:47 UTC, Andrea Fontana 
> wrote:
> > On Tuesday, 19 September 2017 at 03:25:08 UTC, Joakim wrote:  
> >> Next up, 32-bit ARM Android devices are now supported, I'm 
> >> looking at getting 64-bit AArch64 Android up and running.  
> >
> > Keep it up!
> > Andrea  
> 
> Joakim
> 
> I think the  Atmel processors (AVR) that Microchhip bought are 
> 32-bit ARM based.
> It would be neat to develop D programs for limited resource 
> processors.

OT, but Atmel produces:
AVR 8 bit microcontrollers, AVR custom architecture
AVR32 32 bit microcontrollers, AVR32 custom architecture
ARM based products (the SAM* series), ARM7, ARM9, Cortex-M/Cortex-A

Microchip additionally maintains custom 8,16 and 32 bit PIC
architectures.

Joakim's Android work is much appreciated, but for these types of
bare-metal controllers you'll have to look at Mike's work:
https://github.com/JinShil/stm32f42_discovery_demo

This is for 32bit ARM only. I wrote a proof-of concept hello-world for
AVR 8bit controllers (blink an LED) some time ago. On the compiler
side, not much is missing and betterC-related changes fix most compiler
problems. What you really need though is register definitions and
nobody wrote those for AVR 8 bit controllers yet.

-- Johannes

Re: Basic LDC Linux Install Question

[jmh530 via Digitalmars-d-learn]

On Tuesday, 19 September 2017 at 12:37:12 UTC, Daniel Kozak wrote:
Yes you need to add ldc2 to your PATH. So if your ldc2 binary 
is in

/user/something/something/folder_where_is_ldc2/ldc2
you havto add /user/something/something/folder_where_is_ldc2 to 
your PATH.

You can test this by pasting this to terminal:

export 
PATH=$PATH:/user/something/something/folder_where_is_ldc2 ldc2 
--version




Okay, not good enough to just point to the ldc folder, I need to 
point to the ldc/ldc-1.4.0/bin folder. That's just like Windows, 
now that I think of it. Thanks.

[Issue 17832] std.random.choice cannot be used with other random generators

[d-bugmail--- via Digitalmars-d-bugs]

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

Duncan Paterson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dun...@gmail.com
   Assignee|nob...@puremagic.com|dun...@gmail.com

--

Re: opEquals code generation

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/17 8:01 AM, drug wrote:
I iterate over struct members and check against equality depending on 
member type. is there more simple/cleaner/better way to achieve this 
functionality? Especially without string mixins?


Why not just use tupleof directly instead of having to find the member 
name and using mixins?


-Steve

Re: D for Android

[twkrimm via Digitalmars-d]

On Tuesday, 19 September 2017 at 07:44:47 UTC, Andrea Fontana 
wrote:

On Tuesday, 19 September 2017 at 03:25:08 UTC, Joakim wrote:
Next up, 32-bit ARM Android devices are now supported, I'm 
looking at getting 64-bit AArch64 Android up and running.


Keep it up!
Andrea


Joakim

I think the  Atmel processors (AVR) that Microchhip bought are 
32-bit ARM based.
It would be neat to develop D programs for limited resource 
processors.


Does the compiler support the -BetterC flag?

I know this was hard work, and I give you a very, very big thank 
you.


twkrimm

Re: Basic LDC Linux Install Question

[Daniel Kozak via Digitalmars-d-learn]

Yes you need to add ldc2 to your PATH. So if your ldc2 binary is in
/user/something/something/folder_where_is_ldc2/ldc2
you havto add /user/something/something/folder_where_is_ldc2 to your PATH.
You can test this by pasting this to terminal:

export PATH=$PATH:/user/something/something/folder_where_is_ldc2
ldc2 --version

On Tue, Sep 19, 2017 at 2:26 PM, jmh530 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> I'm more of a Windows user than a Linux user. I have the latest DMD on my
> Linux install (linux mint 17.3), but I wanted to test LDC.
>
> I get a message that ldc2 is not found when I type ldc2 --version or sudo
> ldc2 --version (I'm not on root and the existing user does not have root
> privileges, so I have to sudo around that folder).
>
> Here's what I did:
> 1) Download binary from ldc github page
> 2) Unpack and copy to /usr/local/bin/ldc/ldc2-1.4.0-linux-x86_64
>
> I was concerned that the issue is that ldc2 is not in the path. When I
> type $PATH I get
> bash: 
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:
> No such file or directory
>
> Do I need to add /usr/local/bin/ldc to it also? Or am I missing out on
> some other step?
>

Basic LDC Linux Install Question

[jmh530 via Digitalmars-d-learn]

I'm more of a Windows user than a Linux user. I have the latest 
DMD on my Linux install (linux mint 17.3), but I wanted to test 
LDC.


I get a message that ldc2 is not found when I type ldc2 --version 
or sudo ldc2 --version (I'm not on root and the existing user 
does not have root privileges, so I have to sudo around that 
folder).


Here's what I did:
1) Download binary from ldc github page
2) Unpack and copy to /usr/local/bin/ldc/ldc2-1.4.0-linux-x86_64

I was concerned that the issue is that ldc2 is not in the path. 
When I type $PATH I get
bash: 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games: No such file or directory


Do I need to add /usr/local/bin/ldc to it also? Or am I missing 
out on some other step?

Re: opEquals code generation

[drug via Digitalmars-d-learn]

19.09.2017 15:01, drug пишет:
I iterate over struct members and check against equality depending on 
member type. is there more simple/cleaner/better way to achieve this 
functionality? Especially without string mixins?

oops, https://run.dlang.io/is/PbZE5i

Re: How to compile for Win64 with Visual D? Optlink error?

[Daniel Kozak via Digitalmars-d-learn]

this should be ok, can you post error when using with m64

On Tue, Sep 19, 2017 at 1:47 PM, Timothy Foster via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> I'm trying to compile my project as a Win64 application but this is
> happening:
>
> Building C:\Users\me\test\test.exe...
> OPTLINK (R) for Win32  Release 8.00.17
> Copyright (C) Digital Mars 1989-2013  All rights reserved.
> http://www.digitalmars.com/ctg/optlink.html
> OPTLINK : Warning 183: Extension not .RES : obj\debug\dummy\test\..\source
> \c.obj
> obj\debug\dummy\test\..\source\b.obj(1) : Error 52: .DEF Syntax Error
> d†š öñÀY$@
>
> ^
> Building C:\Users\me\test\test.exe failed!
>
>
> I'm on a Win64 machine and compiling Win32 works fine. I'm using Visual
> Studio 17 Community with Visual D. DMD is up to date as is Visual D.
>
> I added a x64 "solution platform" to the configuration manager which added
> a -m64 flag to my linker options. I'm not sure what else I'm meant to do to
> get it to compile as x64?
>