Re: Ecoji-d v1.0.0 is released - Base1024 using emojis 

[Manu via Digitalmars-d-announce]

On 15 March 2018 at 11:45, Anton Fediushin via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

>
> Even though each emoji is 4 bytes long, there is a noticable difference in
> size when we are talking about larger chunks of data:
>

This doesn't make sense. For every 10 bits, you're emitting 32 bits...
you're more than tripling the size of the data.
Base64 takes 6 bits and emits 8 bits, which is a third larger. 1.333x is
smaller than 3.2x. O_o

Re: How to enable verbose logging during application run

[Venkat via Digitalmars-d-learn]

Thankyou.

Re: how to make private class member private

[Amorphorious via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 23:54:22 UTC, psychoticRabbit wrote:

On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:

On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:

maybe extend that to a list of types?


this is basically what C++ friend does and D was trying to 
avoid the complexity of


Really, the complexity of 'friend' comes from people abusing it.

In D, I would prefer no breaking change here. Leave private as 
it is.


Just a simple attribute that only applies within a class, and 
only to private members within that class.


@strictly private string firstName_;

Nothing outside of the class, not even the module, can access 
this now. It's all encapsulated.


It breaks nothing (AFAIK).
It's very clear what the intention is here.
It's an easy attribute to remember.
It restores the principle of class enscapsulation within a 
module, for when it's really needed.


Now D programmers would have the best of both worlds.



Why do you insist that you know how everything works and you are 
the harbinger of truth. The fact is, you don't know squat about 
what you are talking about and you just want to conform D to your 
naive ignorant understanding of programming so you don't get 
confused rather than learning and accepting D for what it does, 
which is do everything better than C/C++. You keep trying to make 
it in to C/C++, the the hell don't you just go use C/C++ then?


No one is going to listen to you. Your ignorance is pointed out 
by many that have used D far longer than you have and you think 
you can come in and point out all the things wrong without having 
any experience with it.


The fact is, the creator of the class is also the creator of the 
module.. and preventing him from having full access to the class 
is ignorant. He doesn't need to encapsulate himself. 
Encapsulation is ONLY meant to reduce dependencies. If the 
programmer, probably someone like you, can't trust himself to 
understand his own code then he shouldn't be coding.


If you don't like it, just write one class per module and don't 
have any free functions... it solves your problem and it doesn't 
use your shitty "solution". No one is forcing you to access your 
class outside the class but inside the module.


The fact is you are ignorant of what you speak about and that is 
99% of the problem. If you don't like how D does it, go use 
another language that does it the way you "think"(if you could 
call it that) is correct.


Many of the thing D does is learned from the mistakes of C/C++... 
and for you to pretend that your insignificant self who has never 
wrote a compiler much less read the specs has a clue about the 
ramifications of the changes is moronic.


Your only reason for not liking it is because you "don't like 
it"... how moronic.


"Mmm.. I don't think I like it.

I feel you should be able to make a member of a class, private, 
regardless of where the class is located. This seems to break the 
concept of class encapsulation.


No. I don't like it at all.
"

Yet you have no clue... You "learned"(brainwashed" that 
encapsulation means private members of classes cannot be accessed 
from C++ and because D provides a more complex rule that you 
can't seem to grasp(but which is very simple and no other human 
that has used D has had issues with) you say that D is wrong 
rather than that you or C++ is wrong.


The fact is, you are a moron. It's not because of this one issue 
but because of your mentality of which this is just an example. 
I'm sure you have the same thing with many issues in your life 
and you go strutting around like you own the place telling 
everyone what is wrong with how things are done when you yourself 
have no clue.


Want me to prove it to you?

You say:
"I feel you should be able to make a member of a class, private, 
regardless of where the class is located. This seems to break the 
concept of class encapsulation.

"

Yet, really, what you mean is that it breaks the concept of class 
that you learned in programming 101 that had to do with C++. You 
don't have a clue about logic and qualification. Maybe you are 
confused and you thought D was C++?



You know, if you go to Rome... ah never mind, you won't get it...

Re: CTFE ^^ (pow)

[ketmar via Digitalmars-d]

Manu wrote:


What is so hard about implementing a pow intrinsic that CTFE can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 years.


nobody bothered. it is all done by intercepting calls in CTFE engine (using 
FQN mangled names), nothing very special. i once did it in my fork (but 
then mangling scheme was changed, and i never fixed the patch, lol).

CTFE ^^ (pow)

[Manu via Digitalmars-d]

What is so hard about implementing a pow intrinsic that CTFE can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10 years.

[Issue 18325] `dmd/core/exception.d(686): _store is thread local` when building dmd

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

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

John Belmonte  changed:

   What|Removed |Added

 CC||j...@neggie.net

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

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

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9fbf0611d2ef4174597470834cb6e356f791468a
fix Issue 17423 - pointer assignment to  in member function is not accounted
for

https://github.com/dlang/dmd/commit/eee17da2ffd89093a2de2f7310ca01520cd49a64
Merge pull request #7999 from WalterBright/fix17423

fix Issue 17423 - pointer assignment to  in member function is not ac…
merged-on-behalf-of: Mike Franklin 

--

[Issue 17423] pointer assignment to `this` in member function is not accounted for

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

[Issue 15660] break immutable with pure function and mutable reference params

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

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

--- Comment #7 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8048

--

[Issue 15660] break immutable with pure function and mutable reference params

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

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

Walter Bright  changed:

   What|Removed |Added

Summary|break "immutable" with pure |break immutable with pure
   |function and mutable|function and mutable
   |reference params|reference params

--

[Issue 18199] Error with lambda in struct initializer

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

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

--- Comment #3 from John Belmonte  ---
I'm trying to locate relevant code in the dmd source code, any pointers would
be appreciated.

The emitted "Deprecation: use { } for an empty statement, not ;" error is
telling.  We can infer that the compiler is incorrectly interpreting the
initializer expression as a statement.

--

Re: how to make private class member private

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote:

On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:

maybe extend that to a list of types?


this is basically what C++ friend does and D was trying to 
avoid the complexity of


Really, the complexity of 'friend' comes from people abusing it.

In D, I would prefer no breaking change here. Leave private as it 
is.


Just a simple attribute that only applies within a class, and 
only to private members within that class.


@strictly private string firstName_;

Nothing outside of the class, not even the module, can access 
this now. It's all encapsulated.


It breaks nothing (AFAIK).
It's very clear what the intention is here.
It's an easy attribute to remember.
It restores the principle of class enscapsulation within a 
module, for when it's really needed.


Now D programmers would have the best of both worlds.

Re: How to enable verbose logging during application run

[rjframe via Digitalmars-d-learn]

On Sat, 17 Mar 2018 22:37:36 +, Venkat wrote:

> Sorry posted the above message by accident.
> 
> I am running a vibed app using `dub` command. But it produces no logging
> what so ever when requests are made. The server returns http error codes
> but it doesn't log anything to the console. How do I make it show me a
> lot more detail than it is doing now ?
> 
> For example, in a Java webapp, one would change the logging level to
> debug if a logging library is configured.


vibe.core.log has a setLogLevel function.

http://vibed.org/api/vibe.core.log/setLogLevel
http://vibed.org/api/vibe.core.log/LogLevel


Also, the URLRouter class has a getAllRoutes method; if needed, writing 
that to the terminal can verify the routes are what you expect.

Re: Ecoji-d v1.0.0 is released - Base1024 using emojis 

[Faux Amis via Digitalmars-d-announce]

On 2018-03-14 18:30, Anton Fediushin wrote:
, I'm glad to announce that ecoji-d - pure D implementation of ecoji 
encoding version 1️⃣.0️⃣.0️⃣ is finally released❗


What is ecoji?

Ecoji encodes data as base1024 with an emoji character set. It can be 
used instead of boring and old base64 冷冷冷.


Encoding example:

---
$ echo "Base64 is so 1999, isn't there something better?" | ecoji-d
論撚若 



Useful feature: Easy manual verification.

Re: How to enable verbose logging during application run

[Venkat via Digitalmars-d-learn]

Sorry posted the above message by accident.

I am running a vibed app using `dub` command. But it produces no 
logging what so ever when requests are made. The server returns 
http error codes but it doesn't log anything to the console. How 
do I make it show me a lot more detail than it is doing now ?


For example, in a Java webapp, one would change the logging level 
to debug if a logging library is configured.

How to enable verbose logging during application run

[Venkat via Digitalmars-d-learn]

I am running a vibed app using `dub` command. But it produces no 
logging what so ever when re

[Issue 18625] mixin(__MODULE__) in string mixin results in undefined identifier in certain cases

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
   Hardware|x86 |All
 OS|Windows |All
   Severity|enhancement |normal

--- Comment #1 from ag0aep6g  ---
Reduced:


module y.asdf;
pragma(msg, __MODULE__); /* y.asdf */
pragma(msg, mixin("__MODULE__")); /* asdf */


Both lines should print "y.asdf".

--

[Issue 18626] New: std.traits.fullyQualifiedName on value results in T instead of error

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

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

  Issue ID: 18626
   Summary: std.traits.fullyQualifiedName on value results in T
instead of error
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

ie: fullyQualifiedName!0 == "T", rather than a failure

--

Re: D beyond the specs

[Walter Bright via Digitalmars-d]

On 3/17/2018 1:02 PM, Laeeth Isharc wrote:
Anyway I asked Walter about why so many Germans in the D community.  No final 
answer.  It's interesting that Walter is of German descent.  A controversial 
topic, but in my experience what you are from shapes who you are, how you think 
and what you value.  And receptivity to a particular way of doing things isn't 
uniform across the world.


I'm German, Dutch, and English. But I grew up in America, so culturally I'm 
American.

[Issue 18625] New: mixin(__MODULE__) in string mixin results in undefined identifier in certain cases

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

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

  Issue ID: 18625
   Summary: mixin(__MODULE__) in string mixin results in undefined
identifier in certain cases
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

This works: 

```
module asdf;

mixin(`static assert(mixin(__MODULE__).stringof == "module "~__MODULE__);`);
```

This does not work:

```
module y.asdf;

mixin(`static assert(mixin(__MODULE__).stringof == "module "~__MODULE__);`);
```

--

[Issue 15624] opApply with @safe and @system variants can't be used with foreach syntax

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

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

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8047

--

Re: how to make private class member private

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote:

maybe extend that to a list of types?


this is basically what C++ friend does and D was trying to avoid 
the complexity of

Re: how to make private class member private

[arturg via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:
I don't like the name @deny, personally I would rather see the 
private attribute changed to something like:


private(true) // The member is oly visible to its parent.

private(false) // Same as just "private", visible to whole 
module.


Could be specialized to something like:

private(this) // Same as private(true)

private(module) // Same as private(false)



maybe extend that to a list of types?

private(typeof(this), Foo, Bar)

would mean only typeof(this), Foo and Bar from the same module 
have access.

Re: Can't add ubytes together to make a ubyte... bug or feature?

[Ali Çehreli via Digitalmars-d-learn]

On 03/17/2018 11:36 AM, Jonathan wrote:

`(a+b)&0xff` What is this syntax?!  Could you give a link to this in the 
D documentation?


Here is my description of bitwise AND:


http://ddili.org/ders/d.en/bit_operations.html#ix_bit_operations.&,%20bitwise%20and

The section titled "Masking" on the same page explains what &0xff part 
means.



I am not even sure how to look it up...


I hope my index section is useful in such cases. Just search for the & 
character there:


  http://ddili.org/ders/d.en/ix.html

Yes, there are many meanings of the & character but I think it's still 
useful. :)


Ali

Re: D beyond the specs

[greentea via Digitalmars-d]

On Saturday, 17 March 2018 at 20:17:17 UTC, Laeeth Isharc wrote:

...  A small group, drawn to do something for intrinsic reasons 
starts to create something.  And they get no face because it 
seems completely unrealistic and in truth the odds are very 
much against success.  But they create something excellent 
because they care about intrinsic reasons and not social 
factors.  And some people start to take notice, but it's still 
more or less a fringe but interesting project.  And it stays 
that way until the world changes, and changes in a way that 
looks obvious with hindsight but nobody really expected at the 
time.  At that point what's important changes and the project 
starts to become popular.  Then people more ambitiously than 
intrinsically motivated start to be drawn by what's now obvious 
and the project starts to be popular, and yet with that 
popularity comes a change in its nature and sometimes people 
think back to the old days. ...


Just like the Linux project - started by a Finnish guy.

[Issue 18555] getSymbolsByUDA has strange behaviour on modules

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

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

spoov0@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||spoov0@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from spoov0@gmail.com ---
Fixed by
https://github.com/dlang/phobos/pull/6290

--

[Issue 18624] getSymbolsByUDA produces wrong result if one of the symbols having the UDA is a function

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

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

spoov0@gmail.com changed:

   What|Removed |Added

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

--- Comment #2 from spoov0@gmail.com ---
https://github.com/dlang/phobos/pull/6290

--

Re: D beyond the specs

[Laeeth Isharc via Digitalmars-d]

On Saturday, 17 March 2018 at 16:26:27 UTC, Guillaume Piolat 
wrote:
While France is all about status (titles, living well over your 
means), and people prefer to learn "high-status" languages, I 
guess this is the profile of late adopters everywhere.


Yes, status seems one of the most important things for normal 
people.


But there's a repeating pattern in life.  A small group, drawn to 
do something for intrinsic reasons starts to create something.  
And they get no face because it seems completely unrealistic and 
in truth the odds are very much against success.  But they create 
something excellent because they care about intrinsic reasons and 
not social factors.  And some people start to take notice, but 
it's still more or less a fringe but interesting project.  And it 
stays that way until the world changes, and changes in a way that 
looks obvious with hindsight but nobody really expected at the 
time.  At that point what's important changes and the project 
starts to become popular.  Then people more ambitiously than 
intrinsically motivated start to be drawn by what's now obvious 
and the project starts to be popular, and yet with that 
popularity comes a change in its nature and sometimes people 
think back to the old days.


So I think that pattern might apply to D, and if that's right one 
might as well focus on the challenges before one and enjoy the 
benefits from the present makeup of the community.  Because as 
adoption grows eventually the makeup will change too.


If you're good and care about what's important, eventually status 
comes to you.  And now you've got more problems to worry about.  
But life isn't about banishing problems, but overcoming them.

Re: User Stories: Funkwerk

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, March 17, 2018 20:12:08 bauss via Digitalmars-d-announce wrote:
> On Saturday, 17 March 2018 at 19:54:07 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, March 17, 2018 12:48:07 bauss via
> >
> > Digitalmars-d-announce wrote:
> >> On Friday, 16 March 2018 at 19:42:11 UTC, Rubn wrote:
> >> > On Wednesday, 14 March 2018 at 14:17:50 UTC, Mike Parker
> >> >
> >> > wrote:
> >> >> foreach(auto element: elements)
> >> >
> >> > ":" is C++ syntax
> >>
> >> Also "auto" can be omitted.
> >>
> >> foreach (element; elements)
> >
> > Not only can be. It must be. auto is not legal in a foreach
> > loop in D, which is arguably a bit inconsistent, but for better
> > or worse, that's the way it is.
> >
> > - Jonathan M Davis
>
> Ahh, I didn't know it had become illegal or at least I think I
> remember foreach loops accepting auto in the past, but that's
> probably years ago or maybe I remember wrong and it has always
> been illegal?

AFAIK, it has always been illegal, and periodically, it's been brought up
that it should be legal for consistency, but for better or worse, it hasn't
been changed.

- Jonathan M Davis

Re: User Stories: Funkwerk

[bauss via Digitalmars-d-announce]

On Saturday, 17 March 2018 at 19:54:07 UTC, Jonathan M Davis 
wrote:
On Saturday, March 17, 2018 12:48:07 bauss via 
Digitalmars-d-announce wrote:

On Friday, 16 March 2018 at 19:42:11 UTC, Rubn wrote:
> On Wednesday, 14 March 2018 at 14:17:50 UTC, Mike Parker 
> wrote:

>> foreach(auto element: elements)
>
> ":" is C++ syntax

Also "auto" can be omitted.

foreach (element; elements)


Not only can be. It must be. auto is not legal in a foreach 
loop in D, which is arguably a bit inconsistent, but for better 
or worse, that's the way it is.


- Jonathan M Davis


Ahh, I didn't know it had become illegal or at least I think I 
remember foreach loops accepting auto in the past, but that's 
probably years ago or maybe I remember wrong and it has always 
been illegal?

Re: Can't add ubytes together to make a ubyte... bug or feature?

[bauss via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 18:56:55 UTC, Dominikus Dittes 
Scherkl wrote:

On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote:
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe 
wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend 
wrote:
I don't care if my computer needs to do math on a 4 byte 
basis, I'm not writing assembly.


x86 actually doesn't need to do math that way, if you were 
writing assembly, it would just work. This is just an 
annoying rule brought over by C.



Can I prevent the initial implicit casts?


Nope, though you can help tell the compiler that you want it 
to fit there by doing stuff like


ubyte a = 200;
ubyte b = 100;
ubyte c = (a+b)&0xff;

or something like that, so the expression is specifically 
proven to fit in the byte with compile time facts.



`(a+b)&0xff` What is this syntax?!  Could you give a link to 
this in the D documentation?  I am not even sure how to look 
it up...

& is the normal binary and operation, same in C, C++, Java, ...
0xFF is a hexadecimal constant (255), which the compiler knows 
fit in an ubyte

So what do you not understand about this syntax?


I guess he doesn't understand bitwise operations.

Also don't you mean bitwise and?

Re: D beyond the specs

[Laeeth Isharc via Digitalmars-d]

On Friday, 16 March 2018 at 18:38:44 UTC, Aurélien Plazzotta 
wrote:

On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote:
Would it be possible to find out at DConf in Munich why 
exactly D is so popular in Germany (my impression) and in 
other countries of Europe (and that general post code) like 
France, Italy, GB, Romania and Russia etc.?


To the best of my knowledge, there is currently no job offer in 
D programming in France. It is not even required/highlighted as 
a second/bonus skill to apply for a job.


Perhaps it is used within a research and development department 
of very few companies for very specific tasks but it's unheard 
of and the mentalities of top management won't change before 
long because we are a retarded population who needs a lot of 
safety nets and huge amounts of guarantees to actually to take 
action...


Also, french citizens don't like taking financial and 
technological risks, now adopting D for profesionnal use is a 
big one.


And yet in Paris lives a man, presumably a French citizen, who 
was working on a cryptocurrency scaling startup last dconf and 
that ended up being part of the path towards launching Bitcoin 
Cash.  So some French citizens don't seem to mind taking risks or 
trying new things, and if there is a dampening of entrepreneurial 
spirits it might be the government and culture.  That's just one 
example, but the outliers can often tell you more than those in 
the centre of the distribution.


It seems like it's already beginning to change slowly.  It wasn't 
long ago that speaking about the French startup scene was more 
like the punchline to a joke.  Today it's something real and I 
think will grow further from here.


Things change slowly in the beginning.  Top management aren't the 
ones to start doing something creative unless they are a highly 
unusual kind of firm.  It's people who can decide or who don't 
need to ask anyone's permission that are the early adopters.


Anyway I asked Walter about why so many Germans in the D 
community.  No final answer.  It's interesting that Walter is of 
German descent.  A controversial topic, but in my experience what 
you are from shapes who you are, how you think and what you 
value.  And receptivity to a particular way of doing things isn't 
uniform across the world.

Re: User Stories: Funkwerk

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, March 17, 2018 12:48:07 bauss via Digitalmars-d-announce wrote:
> On Friday, 16 March 2018 at 19:42:11 UTC, Rubn wrote:
> > On Wednesday, 14 March 2018 at 14:17:50 UTC, Mike Parker wrote:
> >> foreach(auto element: elements)
> >
> > ":" is C++ syntax
>
> Also "auto" can be omitted.
>
> foreach (element; elements)

Not only can be. It must be. auto is not legal in a foreach loop in D, which
is arguably a bit inconsistent, but for better or worse, that's the way it
is.

- Jonathan M Davis

Re: Can't add ubytes together to make a ubyte... bug or feature?

[Dominikus Dittes Scherkl via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote:
On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe 
wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend 
wrote:
I don't care if my computer needs to do math on a 4 byte 
basis, I'm not writing assembly.


x86 actually doesn't need to do math that way, if you were 
writing assembly, it would just work. This is just an annoying 
rule brought over by C.



Can I prevent the initial implicit casts?


Nope, though you can help tell the compiler that you want it 
to fit there by doing stuff like


ubyte a = 200;
ubyte b = 100;
ubyte c = (a+b)&0xff;

or something like that, so the expression is specifically 
proven to fit in the byte with compile time facts.



`(a+b)&0xff` What is this syntax?!  Could you give a link to 
this in the D documentation?  I am not even sure how to look it 
up...

& is the normal binary and operation, same in C, C++, Java, ...
0xFF is a hexadecimal constant (255), which the compiler knows 
fit in an ubyte

So what do you not understand about this syntax?

Re: D beyond the specs

[Walter Bright via Digitalmars-d]

On 3/17/2018 4:28 AM, Arjan wrote:

On Friday, 16 March 2018 at 19:27:40 UTC, Walter Bright wrote:
My old company's product, Zortech C++, was also very popular in Germany, 
England, and Japan. I don't know why.


And a certain spot in the Netherlands, because at the time it outperformed all 
the others like Borland Watcom IBM/visual-age ms-visual-c++ and others at 
compilation speed and most of the time in execution speed as well. Besides since 
we used multiple compiler on our code base symantec/digitalmars often reported 
violations were the other happily accepted the code (and produced wrong code) 
And the incident response time from you was just marvelous, reported an issue, 
next morning a fixed compiler version in the emailbox!


Beside that, I really appreciated the so called IDDE and accompanied srcs of 
libs. It was imo much much better than VC++ at the time. Have used it for a very 
long time even after Symantec ditched it. (borland f* up theirs by forcing 
the C++ builder upone us)




Sounds a lot like D of today, too!

(Thanks for the kind words. I appreciate it!)

Re: Can't add ubytes together to make a ubyte... bug or feature?

[Jonathan via Digitalmars-d-learn]

On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote:
On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend 
wrote:
I don't care if my computer needs to do math on a 4 byte 
basis, I'm not writing assembly.


x86 actually doesn't need to do math that way, if you were 
writing assembly, it would just work. This is just an annoying 
rule brought over by C.



Can I prevent the initial implicit casts?


Nope, though you can help tell the compiler that you want it to 
fit there by doing stuff like


ubyte a = 200;
ubyte b = 100;
ubyte c = (a+b)&0xff;

or something like that, so the expression is specifically 
proven to fit in the byte with compile time facts.



`(a+b)&0xff` What is this syntax?!  Could you give a link to this 
in the D documentation?  I am not even sure how to look it up...

Re: Convert output range to input range

[John Chapman via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 17:16:40 UTC, David Nadlinger wrote:

On Friday, 16 March 2018 at 07:57:04 UTC, John Chapman wrote:
I need to write to a range created with outputRangeObject, 
then read from it. Is there a way to convert it to an input 
range?


Could you illustrate your problem a bit further?


I'm trying to replace the old std.streams in my app with ranges. 
I'm interfacing with a networking library to which I supply a 
callback that when invoked provides the requested data. I write 
that data to an output range, but later on I need to read that 
data from the range too - which of course you can't do.


So what I'm looking for is the range-based equivalent of a 
MemoryStream.

Re: how to make private class member private

[bauss via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 15:02:21 UTC, psychoticRabbit wrote:

On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:


I don't like the name @deny .


how about:

@reallyis private string firstName_;

mmm..perhaps not... then how about...

@strictly private string firstName_;


Still introduces a new attribute. D already has a lot of 
attributes and it goes against how every other attribute for 
visibility works.


That's why my suggestion would work better, because the package 
attribute already works like that.

Re: Convert output range to input range

[David Nadlinger via Digitalmars-d-learn]

On Friday, 16 March 2018 at 07:57:04 UTC, John Chapman wrote:
I need to write to a range created with outputRangeObject, then 
read from it. Is there a way to convert it to an input range?


Could you illustrate your problem a bit further?

In the literal sense, converting from an output to an input range 
would require using coroutines (where .empty() blocks until the 
output range has supplied the next element).


However, I suspect what you want to do is to write results from 
the output range to a buffer (e.g. an Appender) first, and after 
that – or possibly every so often in chunks – process the results 
further?


 — David

[Issue 18199] Error with lambda in struct initializer

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

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

John Belmonte  changed:

   What|Removed |Added

 CC||j...@neggie.net

--- Comment #2 from John Belmonte  ---
The memberName:expression variant of initialization is also affected:

struct Foo {
int function(int) bar;
}

static Foo foo = {
bar : function(x) { return 2 * x; },  // broken
//bar : (x) => 2 * x,  // works
};

This seems to be a parsing issue where the struct initializer can't handle
nested curly brackets.

--

Re: D beyond the specs

[Guillaume Piolat via Digitalmars-d]

On Friday, 16 March 2018 at 18:38:44 UTC, Aurélien Plazzotta 
wrote:
Also, french citizens don't like taking financial and 
technological risks, now adopting D for professionnal use is a 
big one.


A friend of mine has heard about D for about ten years. I've been 
bothering people for a while.


At last dinner we realized two among the table were full-time D 
programmers, and this friend's own brother works with Laeeth. So 
now he now has 3 acquaintances that use D professionally, and are 
enthusiastic.

I don't think such a meal is common in France, just a data point.

Only then he _started asking questions_ about D and what you 
could do, etc.


While France is all about status (titles, living well over your 
means), and people prefer to learn "high-status" languages, I 
guess this is the profile of late adopters everywhere.


Germany is hopefully different, it takes only one german to 
change a light bulb :)

Re: D beyond the specs

[Guillaume Piolat via Digitalmars-d]

On Friday, 16 March 2018 at 14:50:26 UTC, Paulo Pinto wrote:


Well, Algol, Pascal, Oberon, Component Pascal, VHDL, Ada are 
all examples of programming languages successfully used in 
Europe, while having adoption issues on US.


It's even stranger for Ada because AFAIK it was invented for US 
government needs.

Re: Disallowing the creation of objects using new should have default object functions and parent functions be @nogc by definition.

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 17 March 2018 at 13:30:25 UTC, 12345swordy wrote:

Does anyone dispute this?


I don't really see how this would help anything.

[Issue 18623] Documented unittest should not allow private symbol access

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
I agree though the compiler currently doesn't know whether the test is ddoc-ed
when -D isn't passed. As it throws away all documentation text during parsing.

For Phobos we use a workaround which extracts all public tests and puts them in
separate files and then executes them:

https://github.com/dlang/tools/blob/master/tests_extractor.d

--

Re: How to build static linked executable

[Seb via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 14:44:42 UTC, zunkree wrote:

Hi,

Is there a way to build static linked executable with dub for 
vibe-d based app?


Regards,
zunkree


Yes, use -static

Here's how we build the DTour: 
https://github.com/dlang-tour/core/blob/master/dub.sdl

Re: How to build static linked executable

[Seb via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 15:42:06 UTC, Seb wrote:

On Saturday, 17 March 2018 at 14:44:42 UTC, zunkree wrote:

Hi,

Is there a way to build static linked executable with dub for 
vibe-d based app?


Regards,
zunkree


Yes, use -static

Here's how we build the DTour: 
https://github.com/dlang-tour/core/blob/master/dub.sdl


I forgot to mention that -static is an LDC-only flag, but you 
wouldn't want to use DMD for an optimized application anyhow.

Re: how to make private class member private

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote:


I don't like the name @deny .


how about:

@reallyis private string firstName_;

mmm..perhaps not... then how about...

@strictly private string firstName_;

[Issue 18624] getSymbolsByUDA produces wrong result if one of the symbols having the UDA is a function

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
PR: https://github.com/dlang/phobos/pull/6292

--

How to build static linked executable

[zunkree via Digitalmars-d-learn]

Hi,

Is there a way to build static linked executable with dub for 
vibe-d based app?


Regards,
zunkree

Re: how to make private class member private

[bauss via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 11:08:27 UTC, psychoticRabbit wrote:
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven 
wrote:
It's a language design decision as to whether a particular 
feature is worth supporting. I would like this feature too 
though. I'm not sure how much compiler complexity would be 
added by having another visibility modifier.




D could add an new attribute to class members:  @deny

A @deny attribute can come before a classes private member, to 
indicate that the private member is to remain private, even 
within the module.


Cause sure, it nice to be among friends, but you don't want 
your friends knowing every thought that is going through your 
mind! Sometimes, somethings, just need to remain private.


@deny private string _userName;

now... _userName is no longer accessible at the module level, 
and class encapsulation is restored.


If had I any clue about compilers, I'd think this through more 
;-)


I don't like the name @deny, personally I would rather see the 
private attribute changed to something like:


private(true) // The member is oly visible to its parent.

private(false) // Same as just "private", visible to whole module.

Could be specialized to something like:

private(this) // Same as private(true)

private(module) // Same as private(false)

That way it can be introduced without breaking changes and looks 
cleaner since it wouldn't be yet another attribute.


Really it's just an extension to the already existing attribute.

This feature should be relatively easy to implement since it's 
similar to the "package" attribute, which also takes a value as 
the module name.

Disallowing the creation of objects using new should have default object functions and parent functions be @nogc by definition.

[12345swordy via Digitalmars-d]

It makes no sense otherwise. This logically implies that manual 
memory management is required, yet there is a possibility that 
the parent of the class may use the garbage collection. Which in 
this case, it begs the question on why the GC is forbid in the 
first place.


Does anyone dispute this?

[Issue 18624] New: getSymbolsByUDA produces wrong result if one of the symbols having the UDA is a function

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

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

  Issue ID: 18624
   Summary: getSymbolsByUDA produces wrong result if one of the
symbols having the UDA is a function
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: spoov0@gmail.com

The code

"""
enum Attr;
struct A
{
@Attr void a();
@Attr void a(int n);
  void b();
@Attr void c();
}

static assert(getSymbolsByUDA!(A, Attr).stringof == "tuple(a, a, c)");
"""

fails

--

Re: Vision document for H1 2018

[bauss via Digitalmars-d-announce]

On Friday, 16 March 2018 at 19:08:47 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/16/2018 02:35 PM, Tony wrote:

On Friday, 16 March 2018 at 15:04:21 UTC, Kagamin wrote:

On Thursday, 15 March 2018 at 16:03:14 UTC, rumbu wrote:
Are you sure that you are talking about phobos and not 
tango? :)

I'm eager to find how I'm uninformed.


Tango doesn't use UFCS, while phobos and .net framework are 
big on extension methods. Also tango uses object oriented 
console IO, while phobos and .net framework use procedural 
style for it.


I thought C# was like Java and does not allow free procedures. 
Can you give an example of C# procedural-style IO?




It doesn't (last I used it), buy you CAN mark individual member 
functions to be usable UFCS-like. IIRC, I think it might have 
to be static member function.


It's been awhile, so I don't remember it exactly, but it's 
something like this:


class Bar {}

class Foo {
static void SomeFunc(extention Bar bar, int num) {...}
}

class MyApp {
static void Run() {
Bar bar = new Bar();
bar.SomeFunc(2);
}
}


Actually it's like:

static void SomeFunc(this Bar bar, int num) { ... }

Re: User Stories: Funkwerk

[bauss via Digitalmars-d-announce]

On Friday, 16 March 2018 at 19:42:11 UTC, Rubn wrote:

On Wednesday, 14 March 2018 at 14:17:50 UTC, Mike Parker wrote:

foreach(auto element: elements)


":" is C++ syntax


Also "auto" can be omitted.

foreach (element; elements)

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[bauss via Digitalmars-d]

On Saturday, 17 March 2018 at 07:16:22 UTC, Jonathan M Davis 
wrote:
On Saturday, March 17, 2018 07:01:53 rumbu via Digitalmars-d 
wrote:

On Saturday, 17 March 2018 at 06:46:17 UTC, Uknown wrote:
  I haven't really noticed  any of what he

> mentions in the D community

3 days ago:

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


Unfortunately, we do periodically have folks act like that 
around here, but fortunately, for the most part, it's folks who 
don't stick around long, and our regular posters are generally 
well-behaved.


- Jonathan M Davis


This.

Most people around here are really nice :)

Re: D beyond the specs

[Arjan via Digitalmars-d]

On Friday, 16 March 2018 at 19:27:40 UTC, Walter Bright wrote:

On 3/16/2018 4:44 AM, Chris wrote:
Would it be possible to find out at DConf in Munich why 
exactly D is so popular in Germany (my impression) and in 
other countries of Europe (and that general post code) like 
France, Italy, GB, Romania and Russia etc.?


My old company's product, Zortech C++, was also very popular in 
Germany, England, and Japan. I don't know why.


And a certain spot in the Netherlands, because at the time it 
outperformed all the others like Borland Watcom IBM/visual-age 
ms-visual-c++ and others at compilation speed and most of the 
time in execution speed as well. Besides since we used multiple 
compiler on our code base symantec/digitalmars often reported 
violations were the other happily accepted the code (and produced 
wrong code) And the incident response time from you was just 
marvelous, reported an issue, next morning a fixed compiler 
version in the emailbox!


Beside that, I really appreciated the so called IDDE and 
accompanied srcs of libs. It was imo much much better than VC++ 
at the time. Have used it for a very long time even after 
Symantec ditched it. (borland f* up theirs by forcing the C++ 
builder upone us)

Re: how to make private class member private

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote:
It's a language design decision as to whether a particular 
feature is worth supporting. I would like this feature too 
though. I'm not sure how much compiler complexity would be 
added by having another visibility modifier.




D could add an new attribute to class members:  @deny

A @deny attribute can come before a classes private member, to 
indicate that the private member is to remain private, even 
within the module.


Cause sure, it nice to be among friends, but you don't want your 
friends knowing every thought that is going through your mind! 
Sometimes, somethings, just need to remain private.


@deny private string _userName;

now... _userName is no longer accessible at the module level, and 
class encapsulation is restored.


If had I any clue about compilers, I'd think this through more ;-)

Logging Function Parameters

[dom via Digitalmars-d-learn]

Hi,

I am looking for a method to log the current function name + 
parameters.
Getting the name of the current function is simply possible with 
__PRETTY_FUNCTION__
Is there some possibility to generically access the parameters of 
a function such that they can be iterated and printed out?


currently i have something like this:
log.info(__PRETTY_FUNCTION__,  " ", parameter1, " ", parameter2);

i would like to get to something like that:
log.info(__PRETTY_FUNCTION__,  " ", parameters.join(", "));

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[Joakim via Digitalmars-d]

On Saturday, 17 March 2018 at 07:01:53 UTC, rumbu wrote:

On Saturday, 17 March 2018 at 06:46:17 UTC, Uknown wrote:
 I haven't really noticed  any of what he

mentions in the D community


3 days ago:

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


That guy's some nutjob who only hangs out in the Learn forum, 
continually changing nicks and sometimes going off like that (I 
think I went off on one of his prior nicks), he basically has 
nothing to do with the D community.


He's no expert, as psychoRabbit says, merely a noob with some 
mental problems.

[Issue 18623] Documented unittest should not allow private symbol access

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

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

Alex  changed:

   What|Removed |Added

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

--

Re: Vision document for H1 2018

[Greatsam4sure via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 03/10/2018 05:47 AM, Dylan Graham wrote:

On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:


According to the State of D Survey, 71% of the respondents 
don't care about betterC. Why is betterC on the priority list?


Yeah. Why should D worry about tying itself into C when it 
can't even interface with itself through DLLs?


First of all, betterC is about far more than interfacing with 
C. In fact, interop with C isn't really what betterC is about 
at all - that's a separate aspect of the language. (And those 
C/C++ users who still haven't come to D - for many of them the 
holdout is *because* of the issues betterC aims to address. 
Make no mistake, for all the stockholm syndrome in the C and 
C++ worlds, there *are* a lot people openly wanting to jump 
ship but don't have a sufficient option yet. Heck, *I'm* a 
C/C++ -> D convert.)


But more importantly:

The D language itself is specifically designed and intended to 
be multi-purpose. Because of that, D users (and potential D 
users) are *highly* diverse. Everybody here has their own 
use-cases, their own needs and priorities, and their own list 
of things they want fixed yesterday.


In a group this diverse, there just simply *isn't* much on the 
D wishlist that's crucially important to a *majority*, because 
we all need completely different things.


Personally, better DLL support have little to no impact on me. 
Obviously it does for you, and I sympathise. Some of the things 
most important to me for D to improve you probably wouldn't 
care one bit about - and that's ok. We work on different sorts 
of things.


Improved betterC is something I would find very nice if I ever 
have time or opportunity to get back into embedded software. 
But outside of that, yea, it doesn't impact me much more than 
it does for you.


But here's the rub: In this crowd here, probably far more than 
most languages, we all have such wildly varying needs that 29% 
*is* what qualifies as significant around here. Most wishlist 
items are going to have similarly non-majority numbers. And 
they have to pick *something* to focus on. Luckily, as the 
vision document clearly states, there are *several* such 
"somethings" the dlang foundation is committing to working on.




The D language is a marvel. It just nice using it. It is a 
superior language.
It is pure joy programming in D. D language is mature enough to 
write up to 90% of all form of application. The problem I have 
seen thus far is the tools. The tools don't work especially on 
Windows.



The only working ide on Windows is visual-D but tied to visual 
studio. Personally don't like visual studio, it look to old for 
my likely. The plugin for eclipse,visual studio code and intellij 
are really lacking behind.



I having trying to setup code-d up in vs code for more than six 
months now to get auto completion but to no success. I have spent 
countless hours on the internet search for a solution but did not 
find any. I just get all kinds of errors. My next plane is to by 
a Linux system. So to me D is a beautiful language with no 
beautiful tools so not usable to me yet.


All you need to set up dmd on Windows is to download it and 
install.it is less than 2mins, you are good to go. Running your 
code in command line is painless with dub. But who want to write 
a millions of lines of code using plan text editors without code 
hinting, auto complete and superior debuging?


I love D language so much. The language is true mature now. Fix 
the following problem


* Get the plugin for intellij, eclipse and vs code working 
especially on Windows

* Proper documentation for the various packages and library
*Make installation process as easy as installing dmd
*Books that touch all capability of the D langauge with real like 
application. Programming in D is good but it must be enchance 
further



D language must be easy to program on all pupular ide. All you 
need to write c# code in vs code is just two or three extension. 
There is code hinting, auto complete etc. Why will I not use C# 
in vs code? I have no reason. Good language with good tools- 
anybody will give it a trier



Walter and all the team have done a good job. But give me more 
pride to sell D to all my colleagues. Programmers are known to be 
proud of their language, they must have very good reasons to 
switch. People switch from one languge to another because the new 
language just easy their pain.


All the members of the D community must come together and face 
really and work together to move the language further to make D 
the number one langauge which is what D supposed to be.



Working individually have move us here but working collectively 
will definitely make us the best. We must give people on all 
platform- windows, Mac, Linux,intellij,exclipse, netbeam,vs code, 
visual studio etc good reasons to use D besides the beaulty and 
power of the language.


Love D 

Re: D beyond the specs

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 17 March 2018 at 09:31:58 UTC, Ola Fosheim Grøstad 
wrote:
I don't know about compilers specifically, but the big 
distributors in Europe charged some hefty margins on their 
imports. So pricing in US was often much lower than here...


When I think of it, the distributors probably only cared about 
corporate customers for software development (and my impression 
is that distributors often didn't know much about computers and 
software anyway). Since distributors didn't know better they 
hired young computer enthusiasts to work for them, which cracked 
the software protections and spread it among their friends before 
the software hit the stores...


So European computer enthusiasts had easy access to bootleg 
copies of common software. Copying was rampant for cultural 
reasons, which included common fair use clauses that allowed 
copying between individuals and friends. By rampant, I mean 
people copied >90% of the software they used.


I knew of more people that bought "alternative dev tooling" (at 
reasonable pricing) than the offerings  from big players (which 
often would cost more than the computer hardware, and as a 
recurring cost...). There was also an attitude that "if the price 
is unreasonable high then it is perfectly reasonable and moral to 
distribute bootleg copies of it".

Re: how to make private class member private

[Nick Treleaven via Digitalmars-d-learn]

On Tuesday, 13 March 2018 at 13:59:00 UTC, Steven Schveighoffer 
wrote:
If you limit to class members, then you have to do something 
like C++ friends, which are unnecessarily verbose.


Not if you also have a module-level visibility modifier, which 
could have been `module`.


IMO, the module-level encapsulation is the right choice. It 
helps with a lot of key features:


1. IFTI factory methods


Aren't these mainly because constructors can't use IFTI, unlike 
C++17, and because nullary struct constructors are banned?



2. unittests


Documented unittests should not be allowed to use private 
symbols, I just filed this:

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

[Issue 18623] New: Documented unittest should not allow private symbol access

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

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

  Issue ID: 18623
   Summary: Documented unittest should not allow private symbol
access
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

private int i;

///
unittest
{
i++;
}

`i` is not visible outside the module, so it should not appear in public
documentation about how to use the module.

--

Re: D beyond the specs

[Thomas Mader via Digitalmars-d]

On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote:
Would it be possible to find out at DConf in Munich why exactly 
D is so popular in Germany (my impression) and in other 
countries of Europe (and that general post code) like France, 
Italy, GB, Romania and Russia etc.?


My guess is that it has much to do with simple luck.
It's like getting those Goldilock conditions. What I mean by that 
is described in the first couple minutes of this TED talk: 
https://www.ted.com/talks/david_christian_big_history


In communities those Goldilock conditions are not of physical 
nature but of social nature I guess.
For a movement/idea/programming language/... to grow big, it 
seems to be important to get the right people into it. The people 
who are that passionate about it that they put much afford into 
it to convince other people of the value of this new thing. The 
ones who are best candidates for something like that are the ones 
who are very communicative and have a large social net to 
popularize their things on.


What might have happend in Germany is exactly that. The starters 
of companies like Funkwerk, Sociomantic and the like saw value in 
D and decided to use it heavily. They were able to create a 
Goldilock condition by their use and gathered more people around 
it.
If you have more people it's more likely to get even bigger 
because the possibility of another even bigger Goldilock is 
increased. More people mean more connections to other people and 
the thing goes on and on.

In the US it was just not that lucky yet.

For sure there are technical facts to consider but if you follow 
trends, it doesn't always seem to be the crucial factor to choose 
something over the other in technical things.


So finding and convincing or at least introduce such important 
people to your new thing might always be the key thing to do.

Re: D beyond the specs

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 16 March 2018 at 22:43:57 UTC, Chris wrote:
Most interesting! I'm not kidding. Is it 'wow it's from the 
US', or something else? Genuine question. I ain't asking for 
fun. There's more to business and technology than meets the eye.


I don't know about compilers specifically, but the big 
distributors in Europe charged some hefty margins on their 
imports. So pricing in US was often much lower than here...


So smaller competitors with ads in national hobbyist computing 
mags had a relatively easy marketing channel.

Re: how to make private class member private

[Nick Treleaven via Digitalmars-d-learn]

On Tuesday, 13 March 2018 at 05:11:48 UTC, psychoticRabbit wrote:
If you have access to the module source, you have access to 
the source of types inside it. Making the module the lowest 
level of encapsulation makes sense from that perspective.


There are two problems I see:

1st - D has broken the concept of class encapsulation, simply 
for convenience at the module level. Not good in my opinion.


It's a language design decision as to whether a particular 
feature is worth supporting. I would like this feature too 
though. I'm not sure how much compiler complexity would be added 
by having another visibility modifier.


I'm surprised how many people here ignore the advantage of being 
able to modify your class/struct fields without the chance of 
breaking template code that might not even be instantiated by a 
unit test. (And no, the answer to this isn't fix your tests, 
because if that's your attitude, why bother with static typing, 
just use duck typing, the unit tests will catch any bugs). In 
theory this and other generic unit test issues could be 
comprehensively solved by having a Rust-like traits feature.


2nd - C++/C#/Java programmers will come to D, use the same 
syntax, but get very different semantics. Not good in my 
opinion. (i.e. I only realised private was not private, by 
accident).


D has made many good design decisions. I do not see this as one 
of them.


+1, D should have used a different keyword, such as `module`. It 
is a classic source of confusion for programmers familiar with 
many statically typed languages, and it comes up regularly here. 
It is a syntax issue, semantically the feature is better than 
just having true private.

Re: D beyond the specs

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 16 March 2018 at 22:25:50 UTC, jmh530 wrote:
This sort of analysis applies to programming languages in 
exactly the same way. If I'm a company, do I build products 
using language X or language Y. If I'm a person, do I spend N 
hours learning language X or language Y (or do the next best 
thing you can do...March Madness?). What if I already know 
language X? Then it's pure marginal cost to learn language Y.


For me I'd say learning the language is the low cost. The high 
cost is in finding the tooling, the eco system, maintaining the 
configuration and being sure that it is supported over time and 
that it can target the platform I am likely to be interested in 
(now and an in the future).


So, I write toy programs for new languages to see what they are 
like out of curiosity, but I am not likely to adopt any language 
that doesn't have a dedicated IDE. I'm not interested in taking a 
hit on tooling-related costs.


That last part has actually makes me reluctant to adopt Rust, 
Dart and Angular. So I'd say the threshold for moving from 
"non-critical" usage to "critical" usage is quit high.


On the other hand I have a lot less resistance to adopting 
TypeScript, since it is a fairly thin layer over Javascript. Thus 
I can easily move away from it if it turns out to be limiting 
down the road.


C programmers don't just switch to D or Rust or whatever the 
moment they see it has some "technical" features that are 
better. That's not what we observe. The marginal benefit has to 
exceed the marginal cost.


Actually, I'd say no marginal benefit is worth moving away from a 
platform with quality tooling.


So you have to win on productivity and performance (memory, 
portability, speed).

Re: D beyond the specs

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 17 March 2018 at 08:48:45 UTC, Ola Fosheim Grøstad 
wrote:
Anyway, cultural change is slow. Even though the 70s is far 
away, it still probably has an effect on culture and attitudes 
in universities and the tech sector.


In the late 80s I was quite surprised that Danish computing mags 
(for hobbyists) wrote a lot about a language I had never heard of 
before:


https://en.wikipedia.org/wiki/COMAL

I am sure there has been other similar trends in other European 
countries.

Re: D beyond the specs

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 16 March 2018 at 14:50:26 UTC, Paulo Pinto wrote:
Well, Algol, Pascal, Oberon, Component Pascal, VHDL, Ada are 
all examples of programming languages successfully used in 
Europe, while having adoption issues on US.


There are some historical roots, I believe. In the 60s and 70s 
computing was so expensive that government funding was a driving 
force. Since each nation then also wanted to have their own 
computing industry they favour national companies (and thus 
employment), so each nation had their own CPU/hardware 
architecture and eco system. And Europe has many many nations... 
So quite a heterogenous computing environment... :-P


The US has a much bigger internal market and some key big players 
early on ("nobody has been fired for picking IBM"). They also 
have many large corporation that could sustain the cost of 
establishing a commercial computing sector.


Not sure how that works out today, though, as there is no longer 
a strong focus on national computing industries (unless you count 
Apple and Microsoft as such). Asia has run away with the hardware 
and development software has become less and less 
proprietary/national each decade.


My perception is that there is a difference between academic 
research oriented institutions and more rural engineering 
institutions. The former would focus more on language qualities 
(surprisingly University of Oslo is now switching from Java to 
Python, probably because it used a lot in data analysis), while 
the latter would focus more on business marketable languages 
(C++).


Anyway, cultural change is slow. Even though the 70s is far away, 
it still probably has an effect on culture and attitudes in 
universities and the tech sector.


Also, since most applications are no longer CPU bound there 
should be much more opportunity for trying new options today than 
10-20 years ago.

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[psychoticRabbit via Digitalmars-d]

On Saturday, 17 March 2018 at 07:16:22 UTC, Jonathan M Davis 
wrote:


Unfortunately, we do periodically have folks act like that 
around here, but fortunately, for the most part, it's folks who 
don't stick around long, and our regular posters are generally 
well-behaved.


- Jonathan M Davis


yeah I agree 100%

the people that actually know stuff around here, are NOT the 
people that treat others badly.


I have certainly worked in environments where the opposite is 
true. I usually left them pretty quickly. Life is short.


I've also trained sysadmins myself, and I can say, that holding 
back the sarcasm takes a real personal committment - to just not 
doing it.


Once you make that committment, it becomes easier and 
easier...and soon enough, you're back to treating people the way 
they deserve to be treated.


ultimately, its a personal choice, to treat people properly, or 
not.


I don't think it's a 'community' thing. treating people properly 
is not dependent on any sense of being in a 'community'. so here 
I differ with the view in that article.


(having said that, not all sarcasm is meant to offend. the best 
of friends can throw sarcasm at each other, and still be the best 
of friends).

Re: Convert output range to input range

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, March 17, 2018 06:58:04 Dukc via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 08:07:09 UTC, Jonathan M Davis wrote:
> > For instance, std.array.Appender is an output range, and you
> > get a dynamic array out of it, which would be an input range.
> > So, if you have control over what output range you're dealing
> > with, the simplest would be to just use Appender.
>
> I think it's worth warning that appending on an array may
> invalidate all copies of it. Meaning that you should not append
> on an array while you're iterating over it, unless iterating by
> the original copy of the array. Note that foreach loop copies the
> range by default. Pass refRange(*array) to foreach instead.

Appending to a dynamic array doesn't invalidate anything. It just results in
a new buffer being allocated and the dynamic array being changed to point to
it instead of the dynamic array does not have enough capacity to append in
place. Any other dynamic arrays which were slices of the previous buffer
still refer to it and are perfectly valid.

Yes, if you want to treat a dynamic array as a reference type, it's not
going to work to simply pass around a dynamic array, because dynamic arrays
are pseudo-reference types and not reference types, and if you want a
reference type, you're going to have to wrap the dynamic array in another
type, but the fact that they're pseudo-reference types does not mean that
anything is invalidated when appending.

Now, doing something like iterating over a dynamic array with a foreach loop
and then appending to it in that same loop means that you're really
operating on two dynamic arrays, because the loop is slices the dynamic
array and is thus iterating over another dynamic array which (at least
initially) refers to the same memory, and the appending that you're doing
won't affect it. So, you do have to be careful about appending while
iterating if you really want to be appending to the same dynamic array that
you're iterating over, but everything involved will be valid regardless. It
just may not have the behavior you want, because the dynamic array has been
sliced.

In any case, based on the OP's question, it was my assumption that they
intended to fully write to the output range and then operate on the results
as on input range, which then has none of the problems associated with
trying to put while you pop. If they want to put while they're popping, then
things get far more complicated, and a dynamic array is probably not the
best solution whether Appender is used or not.

- Jonathan M Davis

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 17, 2018 07:01:53 rumbu via Digitalmars-d wrote:
> On Saturday, 17 March 2018 at 06:46:17 UTC, Uknown wrote:
>   I haven't really noticed  any of what he
>
> > mentions in the D community
>
> 3 days ago:
>
> https://forum.dlang.org/post/ylngefsfuwqodaprw...@forum.dlang.org

Unfortunately, we do periodically have folks act like that around here, but
fortunately, for the most part, it's folks who don't stick around long, and
our regular posters are generally well-behaved.

- Jonathan M Davis

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[psychoticRabbit via Digitalmars-d]

On Saturday, 17 March 2018 at 07:01:53 UTC, rumbu wrote:


3 days ago:

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


yeah...but that presumes Amorphorious is an 'expert programmer'.

which is not the impression I got ;-)

Re: OT: Behaviour of Experienced Programmers Towards Newcomers

[rumbu via Digitalmars-d]

On Saturday, 17 March 2018 at 06:46:17 UTC, Uknown wrote:
 I haven't really noticed  any of what he

mentions in the D community


3 days ago:

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

Re: Convert output range to input range

[Dukc via Digitalmars-d-learn]

On Friday, 16 March 2018 at 08:07:09 UTC, Jonathan M Davis wrote:
For instance, std.array.Appender is an output range, and you 
get a dynamic array out of it, which would be an input range. 
So, if you have control over what output range you're dealing 
with, the simplest would be to just use Appender.


I think it's worth warning that appending on an array may 
invalidate all copies of it. Meaning that you should not append 
on an array while you're iterating over it, unless iterating by 
the original copy of the array. Note that foreach loop copies the 
range by default. Pass refRange(*array) to foreach instead.

OT: Behaviour of Experienced Programmers Towards Newcomers

[Uknown via Digitalmars-d]

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

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