Re: Lazy caching map | Mir version

[9il via Digitalmars-d]

On Friday, 9 March 2018 at 19:41:46 UTC, H. S. Teoh wrote:
Today I found myself needing a lazy, caching version of map() 
on an array.  More precisely, given an array `T[] src` of 
source data and a function func(T) that's pretty expensive to 
compute, return an object `result` such that:


- result[i] == func(src[i]), for 0 ≤ i < src.length.

- If result[j] is never actually used, func(src[j]) is never 
invoked

  (lazy).

- If result[j] is referenced multiple times, a cached value is 
returned
  after the first time, i.e., the result of func(src[j]) is 
cached, and

  func(src[j]) is never invoked more than once.

Can this be done using current Phobos primitives?


T


Phobos implementation based on memoize would use hash map 
internally, which is slow for this use case.


mir-algorithm v0.9.5 (DUB would be updated soon) got `cached` and 
`cachedGC` topologies.


Example:

// Mir's map is required
import mir.ndslice: cachedGC, map, sliced;

auto ar = new int[5];
// init ar ...
auto cachedLazyMap = ar.map!fun.cachedGC;

`cachedGC` [1] internally allocates a vector of caches and a 
packed bitarray.


`cached` [2] allows to reuse already allocated buffers.

The result support all random access range primitive, slicing and 
etc.


ndslice architecture allows to add new random access topologies 
very easily.


[1] 
http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#.cachedGC
[2] 
http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#.cached


Best regards,
Ilya Yaroshenko

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 04:15:26 UTC, rikki cattermole wrote:

On 19/03/2018 5:05 PM, Norm wrote:
On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole 
wrote:

On 19/03/2018 4:43 PM, Norm wrote:
On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
wrote:


Did they at any point tell us that it was a blocker for 
your company who was trialing D?


Because I do not remember once in that time period of any 
one saying this.


Walter has gone out of his way in the past to help 
companies, even flying to them on his own dime.


If you want to be treated special, we need to have a reason 
for you to be treated special, otherwise you're just like 
everybody else complaining without giving back.


We don't want to be treated special. We don't want to give 
back. This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to 
submit PRs or get special treatment from Walter to use it 
effectively? Sorry, but this is why many feel that D is 
still just a hobby project.


We are an organisation trying to get work done. D was a 
potential replacement of our existing C++/Python tool chain. 
Unfortunately it *requires* us to give back, which as I 
stated is not our business. Our business is the development 
of medical devices and supporting application software, not 
compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to 
recently licensed so that you may not use it for this 
purpose. Nothing has changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?


The code generation capabilities of dmd has not been certified 
for medical usage.


In essence, if it generated bad code, kills somebody, your the 
one at fault, even if the source is fine. You would end up 
begging to settle out of court.


It is my understanding that medical software manufacturers pay 
for their compilers already certified. So that suggests to me 
that you're not exactly life threatening but I would still 
caution you away from D even if that bit is just my own opinion.


No, compilers do not need to be certified for class B or class C 
software. These are the two highest safety classes for medical 
SW. Beyond class C SW is not allowed, e.g. safety critical 
interlocks such as the big red button to shut off a radiation 
dose or stop a robotic system.


Compilers are are treated as SOUP (Software of Unknown 
Provenance), i.e. a black box. Risk analysis leads to risk 
control measures that in turn ensure people don't die and this is 
done at the system and component level, not the codegen level. 
Verification is performed to ensure the system implements the 
requirements correctly, and subsequently the risk control 
measures. Not all requirements are risk control measures, but all 
requirements must be verified as correct.


Cheers,
Norm

Re: CTFE ^^ (pow)

[bachmeier via Digitalmars-d]

On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:

Or hire staff who are paid to work on 'boring' issues. I would 
make regular donations if I could be satisfied that my decade 
old issues would be addressed. I wonder how many others would 
too?


That's actually possible now for corporate sponsors, though it 
takes a fair chunk of change, but you get 3 bug fixes a month: 
https://opencollective.com/dlang#budget


My understanding is that more options will be made available 
later.

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 5:23 PM, Jonathan M Davis wrote:

On Monday, March 19, 2018 17:15:26 rikki cattermole via Digitalmars-d wrote:

On 19/03/2018 5:05 PM, Norm wrote:

On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to recently
licensed so that you may not use it for this purpose. Nothing has
changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?


The code generation capabilities of dmd has not been certified for
medical usage.

In essence, if it generated bad code, kills somebody, your the one at
fault, even if the source is fine. You would end up begging to settle
out of court.

It is my understanding that medical software manufacturers pay for their
compilers already certified. So that suggests to me that you're not
exactly life threatening but I would still caution you away from D even
if that bit is just my own opinion.


It may be there are compilers certified for that sort of thing (I'm
certainly no expert on the subject), but AFAIK, basically every compiler
ever says that it's not certified or guaranteed for anything, because the
compiler writers don't want to get sued if something goes wrong regardless
of what you're using it for.

- Jonathan M Davis



Here is clang's[0], nothing about medical. Just you can't sue us when it 
goes wrong.


Compare against[1], clearly its a big deal safety wise. This is why I 
will say specifically even for D that I love, do not use it here.


[0] http://releases.llvm.org/2.8/LICENSE.TXT
[1] 
https://developer.arm.com/products/software-development-tools/compilers/arm-compiler/safety

Re: CTFE ^^ (pow)

[nkm1 via Digitalmars-d]

On Monday, 19 March 2018 at 02:56:32 UTC, Norm wrote:

+1024 bytes

I think D is a terrific language worthy of all the praise it 
gets and it is way way more stable than it was 3yrs ago. But 
the attitude of submit a PR if you want it fixed works very 
much against D. Like it or not these forums are a front page on 
the D marketing campaign.


But do you know that? Maybe without that attitude fewer PRs would 
have been submitted. Perhaps that attitude works, just doesn't 
work well enough for your purposes. But maybe without that 
attitude D would've been even less suitable for you?


a) We're not in the business of developing and maintaining D, 
but it seems that is what we would need to do as a company. We 
are better off with C++ and Python.


b) D feels like C++ did back in the mid 90's. A time when we 
avoided templates and often the STL because compiler 
implementations were too buggy. We are better off with C++ and 
Python.


So you rejected D because of compiler bugs, missing tools, etc., 
not because of nasty attitude of some people on the forums? Fair 
enough, and it's entirely possible that DMD (or whatever) is not 
good enough for you, but what makes you think that improving the 
attitude would do anything to fix bugs? Only PRs can do that.


Anyway, as far as I can tell, when people answer to complainers 
"send a PR or GTFO", they're just telling it like it is. Ignoring 
the reality won't make it stop being the objective state of 
affairs.


D claims to be "Industry Proven and Ready" but we have to 
submit PRs
or get special treatment from Walter to use it effectively? 
Sorry, but

this is why many feel that D is still just a hobby project.


D doesn't "claim" anything, it's just a programming language. 
Some people claim some things, it's your job to determine how 
true their propaganda is.
Also, what is wrong or unworthy about hobby projects? Pretty sure 
my hobby (which is not hacking on DMD) is a lot more important 
(to me) than your medical company ;)

Re: The D Language Foundation at Open Collective

[Tony via Digitalmars-d-announce]

On Monday, 19 March 2018 at 03:12:52 UTC, Nick Sabalausky 
(Abscissa) wrote:


(And McDonalds $1/large thing seems to have gone away, I think 
it was just a temporary promotion. At least around here, anyway 
(Cleveland area, in the US)).


Still doing it in the Northern California McDonalds near me. $1 
for a large soda too.



I'll never understand the whole "pour over" coffee movement.


There is a coffee chain that started in San Francisco, Philz 
Coffee, which specializes in pour over coffee, and is now up to 
42 locations. It is popular, and pour over and popular means an 
excellent chance you end up waiting in a significant line, but a 
lot of people don't seem to mind. I even wonder if it adds to the 
experience, making the product seem more valuable. However, 
someone must not like the wait because I read an article recently 
that mentioned some upscale coffee places were going back to 
using machines. I believe they only mentioned the time factor, 
but it is also labor intensive to manually pour the water.

[Issue 18534] Wrong code for ?: operator when compiling with -O

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8052

--

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

On Monday, March 19, 2018 17:15:26 rikki cattermole via Digitalmars-d wrote:
> On 19/03/2018 5:05 PM, Norm wrote:
> > On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:
> >> You just said the magic word, medical.
> >>
> >> D was never an appropriate fit here.
> >>
> >> dmd's backend has been for thirty years (or so) been up to recently
> >> licensed so that you may not use it for this purpose. Nothing has
> >> changed here.
> >
> > I have no idea what you're talking about now.
> >
> > What has the backend license got to do with medical?
>
> The code generation capabilities of dmd has not been certified for
> medical usage.
>
> In essence, if it generated bad code, kills somebody, your the one at
> fault, even if the source is fine. You would end up begging to settle
> out of court.
>
> It is my understanding that medical software manufacturers pay for their
> compilers already certified. So that suggests to me that you're not
> exactly life threatening but I would still caution you away from D even
> if that bit is just my own opinion.

It may be there are compilers certified for that sort of thing (I'm
certainly no expert on the subject), but AFAIK, basically every compiler
ever says that it's not certified or guaranteed for anything, because the
compiler writers don't want to get sued if something goes wrong regardless
of what you're using it for.

- Jonathan M Davis

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 5:05 PM, Norm wrote:

On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

On 19/03/2018 4:43 PM, Norm wrote:

On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:


Did they at any point tell us that it was a blocker for your company 
who was trialing D?


Because I do not remember once in that time period of any one saying 
this.


Walter has gone out of his way in the past to help companies, even 
flying to them on his own dime.


If you want to be treated special, we need to have a reason for you 
to be treated special, otherwise you're just like everybody else 
complaining without giving back.


We don't want to be treated special. We don't want to give back. This 
is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to submit PRs 
or get special treatment from Walter to use it effectively? Sorry, 
but this is why many feel that D is still just a hobby project.


We are an organisation trying to get work done. D was a potential 
replacement of our existing C++/Python tool chain. Unfortunately it 
*requires* us to give back, which as I stated is not our business. 
Our business is the development of medical devices and supporting 
application software, not compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to recently 
licensed so that you may not use it for this purpose. Nothing has 
changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?


The code generation capabilities of dmd has not been certified for 
medical usage.


In essence, if it generated bad code, kills somebody, your the one at 
fault, even if the source is fine. You would end up begging to settle 
out of court.


It is my understanding that medical software manufacturers pay for their 
compilers already certified. So that suggests to me that you're not 
exactly life threatening but I would still caution you away from D even 
if that bit is just my own opinion.

Re: D for Android beta

[Joakim via Digitalmars-d-announce]

On Wednesday, 30 August 2017 at 07:09:05 UTC, Joakim wrote:

On Saturday, 26 August 2017 at 09:59:33 UTC, Joakim wrote:

On Thursday, 1 June 2017 at 19:45:17 UTC, Ali Çehreli wrote:

Very exciting! :)

On 06/01/2017 12:31 PM, Joakim wrote:

> I will write up instructions on how to write an Android app
in D _on_
> your Android device

I hope it will be detailed enough for people who are very new 
to programming on the Android.


Ali


I've finally written up full instructions on building D apps 
for Android by using the linux cross-compiler or native 
Android compiler I provide:


https://wiki.dlang.org/Build_D_for_Android

The upcoming ldc 1.4 beta will be the first to include Android 
cross-compilation support for all supported host platforms, ie 
Windows, Mac, and linux, as all my Android patches have now 
been merged.  I'll stop putting out my own cross-compiler 
builds, though I'll maintain the native ldc package in the 
Termux package repo, once that's accepted.


If you want to build full OpenGLES GUI Android apps on your 
Android device, this wiki page shows you how to do that too.  
You too can be one of the elite few building mobile apps on 
your mobile device, and in D!


And there is now an ldc package in the Termux Android app, 
updated the wiki page to show how simple it is to install ldc 
on your Android device now:


https://wiki.dlang.org/Build_D_for_Android#Native_compilation_2

Make sure to tell everyone you know how easy it is to write D 
on your Android smartphone or tablet now, just like the Go 
people have been enjoying:


https://mobile.twitter.com/mattbostock/status/896923877711814657

The Termux twitter highlights those now happy about using Node, 
Clojure, or Scala on their Android phone, hopefully D is next:


https://mobile.twitter.com/termux

Next up, getting D working on 64-bit ARM devices, which I 
recently got access to.  David has been working on it already, 
hope we can get that done by ldc 1.5:


https://github.com/ldc-developers/ldc/issues/2153


I've updated the wiki page with instructions for cross-compiling 
from macOS:


https://wiki.dlang.org/Build_D_for_Android#Mac

I forgot to mention in here that I added instructions for Windows 
six months back.


I'm looking at 64-bit AArch64 support, where pretty much all the 
druntime tests pass with ldc 1.8 because of the great work of 
David, Kai, and others. The few failures are likely related to 
emulated TLS not being tied into the GC yet. I'll be working on 
this port this week.

Re: CTFE ^^ (pow)

[Danni Coy via Digitalmars-d]

The volunteer line is fine for big picture stuff that is going to require a
lot of work and planing to get right. Using that for smaller feature
requests is going to give the impression that D is lacking in the technical
expertise to get anything done, It's often a sign that an open source
project is dying. I don't think anybody wants that.

On the other hand take a little time to try and get your point accross
without being unnecessarily confrontational. Not because you aren't right
but because it takes less time than rehashing these conversations and I
know for a fact that some of you have way more productive things to do with
your time than this ;)

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote:

On 19/03/2018 4:43 PM, Norm wrote:
On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole 
wrote:


Did they at any point tell us that it was a blocker for your 
company who was trialing D?


Because I do not remember once in that time period of any one 
saying this.


Walter has gone out of his way in the past to help companies, 
even flying to them on his own dime.


If you want to be treated special, we need to have a reason 
for you to be treated special, otherwise you're just like 
everybody else complaining without giving back.


We don't want to be treated special. We don't want to give 
back. This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to 
submit PRs or get special treatment from Walter to use it 
effectively? Sorry, but this is why many feel that D is still 
just a hobby project.


We are an organisation trying to get work done. D was a 
potential replacement of our existing C++/Python tool chain. 
Unfortunately it *requires* us to give back, which as I stated 
is not our business. Our business is the development of 
medical devices and supporting application software, not 
compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to 
recently licensed so that you may not use it for this purpose. 
Nothing has changed here.


I have no idea what you're talking about now.

What has the backend license got to do with medical?

D would be a great fit for medical with its @safe, pure and GC.

Supporting application software is standard desktop development. 
Some of these applications are for production and testing and the 
rest are normal end-user Windows desktop?


We also develop mobile applications but we didn't consider D for 
that role.


Cheers,
Norm

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 4:43 PM, Norm wrote:

On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:


Did they at any point tell us that it was a blocker for your company 
who was trialing D?


Because I do not remember once in that time period of any one saying 
this.


Walter has gone out of his way in the past to help companies, even 
flying to them on his own dime.


If you want to be treated special, we need to have a reason for you to 
be treated special, otherwise you're just like everybody else 
complaining without giving back.


We don't want to be treated special. We don't want to give back. This is 
the *entire* point.


D claims to be "Industry Proven and Ready" but we have to submit PRs or 
get special treatment from Walter to use it effectively? Sorry, but this 
is why many feel that D is still just a hobby project.


We are an organisation trying to get work done. D was a potential 
replacement of our existing C++/Python tool chain. Unfortunately it 
*requires* us to give back, which as I stated is not our business. Our 
business is the development of medical devices and supporting 
application software, not compiler or language development.


You just said the magic word, medical.

D was never an appropriate fit here.

dmd's backend has been for thirty years (or so) been up to recently 
licensed so that you may not use it for this purpose. Nothing has 
changed here.

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 03:14:51 UTC, rikki cattermole wrote:


Did they at any point tell us that it was a blocker for your 
company who was trialing D?


Because I do not remember once in that time period of any one 
saying this.


Walter has gone out of his way in the past to help companies, 
even flying to them on his own dime.


If you want to be treated special, we need to have a reason for 
you to be treated special, otherwise you're just like everybody 
else complaining without giving back.


We don't want to be treated special. We don't want to give back. 
This is the *entire* point.


D claims to be "Industry Proven and Ready" but we have to submit 
PRs or get special treatment from Walter to use it effectively? 
Sorry, but this is why many feel that D is still just a hobby 
project.


We are an organisation trying to get work done. D was a potential 
replacement of our existing C++/Python tool chain. Unfortunately 
it *requires* us to give back, which as I stated is not our 
business. Our business is the development of medical devices and 
supporting application software, not compiler or language 
development.


IMO most of D is close enough, but I am a convert and geek. Most 
of my fellow developers are not.


Cheers,
Norm

[Issue 18199] Error with lambda in struct initializer

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

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

--- Comment #8 from John Belmonte  ---
https://github.com/dlang/dmd/pull/8051

--

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 19:56, Norm via Digitalmars-d
 wrote:
> On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
>>
>> On 18 March 2018 at 17:28, Joakim via Digitalmars-d
>>  wrote:
>>>
>>>
>>> Perhaps the community simply has different priorities than you? For
>>> example, my Android port has never gotten much use either, which is fine as
>>> I primarily did that work for myself.
>>>
>>> Nevertheless, you have to think of D as like working in a startup: if you
>>> see something that you think needs doing, you have to drive it yourself or
>>> it will never get done. Pretty much the same for most any OSS project too.
>>
>>
>> This is such an easy and readily-deploy-able response here.
>> What you say is true, and I totally understand this... but at the same
>> time, that's not actually the relationship I want to have with my
>> tool. A startup probably shouldn't still be a startup 10 years later.
>>
>> In your case, doing the android work was obviously an interest you had
>> on the side, and you gain something from the work itself.
>> I have a small amount of that, but that's not where I'm at, and it
>> never has been. I want to use D to do my job, because I'm fed up with
>> C++. I want to engage in D the way I think D should **EXPECT** it's
>> users to engage in D; as an end-user, who uses the tool to get their
>> jobs done.
>> If D is a large-ish scale hobby project among a bunch of people with
>> mutual interests, then that should be more clearly communicated, but I
>> don't think that's the intent, and I feel perfectly fine interacting
>> with D in the way D is intended to be interacted with.
>>
>> Incidentally, this particular work I'm doing is on a multimedia library
>> intended for the community... so I really am truly trying to contribute
>> something of value!! But like most of my projects, I tend to get blocked at
>> some point, and then it goes on hold indefinitely.
>
>
> +1024 bytes
>
> I think D is a terrific language worthy of all the praise it gets and it is
> way way more stable than it was 3yrs ago. But the attitude of submit a PR if
> you want it fixed works very much against D. Like it or not these forums are
> a front page on the D marketing campaign.
>
> My workplace has stopped using D after a 6 month trial, which finished in
> Jan 2018. Several developers did post here during that period when blocked
> by a bug or incomplete feature, only to be told if they want it fixed they
> can always submit a PR.
>
> Inevitably when told this they simply dropped D and went back to C++ and
> Python. And they made a point to bring this experience up at the final
> go/no-go meeting.
>
> The majority of developers, including those voting for D, had these common
> opinions (much to my disappointment)
>
> a) We're not in the business of developing and maintaining D, but it seems
> that is what we would need to do as a company. We are better off with C++
> and Python.
>
> b) D feels like C++ did back in the mid 90's. A time when we avoided
> templates and often the STL because compiler implementations were too buggy.
> We are better off with C++ and Python.
>
>
> I keep pushing D here but now it is a bit of a joke when I bring it up. I've
> become "the D guy" and it isn't discussed seriously any more by other
> developers, except a select few.

I know these feels so well.
People take their one experience, and that's the truth on the matter.
The sad part is, it's actually a massive missed opportunity! If these
colleagues posted here, and instead were greeted by recognition of
their issue, and provided a satisfactory work-around, or even a prompt
fix, they would have taken a COMPLETELY different message away from
their interaction; it would be "this D comunity is so awesome, I can
have confidence that our issues will be handled in a personalised
way!", and there's very strong value in that for a business...

Re: how to make private class member private

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer 
wrote:


If we could go back in time and talk with a young Walter about 
the consequences of choosing the scheme the way it is, maybe he 
might have made different choices, but at this point, it's hard 
to change it.




I think this highlights the real problem with D.

Power is too centralised, and kinda arbitrary.

I'm going back to Java ;-)

Re: The D Language Foundation at Open Collective

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

On 03/18/2018 04:18 PM, Tony wrote:

On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote:



Sorry to derail, but I had to ask: where does 1 coffee (even extra 
large) cost $5 USD? Let me know so I know to never move there.


I have seen regular coffee at $4.50 and as high as $5.50 in the USA (and 
not always a large), but in order to get there, it has to be "single cup 
pour over" made, as opposed to coming out of a machine into a pot. And 
the beans have to be organic or they are telling you exactly where they 
were grown and giving you alleged "flavor notes" and maybe they roasted 
them in-house or locally, and the place has to have an upscale or luxury 
vibe. But Starbucks in the USA gives you a 20oz out-of-a-machine for 
under $3. McDonald's beats everybody - $1 for a large. Although I am not 
a big fan of the McDonalds coffee (maybe psychological due to the low 
price). 7/11 convenience stores and Chevron gas stations both have 
several varieties of coffee on tap that they sell for under $2 for a 
large, that I think tastes good.


McDonald's and Wendy's both have pretty good coffee, but the catch is 
they often let it sit around far too long, at which point it can get 
pretty bad. So it's kind of coffee roulette. (And McDonalds $1/large 
thing seems to have gone away, I think it was just a temporary 
promotion. At least around here, anyway (Cleveland area, in the US)).


I'll never understand the whole "pour over" coffee movement. It's 
basically the same exact technique everyone's the cheap consumer level 
coffee machine already does far more conveniently: Hot water poured over 
coffee grounds sitting in a filter. I've been to one of those pour over 
places, and it was mediocre at best (not to mention slow and expensive). 
I've had better coffee from fast food joints. But then again, I've never 
been very hipster-compatible ;) There's a couple (non-fast food) chains 
we have around here, Panera and Arabica, that make some of the best 
coffee I've ever had, without doing the whole pour-over fad, for about $2.

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 3:56 PM, Norm wrote:

On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 wrote:


Perhaps the community simply has different priorities than you? For 
example, my Android port has never gotten much use either, which is 
fine as I primarily did that work for myself.


Nevertheless, you have to think of D as like working in a startup: if 
you see something that you think needs doing, you have to drive it 
yourself or it will never get done. Pretty much the same for most any 
OSS project too.


This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at the same
time, that's not actually the relationship I want to have with my
tool. A startup probably shouldn't still be a startup 10 years later.

In your case, doing the android work was obviously an interest you had
on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and it
never has been. I want to use D to do my job, because I'm fed up with
C++. I want to engage in D the way I think D should **EXPECT** it's
users to engage in D; as an end-user, who uses the tool to get their
jobs done.
If D is a large-ish scale hobby project among a bunch of people with
mutual interests, then that should be more clearly communicated, but I
don't think that's the intent, and I feel perfectly fine interacting
with D in the way D is intended to be interacted with.

Incidentally, this particular work I'm doing is on a multimedia 
library intended for the community... so I really am truly trying to 
contribute something of value!! But like most of my projects, I tend 
to get blocked at some point, and then it goes on hold indefinitely.


+1024 bytes

I think D is a terrific language worthy of all the praise it gets and it 
is way way more stable than it was 3yrs ago. But the attitude of submit 
a PR if you want it fixed works very much against D. Like it or not 
these forums are a front page on the D marketing campaign.


My workplace has stopped using D after a 6 month trial, which finished 
in Jan 2018. Several developers did post here during that period when 
blocked by a bug or incomplete feature, only to be told if they want it 
fixed they can always submit a PR.


Did they at any point tell us that it was a blocker for your company who 
was trialing D?


Because I do not remember once in that time period of any one saying this.

Walter has gone out of his way in the past to help companies, even 
flying to them on his own dime.


If you want to be treated special, we need to have a reason for you to 
be treated special, otherwise you're just like everybody else 
complaining without giving back.

Re: CTFE ^^ (pow)

[Norm via Digitalmars-d]

On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 wrote:


Perhaps the community simply has different priorities than 
you? For example, my Android port has never gotten much use 
either, which is fine as I primarily did that work for myself.


Nevertheless, you have to think of D as like working in a 
startup: if you see something that you think needs doing, you 
have to drive it yourself or it will never get done. Pretty 
much the same for most any OSS project too.


This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at 
the same
time, that's not actually the relationship I want to have with 
my
tool. A startup probably shouldn't still be a startup 10 years 
later.


In your case, doing the android work was obviously an interest 
you had

on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and 
it
never has been. I want to use D to do my job, because I'm fed 
up with
C++. I want to engage in D the way I think D should **EXPECT** 
it's
users to engage in D; as an end-user, who uses the tool to get 
their

jobs done.
If D is a large-ish scale hobby project among a bunch of people 
with
mutual interests, then that should be more clearly 
communicated, but I
don't think that's the intent, and I feel perfectly fine 
interacting

with D in the way D is intended to be interacted with.

Incidentally, this particular work I'm doing is on a multimedia 
library intended for the community... so I really am truly 
trying to contribute something of value!! But like most of my 
projects, I tend to get blocked at some point, and then it goes 
on hold indefinitely.


+1024 bytes

I think D is a terrific language worthy of all the praise it gets 
and it is way way more stable than it was 3yrs ago. But the 
attitude of submit a PR if you want it fixed works very much 
against D. Like it or not these forums are a front page on the D 
marketing campaign.


My workplace has stopped using D after a 6 month trial, which 
finished in Jan 2018. Several developers did post here during 
that period when blocked by a bug or incomplete feature, only to 
be told if they want it fixed they can always submit a PR.


Inevitably when told this they simply dropped D and went back to 
C++ and Python. And they made a point to bring this experience up 
at the final go/no-go meeting.


The majority of developers, including those voting for D, had 
these common opinions (much to my disappointment)


a) We're not in the business of developing and maintaining D, but 
it seems that is what we would need to do as a company. We are 
better off with C++ and Python.


b) D feels like C++ did back in the mid 90's. A time when we 
avoided templates and often the STL because compiler 
implementations were too buggy. We are better off with C++ and 
Python.



I keep pushing D here but now it is a bit of a joke when I bring 
it up. I've become "the D guy" and it isn't discussed seriously 
any more by other developers, except a select few.


Cheers,
Norm

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

On Sunday, March 18, 2018 18:15:28 Manu via Digitalmars-d wrote:
> On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d
> > I definitely agree with this. If the folks fixing stuff don't have the
> > same priorities as you, then there's a high risk that what you want to
> > be fixed won't get fixed, and that's often how things go with open
> > source projects.
> And here it comes again!
> I understand the reality, and echo-ing statement sounds so good to the
> community... but it's a terrible opinion to propagate if the goal is
> for D to be successful.
> You're effectively saying "D is a hobby/toy, therefore you can't bank
> on it with confidence". If I weren't a deluded zealot, there's NO WAY
> I'd let my business invest in this technology when the crowd endlessly
> repeats this sentiment.
>
> So, while it IS a practical reality, there needs to be very strong
> motivation from the community (and organisation) to combat that
> practical reality.
> I would strongly suggest; never say a sentence like this again. It's
> the wrong attitude, and it gives an undesirable impression to users.
> (assuming the goal is for D to be successful, and not a fun hobby for
> the devs)

Well, it's the reality of things are. And D can be used just fine in a
production environment. It's just that you have to be willing to deal with
the warts that come with the wonderful stuff. Anyone who isn't isn't going
to be very happy. The number of warts have definitely gone down over time,
but that doesn't mean that they're all gone, and depending on your
priorities, it may be that they're far too often not going away in the
places that you care about most. Either way, I'm not about to lie about the
state of things. The fact that we're dealing almost exclusively with
volunteers has a definite impact on what gets done and how it gets done.
We're not the first language to start out that way, and others ended up
being _very_ successful in the long run (e.g. it's my understanding, that
python started entirely as open source with no company backing and took
quite a few years to grow to the point that it had a significant user base).
We've made a lot of progress, but we also have quite a lot of work to do.

> > But at the same time, if you come to D, see all kinds of great things
> > about it, and think that it's going to be fantastic but keep running
> > into things that cause you problems when you try to use D, and then
> > those pain points don't get fixed even after years of dealing with the
> > language, that's going to be very frustrating - even more so if you've
> > invested a lot of time and energy into it.
> >
> > On some level, the only solution is to buckle down and fix your pain
> > points yourself, but that can also be quite frustrating.
>
> Or hire staff who are paid to work on 'boring' issues. I would make
> regular donations if I could be satisfied that my decade old issues
> would be addressed. I wonder how many others would too?

With how things seem to be going with the D Foundation, it seems
increasingly likely that something like this will happen. It wasn't all that
long ago that there was trouble having enough money to pay for the travel
expenses of folks going to dconf, let alone hire staff to work on stuff. As
I understand it, some money has already been paid for specific projects
(e.g. the new CTFE engine), but AFAIK, there isn't currently anyone being
paid just to fix bugs. That may come though, especially if folks are willing
to donate money specifically towards that end.

- Jonathan M Davis

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 18:50, rikki cattermole via Digitalmars-d
 wrote:
> On 19/03/2018 2:38 PM, Manu wrote:
>>
>> On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d
>>
>>  wrote:
>>>
>>> On 19/03/2018 2:21 PM, Manu wrote:


 On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
  wrote:
>
>
> For those not in the know, Manu is special.
>
> He is in essence a use case for D himself.
>
> We really should be trying to make him happy in terms of blockers.
> It's just good business sense.
>
> Shame we can't throw money at him, he would have great ROI value.



 Haha!
 I tried to mitigate coming across that way, and express myself in
 terms of patience and frustration, which I think is probably something
 a lot of people here can relate to.

 Sure, there's no reason for anyone to care about my opinion, but I
 have truly spent years investing in D, and strategies and attempts to
 integrate it into my work *professionally*. Doing company
 demonstrations, training colleagues, attempting small projects as
 proof of concept, etc.
 That's all I care about. I have hobby projects like everyone, but what
 I *really* care about, is getting to the point where I can write D
 code professionally in my field of work.
 I also think I work in one of the prime fields where D has so much to
 offer... but we also have an unusually high bar-to-entry.
>>>
>>>
>>>
>>> Your entire reply is reason to care about your opinion :)
>>>
>>> I'm not alone in thinking that you're a very valuable community member.
>>
>>
>> I'm not though... I'm a noisy whingey one that never actually gives
>> anything back!
>> I'm just a stubborn mule that's constantly trying to fight my way
>> through my next hurdle.
>>
>> I think maybe my lessons are of some value, and I've been a forcing
>> function for a few important developments.
>> If I were to start over again today, I might have different
>> experience, thanks to a relative increase in ecosystem maturity
>> compared to when I started.
>>
>>> Perhaps you can have a chat with a member of DLF about getting a list of
>>> issues for you figured out?
>>
>>
>> I've influenced more than I feel is reasonable with respect to my
>> results. I've mostly failed, and not through lack of trying. There are
>> lots of people here now who are having way more success than I have.
>> I might do that if I could maneuver my workplace into a position where
>> they were to consider a serious investigation again.
>
>
> Your result, is a better D experience for everyone involved.
> There has been no failure that I can see on the communities end.
>
> You failed to create a successful commercial products using D, wait hang on
> Quantum Break!
>
> Just because 99 times out of 100 you've failed doesn't mean 1 won't be
> successful given more hard work.

I'm much more comfortable with confrontational emails :P

I'm not doing much work anymore though...
I'm drifting for entirely preventable reasons. I guess I just wanted
to share that here somehow. In altogether too many words! ;)

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 2:38 PM, Manu wrote:

On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d
 wrote:

On 19/03/2018 2:21 PM, Manu wrote:


On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 wrote:


For those not in the know, Manu is special.

He is in essence a use case for D himself.

We really should be trying to make him happy in terms of blockers.
It's just good business sense.

Shame we can't throw money at him, he would have great ROI value.



Haha!
I tried to mitigate coming across that way, and express myself in
terms of patience and frustration, which I think is probably something
a lot of people here can relate to.

Sure, there's no reason for anyone to care about my opinion, but I
have truly spent years investing in D, and strategies and attempts to
integrate it into my work *professionally*. Doing company
demonstrations, training colleagues, attempting small projects as
proof of concept, etc.
That's all I care about. I have hobby projects like everyone, but what
I *really* care about, is getting to the point where I can write D
code professionally in my field of work.
I also think I work in one of the prime fields where D has so much to
offer... but we also have an unusually high bar-to-entry.



Your entire reply is reason to care about your opinion :)

I'm not alone in thinking that you're a very valuable community member.


I'm not though... I'm a noisy whingey one that never actually gives
anything back!
I'm just a stubborn mule that's constantly trying to fight my way
through my next hurdle.

I think maybe my lessons are of some value, and I've been a forcing
function for a few important developments.
If I were to start over again today, I might have different
experience, thanks to a relative increase in ecosystem maturity
compared to when I started.


Perhaps you can have a chat with a member of DLF about getting a list of
issues for you figured out?


I've influenced more than I feel is reasonable with respect to my
results. I've mostly failed, and not through lack of trying. There are
lots of people here now who are having way more success than I have.
I might do that if I could maneuver my workplace into a position where
they were to consider a serious investigation again.


Your result, is a better D experience for everyone involved.
There has been no failure that I can see on the communities end.

You failed to create a successful commercial products using D, wait hang 
on Quantum Break!


Just because 99 times out of 100 you've failed doesn't mean 1 won't be 
successful given more hard work.

Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

[dangbinghoo via Digitalmars-d-announce]

On Monday, 19 March 2018 at 01:25:23 UTC, dangbinghoo wrote:

On Wednesday, 14 March 2018 at 11:09:47 UTC, Aravinda VK wrote:

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

hello there,

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

https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

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


Thanks!


For Fedora I found below link to install 
`gcc-arm-linux-gnueabihf`


https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabihf-toolchain/


just added fedora or centos, but installing using yum.


also added dnf way for installing armhf toolchain as the tutorial 
is mainly based on armhf target.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 18:29, rikki cattermole via Digitalmars-d
 wrote:
> On 19/03/2018 2:21 PM, Manu wrote:
>>
>> On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
>>  wrote:
>>>
>>> For those not in the know, Manu is special.
>>>
>>> He is in essence a use case for D himself.
>>>
>>> We really should be trying to make him happy in terms of blockers.
>>> It's just good business sense.
>>>
>>> Shame we can't throw money at him, he would have great ROI value.
>>
>>
>> Haha!
>> I tried to mitigate coming across that way, and express myself in
>> terms of patience and frustration, which I think is probably something
>> a lot of people here can relate to.
>>
>> Sure, there's no reason for anyone to care about my opinion, but I
>> have truly spent years investing in D, and strategies and attempts to
>> integrate it into my work *professionally*. Doing company
>> demonstrations, training colleagues, attempting small projects as
>> proof of concept, etc.
>> That's all I care about. I have hobby projects like everyone, but what
>> I *really* care about, is getting to the point where I can write D
>> code professionally in my field of work.
>> I also think I work in one of the prime fields where D has so much to
>> offer... but we also have an unusually high bar-to-entry.
>
>
> Your entire reply is reason to care about your opinion :)
>
> I'm not alone in thinking that you're a very valuable community member.

I'm not though... I'm a noisy whingey one that never actually gives
anything back!
I'm just a stubborn mule that's constantly trying to fight my way
through my next hurdle.

I think maybe my lessons are of some value, and I've been a forcing
function for a few important developments.
If I were to start over again today, I might have different
experience, thanks to a relative increase in ecosystem maturity
compared to when I started.

> Perhaps you can have a chat with a member of DLF about getting a list of
> issues for you figured out?

I've influenced more than I feel is reasonable with respect to my
results. I've mostly failed, and not through lack of trying. There are
lots of people here now who are having way more success than I have.
I might do that if I could maneuver my workplace into a position where
they were to consider a serious investigation again.

I still want x^^y to work though! :P

Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

[dangbinghoo via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 12:44:31 UTC, Uknown wrote:

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

hello there,

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

https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

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


Thanks!


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


All these instructions are not tied to a specified version, it 
should work for the future. Linux Distribution like 
fedora/debain/ArchLinux will not change such a package name for 
installing arm toolchain, as the toolchain package is not like 
libpng, you may have libpng11 libpng1.2 or what ever, it's just 
solid package names.

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

On 19/03/2018 2:21 PM, Manu wrote:

On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 wrote:

For those not in the know, Manu is special.

He is in essence a use case for D himself.

We really should be trying to make him happy in terms of blockers.
It's just good business sense.

Shame we can't throw money at him, he would have great ROI value.


Haha!
I tried to mitigate coming across that way, and express myself in
terms of patience and frustration, which I think is probably something
a lot of people here can relate to.

Sure, there's no reason for anyone to care about my opinion, but I
have truly spent years investing in D, and strategies and attempts to
integrate it into my work *professionally*. Doing company
demonstrations, training colleagues, attempting small projects as
proof of concept, etc.
That's all I care about. I have hobby projects like everyone, but what
I *really* care about, is getting to the point where I can write D
code professionally in my field of work.
I also think I work in one of the prime fields where D has so much to
offer... but we also have an unusually high bar-to-entry.


Your entire reply is reason to care about your opinion :)

I'm not alone in thinking that you're a very valuable community member.
Perhaps you can have a chat with a member of DLF about getting a list of 
issues for you figured out?

Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

[dangbinghoo via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 11:09:47 UTC, Aravinda VK wrote:

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

hello there,

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

https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

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


Thanks!


For Fedora I found below link to install 
`gcc-arm-linux-gnueabihf`


https://copr.fedorainfracloud.org/coprs/lantw44/arm-linux-gnueabihf-toolchain/


just added fedora or centos, but installing using yum.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 18:15, Manu  wrote:
> On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d
>  wrote:
>> On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:
>>> On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:
>>> > On 18 March 2018 at 17:00, Manu  wrote:
>>> >> [...]
>>> >
>>> > I want to just justify my apparent over-reaction... I think I'm
>>> > not
>>> > the only one that feels this way fairly often.
>>> > Something that seems trivial only invokes over-reaction of this
>>> > nature
>>> > when there is sufficient emotional energy behind it.
>>> > In my case, that is represented by investing a decade of my
>>> > life into
>>> > something based on the promise (**wishful thinking?) that it'll
>>> > get to
>>> > the point where I want it to be as a tool to do my work... but
>>> > then
>>> > slowly awakening myself to the reality that that's actually
>>> > unlikely
>>> > to happen, and the longer it takes, the less likely that
>>> > eventual
>>> > reality becomes.
>>> > Perhaps it's breaking a delusion I imposed on myself years ago,
>>> > but it
>>> > still produces a feeling of being robbed of time and energy.
>>> >
>>> > Anyway, I suspect I'm not the only one that reaches this point
>>> > and
>>> > tends to feel this way. I've seen a lot of good people come and
>>> > go
>>> > after they 'burn out' in some way. Patience is finite.
>>> > There's no action item here... just wanted to share a
>>> > reflection, and
>>> > perhaps there's some takeaway for the community with respect to
>>> > priorities?
>>>
>>> Perhaps the community simply has different priorities than you?
>>> For example, my Android port has never gotten much use either,
>>> which is fine as I primarily did that work for myself.
>>>
>>> Nevertheless, you have to think of D as like working in a
>>> startup: if you see something that you think needs doing, you
>>> have to drive it yourself or it will never get done. Pretty much
>>> the same for most any OSS project too.
>>
>> I definitely agree with this. If the folks fixing stuff don't have the same
>> priorities as you, then there's a high risk that what you want to be fixed
>> won't get fixed, and that's often how things go with open source projects.
>
> And here it comes again!
> I understand the reality, and echo-ing statement sounds so good to the
> community... but it's a terrible opinion to propagate if the goal is
> for D to be successful.
> You're effectively saying "D is a hobby/toy, therefore you can't bank
> on it with confidence". If I weren't a deluded zealot, there's NO WAY
> I'd let my business invest in this technology when the crowd endlessly
> repeats this sentiment.
>
> So, while it IS a practical reality, there needs to be very strong
> motivation from the community (and organisation) to combat that
> practical reality.
> I would strongly suggest; never say a sentence like this again. It's
> the wrong attitude, and it gives an undesirable impression to users.
> (assuming the goal is for D to be successful, and not a fun hobby for
> the devs)
>
>> But at the same time, if you come to D, see all kinds of great things about
>> it, and think that it's going to be fantastic but keep running into things
>> that cause you problems when you try to use D, and then those pain points
>> don't get fixed even after years of dealing with the language, that's going
>> to be very frustrating - even more so if you've invested a lot of time and
>> energy into it.
>>
>> On some level, the only solution is to buckle down and fix your pain points
>> yourself, but that can also be quite frustrating.
>
> Or hire staff who are paid to work on 'boring' issues. I would make
> regular donations if I could be satisfied that my decade old issues
> would be addressed. I wonder how many others would too?

For what it's worth, I think I sound like nothing is moving ever, and
that's not actually the reality today at all. I so feel like momentum
has increased substantially recently on a number of fronts, but I'm
mostly a passive observer standing a bit off to the side somewhere.
I am constantly impressed and excited about all the work that's being
done here... I read the announcements, and think "yeah, I super can't
wait to get amongst that good stuff!! ...if only my project would be
un-blocked from the thing that blocked it 5 years ago".
In some way, I'm still waiting for the opportunity to do all the good
stuff with D that D can do (including Android ports!), but I'm usually
blocked by mostly boring trivia, and a couple of big things (ie, ARC).

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 18:11, rikki cattermole via Digitalmars-d
 wrote:
> For those not in the know, Manu is special.
>
> He is in essence a use case for D himself.
>
> We really should be trying to make him happy in terms of blockers.
> It's just good business sense.
>
> Shame we can't throw money at him, he would have great ROI value.

Haha!
I tried to mitigate coming across that way, and express myself in
terms of patience and frustration, which I think is probably something
a lot of people here can relate to.

Sure, there's no reason for anyone to care about my opinion, but I
have truly spent years investing in D, and strategies and attempts to
integrate it into my work *professionally*. Doing company
demonstrations, training colleagues, attempting small projects as
proof of concept, etc.
That's all I care about. I have hobby projects like everyone, but what
I *really* care about, is getting to the point where I can write D
code professionally in my field of work.
I also think I work in one of the prime fields where D has so much to
offer... but we also have an unusually high bar-to-entry.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d
 wrote:
> On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:
>> On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:
>> > On 18 March 2018 at 17:00, Manu  wrote:
>> >> [...]
>> >
>> > I want to just justify my apparent over-reaction... I think I'm
>> > not
>> > the only one that feels this way fairly often.
>> > Something that seems trivial only invokes over-reaction of this
>> > nature
>> > when there is sufficient emotional energy behind it.
>> > In my case, that is represented by investing a decade of my
>> > life into
>> > something based on the promise (**wishful thinking?) that it'll
>> > get to
>> > the point where I want it to be as a tool to do my work... but
>> > then
>> > slowly awakening myself to the reality that that's actually
>> > unlikely
>> > to happen, and the longer it takes, the less likely that
>> > eventual
>> > reality becomes.
>> > Perhaps it's breaking a delusion I imposed on myself years ago,
>> > but it
>> > still produces a feeling of being robbed of time and energy.
>> >
>> > Anyway, I suspect I'm not the only one that reaches this point
>> > and
>> > tends to feel this way. I've seen a lot of good people come and
>> > go
>> > after they 'burn out' in some way. Patience is finite.
>> > There's no action item here... just wanted to share a
>> > reflection, and
>> > perhaps there's some takeaway for the community with respect to
>> > priorities?
>>
>> Perhaps the community simply has different priorities than you?
>> For example, my Android port has never gotten much use either,
>> which is fine as I primarily did that work for myself.
>>
>> Nevertheless, you have to think of D as like working in a
>> startup: if you see something that you think needs doing, you
>> have to drive it yourself or it will never get done. Pretty much
>> the same for most any OSS project too.
>
> I definitely agree with this. If the folks fixing stuff don't have the same
> priorities as you, then there's a high risk that what you want to be fixed
> won't get fixed, and that's often how things go with open source projects.

And here it comes again!
I understand the reality, and echo-ing statement sounds so good to the
community... but it's a terrible opinion to propagate if the goal is
for D to be successful.
You're effectively saying "D is a hobby/toy, therefore you can't bank
on it with confidence". If I weren't a deluded zealot, there's NO WAY
I'd let my business invest in this technology when the crowd endlessly
repeats this sentiment.

So, while it IS a practical reality, there needs to be very strong
motivation from the community (and organisation) to combat that
practical reality.
I would strongly suggest; never say a sentence like this again. It's
the wrong attitude, and it gives an undesirable impression to users.
(assuming the goal is for D to be successful, and not a fun hobby for
the devs)

> But at the same time, if you come to D, see all kinds of great things about
> it, and think that it's going to be fantastic but keep running into things
> that cause you problems when you try to use D, and then those pain points
> don't get fixed even after years of dealing with the language, that's going
> to be very frustrating - even more so if you've invested a lot of time and
> energy into it.
>
> On some level, the only solution is to buckle down and fix your pain points
> yourself, but that can also be quite frustrating.

Or hire staff who are paid to work on 'boring' issues. I would make
regular donations if I could be satisfied that my decade old issues
would be addressed. I wonder how many others would too?

Re: CTFE ^^ (pow)

[rikki cattermole via Digitalmars-d]

For those not in the know, Manu is special.

He is in essence a use case for D himself.

We really should be trying to make him happy in terms of blockers.
It's just good business sense.

Shame we can't throw money at him, he would have great ROI value.

Re: how to make private class member private

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote:


´´´
Are there any scenarios in which the person writing the class, 
would want to encapsulate their class, or some parts of it, 
from the rest of a module (while being forced to put the class 
in this module)?

´´´

The answer is no. As the person which is writing the class has 
always the power to decide which module to edit to put the 
class in.


And due this fact, the statement

The fact is, the creator of the class is also the creator of 
the module..


is the coolest semantic statement of the whole thread so far, I 
think :)


Well, it seems to me, that the only real objection one can have 
to improving encapsulation within a module, is objecting to 
improving encapsulation within a module.


The fact that the creator of a class, is also the creator of the 
module that contains that class, is not a valid reason for not 
seeking to improve encapsulation of that class.

Re: help cast

[sdvcn via Digitalmars-d]

On Sunday, 18 March 2018 at 20:07:28 UTC, Jonathan M Davis wrote:
On Sunday, March 18, 2018 14:56:04 Steven Schveighoffer via 
Digitalmars-d wrote:

On 3/18/18 2:24 PM, Jonathan M Davis wrote:
> On Sunday, March 18, 2018 13:10:28 Steven Schveighoffer via 
> Digitalmars-d

>
> wrote:
>> On 3/18/18 4:34 AM, sdvcn wrote:
>>> dchar v11=dchar.max;
>>>
>>>   auto vp11 = [v11];
>>>
>>>   auto v2 = cast(ubyte[]) (vp11);   //v2.length=4
>>>   auto v22 = cast(ubyte[])( [v11]); //v2.length=1
>>
>> This seems like a bug to me.
>>
>> It appears that v22 has truncated v11 to a byte and made 
>> only a single byte array out of it.

>
> Except that that's precisely how you usually get an array 
> any integral type smaller than an integer. e.g.

>
> auto arr = cast(ubyte[])([1, 2, 3, 4]);
>
> In this case, you could do
>
> ubyte[] arr = [1, 2, 3, 4];
>
> instead, but if you're not dealing with an initializaton or 
> assignment like this (e.g. you're passing the array to a 
> functon), then the cast is the way you do it. Normally, you 
> do it with integer literals, and I could see an argument 
> that it shouldn't allow it without VRP being used to make it 
> work, but it _is_ a cast, and casts are a bit of a blunt 
> instrument.

>
> So, I really don't think that it's a bug.

It's quite possible that you aren't understanding what is 
happening:


ubyte[] arr = cast(ubyte[])[555];
writeln(arr); // [43]

Why is this not a bug? I didn't cast the 555 to a ubyte, so it 
should either complain that it can't do it, or give me an 
array of 4 bytes.


I guess it could be explained as the same thing as:

ubyte[] arr = [cast(ubyte)555];

But this is surprisingly weird behavior.


That's exactly what it's doing, and when you have multiple 
elements in the literal, it quickly gets a lot more pleasant 
than casting each element individually. e.g.


cast(ubyte[])[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

vs

[cast(ubyte)0, cast(ubyte)1, cast(ubyte)2, cast(ubyte)3, 
cast(ubyte)4,
 cast(ubyte)5, cast(ubyte)6, cast(ubyte)7, cast(ubyte)8, 
cast(ubyte)9,

 cast(ubyte)10]

I use this trick all the time when creating arrays of integral 
types smaller than int, precisely because casting each element 
is a royal pain and way harder to read.


- Jonathan M Davis




代码目的是转换任意类行到ubyte[]
The object of the code is to convert any class of rows to ubyte[]

但是非数组类无法正确转化
But non - array classes can't be converted correctly



void pByte(T)(T v)
{
ubyte[] uBuf;
static if(isArray!T){
uBuf = cast(ubyte[])mKey;
}else{
uBuf = cast(ubyte[])[v];
}
writeln(uBuf);
}

无法得到正确结果
Unable to get the correct result

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 17:28, Joakim via Digitalmars-d
 wrote:
>
> Perhaps the community simply has different priorities than you? For example,
> my Android port has never gotten much use either, which is fine as I
> primarily did that work for myself.
>
> Nevertheless, you have to think of D as like working in a startup: if you
> see something that you think needs doing, you have to drive it yourself or
> it will never get done. Pretty much the same for most any OSS project too.

This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at the same
time, that's not actually the relationship I want to have with my
tool. A startup probably shouldn't still be a startup 10 years later.

In your case, doing the android work was obviously an interest you had
on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and it
never has been. I want to use D to do my job, because I'm fed up with
C++. I want to engage in D the way I think D should **EXPECT** it's
users to engage in D; as an end-user, who uses the tool to get their
jobs done.
If D is a large-ish scale hobby project among a bunch of people with
mutual interests, then that should be more clearly communicated, but I
don't think that's the intent, and I feel perfectly fine interacting
with D in the way D is intended to be interacted with.

Incidentally, this particular work I'm doing is on a multimedia
library intended for the community... so I really am truly trying to
contribute something of value!! But like most of my projects, I tend
to get blocked at some point, and then it goes on hold indefinitely.

Re: Testing D database calls code for regression

[H. S. Teoh via Digitalmars-d-learn]

On Sun, Mar 18, 2018 at 07:51:18PM +, aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn
> > wrote:
> > > [...]
> > 
> > The usual way I do this is to decouple the code from the real
> > database backend by templatizing the database driver.  Then in my
> > unittest I can instantiate the template with a mock database driver
> > that only implements the bare minimum to run the test.
> > 
> > [...]
> 
> Mocking a fake database can also be huge pain. Especially when
> something like transactions and prepared statements are involved.

It depends on what your test is looking for.  The idea is that the mock
database only implements a (small!) subset of a real database, basically
just enough for the test to run, and nothing more.  Of course, sometimes
it may not be easy to do this, if the code being tested is very complex.


> Imagine testing your mock for introduced by future extension.

If you find yourself needing to test your mock database, then you're
doing it wrong.  :-D  It's supposed to be helping you test your code,
not to create more code that itself needs to be tested!

Basically, this kind of testing imposes certain requirements on the way
you write your code. Certain kinds of code are easier to test than
others.  For example, imagine trying to test a complex I/O pipeline
implemented as nested loops. It's basically impossible to test it except
as a blackbox testing (certain input sets must produce certain output
sets). It's usually impractical for the test to target specific code
paths nested deep inside a nested loop. The only thing you can do is to
hope and pray that your blackbox tests cover enough of the code paths to
ensure things are correct. But you're likely to miss certain exceptional
cases.

But if said I/O pipeline is implemented as series of range compositions,
for example, then it becomes very easy to test each component of the
range composition. Each component is decoupled from the others, so it's
easy for the unittest to check all code paths. Then it's much easier to
have the confidence that the composed pipeline itself is correct.

I/O pipelines are an easy example, but understandably, in real-world
code things are rarely that clean.  So you'll have to find a way of
designing your database code such that it's more easily testable.
Otherwise, it's going to be a challenge no matter what.  No matter what
you do, testing a function made of loops nested 5 levels deep is going
to be very hard.  Similarly, if your database code has very complex
interdependencies, then it's going to be hard to test no matter how you
try.

Anyway, on the more practical side of things, depending on what your
test is trying to do, a mock database could be as simple as:

struct MockDb {
string prebakedResponse;
auto query(string sql) {
if (sql == "SELECT * FROM data")
return prebakedResponse;
else if (sql == "UPDATE * SET ... ")
prebakedResponse = ...
else
assert(0, "Time to rewrite your unittest :-P");
}
}

I.e., you literally only need to implement what the test case will
actually invoke. Anything that isn't strictly required is fair game to
just outright ignore.

Also, keep in mind that MockDb can be a completely different thing per
unittest. Trying to use the same mock DB for all unittests will just end
up with writing your own database engine, which kinda defeats the
purpose. :-P  But the ability to do this depends on how decoupled the
code is.  Code with complex interdependencies will generally give you a
much harder time than more modular, decoupled code.


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose 
Bierce

Re: CTFE ^^ (pow)

[Jonathan M Davis via Digitalmars-d]

On Monday, March 19, 2018 00:28:15 Joakim via Digitalmars-d wrote:
> On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:
> > On 18 March 2018 at 17:00, Manu  wrote:
> >> [...]
> >
> > I want to just justify my apparent over-reaction... I think I'm
> > not
> > the only one that feels this way fairly often.
> > Something that seems trivial only invokes over-reaction of this
> > nature
> > when there is sufficient emotional energy behind it.
> > In my case, that is represented by investing a decade of my
> > life into
> > something based on the promise (**wishful thinking?) that it'll
> > get to
> > the point where I want it to be as a tool to do my work... but
> > then
> > slowly awakening myself to the reality that that's actually
> > unlikely
> > to happen, and the longer it takes, the less likely that
> > eventual
> > reality becomes.
> > Perhaps it's breaking a delusion I imposed on myself years ago,
> > but it
> > still produces a feeling of being robbed of time and energy.
> >
> > Anyway, I suspect I'm not the only one that reaches this point
> > and
> > tends to feel this way. I've seen a lot of good people come and
> > go
> > after they 'burn out' in some way. Patience is finite.
> > There's no action item here... just wanted to share a
> > reflection, and
> > perhaps there's some takeaway for the community with respect to
> > priorities?
>
> Perhaps the community simply has different priorities than you?
> For example, my Android port has never gotten much use either,
> which is fine as I primarily did that work for myself.
>
> Nevertheless, you have to think of D as like working in a
> startup: if you see something that you think needs doing, you
> have to drive it yourself or it will never get done. Pretty much
> the same for most any OSS project too.

I definitely agree with this. If the folks fixing stuff don't have the same
priorities as you, then there's a high risk that what you want to be fixed
won't get fixed, and that's often how things go with open source projects.
But at the same time, if you come to D, see all kinds of great things about
it, and think that it's going to be fantastic but keep running into things
that cause you problems when you try to use D, and then those pain points
don't get fixed even after years of dealing with the language, that's going
to be very frustrating - even more so if you've invested a lot of time and
energy into it.

On some level, the only solution is to buckle down and fix your pain points
yourself, but that can also be quite frustrating.

- Jonathan M Davis

Re: Should the "front" range primitive be "const" ?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 19, 2018 00:14:11 Drone1h via Digitalmars-d-learn wrote:
> I am not sure whether I can make it work with "inout" instead of
> "const". Perhaps I am missing something.
...
> May I ask that you confirm that this is what you suggested ?
> Thank you.

Marking a empty or front with inout has most of the problems that const has.
The difference is that if the range is mutable, then the return value will
be treated as mutable. The internals of the function, however, must still
work with const or inout, and that's not true for most ranges. It can work
just fine to mark empty or front as inout or const if you're in full control
of the element types and aren't wrapping other ranges, but as soon as you
start wrapping other ranges, you pretty much must give up on inout and
const, because most ranges won't work with them - even to just call empty or
front. And in many cases, they can't be made to work with const or inout,
because that often causes serious problems with the return type. The range
API simply does not include const or inout, so you can't assume that any
range will compile with them, meaning that ranges that wrap other ranges can
only use const or inout when they're intended to wrap a very specific set of
ranges that do work with const or inout. Ranges that generically wrap other
ranges cannot use const or inout, or they will not compile with many (most?)
ranges.

> > [...] const ranges are utterly useless, because they can't be
> > mutated and thus can't be iterated. [...]
>
> I am considering a function that takes as parameter a (reference
> to) const range. It should be able to check whether the range is
> "empty" and, if not empty, it should be able to access the
> "front" element.
>
> Now the caller of that function can rest assured that the
> function is not going to modify the range by "popFront".
>
> The function might be more useful than a function that just takes
> as parameter a value (the result of "front") because it may be
> called with an empty range and it can detect that. This is
> similar to getting as parameter a (possibly null) pointer to a
> value instead of getting as parameter a value.
>
> Therefore, it seems to me that a const range might be useful.
>
> If you have already considered this and have actually seen
> one-step ahead of me, may I ask that you confirm, please ?

Most ranges do not work with const in any way shape or form. _Some_ will
work if all you're doing is looking at is empty or front. But if all you're
doing is looking at the front, in general, why pass a range? Just call front
and pass it, and then the function will work with more than just ranges.
Yes, if you want a function that does something like

auto frontOrInit(R)(R range)
{
return range.empty ? ElementType!R.init : range.front;
}

then you can make the range const, but in general, a function is either
going to be iterating over the range (so the range can't be const), or what
the function is doing really has nothing to do with ranges and would be far
more flexible if it just took the range's element type. Functions like
frontOrInit where it would make sense to only call front or empty on a range
are rare. And honestly, making a function like frontOrInit accept the range
by const doesn't buy you much if a range's front and empty are const, and it
makes the function useless with most ranges, because most ranges don't - and
many can't - mark front or empty as const.

Honestly, I think that you will be far better off if you just don't try and
use const or inout with ranges. You can make it work in very restricted
circumstances, but you will constantly be fighting problems where code does
not compile. I'd suggest that you read this:

http://jmdavisprog.com/articles/why-const-sucks.html

- Jonathan M Davis

Re: CTFE ^^ (pow)

[Joakim via Digitalmars-d]

On Monday, 19 March 2018 at 00:08:58 UTC, Manu wrote:

On 18 March 2018 at 17:00, Manu  wrote:

[...]


I want to just justify my apparent over-reaction... I think I'm 
not

the only one that feels this way fairly often.
Something that seems trivial only invokes over-reaction of this 
nature

when there is sufficient emotional energy behind it.
In my case, that is represented by investing a decade of my 
life into
something based on the promise (**wishful thinking?) that it'll 
get to
the point where I want it to be as a tool to do my work... but 
then
slowly awakening myself to the reality that that's actually 
unlikely
to happen, and the longer it takes, the less likely that 
eventual

reality becomes.
Perhaps it's breaking a delusion I imposed on myself years ago, 
but it

still produces a feeling of being robbed of time and energy.

Anyway, I suspect I'm not the only one that reaches this point 
and
tends to feel this way. I've seen a lot of good people come and 
go

after they 'burn out' in some way. Patience is finite.
There's no action item here... just wanted to share a 
reflection, and

perhaps there's some takeaway for the community with respect to
priorities?


Perhaps the community simply has different priorities than you? 
For example, my Android port has never gotten much use either, 
which is fine as I primarily did that work for myself.


Nevertheless, you have to think of D as like working in a 
startup: if you see something that you think needs doing, you 
have to drive it yourself or it will never get done. Pretty much 
the same for most any OSS project too.

[Issue 18630] New: std.math must CTFE

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

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

  Issue ID: 18630
   Summary: std.math must CTFE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

Every single function in std.math must CTFE.

At very least, let's start with pow, log, exp, sin/cos and friends...

Curves exist. Populating tables with curve data is a thing that I *constantly*
want to do.

I usually workaround with a static constructor that pre-computes tables at
startup, but that only solves some subset of cases. When I want those tables to
interact with other CTFE code, I'm blocked.

--

Re: Should the "front" range primitive be "const" ?

[Drone1h via Digitalmars-d-learn]

First of all, thank you all for the replies. It has taken me some 
time to learn a bit more to be able to understand at least some 
parts of them. I have a further question below the quotes.


On Tuesday, 30 January 2018 at 01:20:09 UTC, Jonathan M Davis 
wrote:
On Tuesday, January 30, 2018 01:05:54 Drone1h via 
Digitalmars-d-learn wrote:



[...]
I am trying to implement a ("struct template" ? what is the
correct word ?) range that just forwards its primitives 
("empty",

"front", "popFront") to another range, possibly with some very
limited filtering/alteration, as std.range.Take (just to 
learn).


Initially, the "front" member function (property) used to be
declared "const", but that was not accepted when the underlying
range (denoted "R" in the code below) was 
std.stdio.File.ByChunk

("Error: mutable method std.stdio.File.ByChunk.front is not
callable using a const object").
[...]


If you want to put an attribute on it, inout is better, because 
then it will work with any constness


I am not sure whether I can make it work with "inout" instead of 
"const". Perhaps I am missing something.


Here is my code:

auto Take2 (R) (R r, size_t n)
{
import std.range.primitives;

struct Result
{
private:
R  _r;
size_t _n;
size_t _i;

public:
@property bool empty () const
{
return _i >= _n || _r.empty;
}

@property auto ref front () const // Replace "const" 
with "inout" here ?

{
return _r.front;
}

void popFront ()
{
++_i;
if (_i < _n)
_r.popFront ();
}

this (R r, size_t n)
{
_r = r;
_n = n;
_i = 0;
}
}

return Result (r, n);
}

unittest
{
import std.stdio;

auto file = File ("Example", "rb");
foreach (c; file.byChunk (0x100).Take2 (5))
stdout.rawWrite (c);
}

I get compile error:

Error: mutable method `std.stdio.File.ByChunkImpl.front` is 
not callable using a `const` object


If I replace "const" with "inout" for the "front" function, i.e. 
"@property auto ref front () inout", I get similar error:


Error: mutable method `std.stdio.File.ByChunkImpl.front` is 
not callable using a `inout` object


May I ask that you confirm that this is what you suggested ? 
Thank you.




[...] const ranges are utterly useless, because they can't be 
mutated and thus can't be iterated. [...]


I am considering a function that takes as parameter a (reference 
to) const range. It should be able to check whether the range is 
"empty" and, if not empty, it should be able to access the 
"front" element.


Now the caller of that function can rest assured that the 
function is not going to modify the range by "popFront".


The function might be more useful than a function that just takes 
as parameter a value (the result of "front") because it may be 
called with an empty range and it can detect that. This is 
similar to getting as parameter a (possibly null) pointer to a 
value instead of getting as parameter a value.


Therefore, it seems to me that a const range might be useful.

If you have already considered this and have actually seen 
one-step ahead of me, may I ask that you confirm, please ?




Thank you respectfully.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 17:00, Manu  wrote:
> On 18 March 2018 at 02:19, Johan Engelen via Digitalmars-d
>  wrote:
>> On Sunday, 18 March 2018 at 04:25:48 UTC, 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.
>>
>>
>> It's been available in LDC since 1.6.0.
>> https://godbolt.org/g/Yx7PyK
>>
>> - Johan
>>
>> (PS. The aggressive style of your message would not motivate me to improve
>> things for you.)
>
> It's not aggression, it's a decade of compounded frustration.
> I consider myself extremely patient with D, but how far am I supposed
> to extend patience before I admit that I'm wasting my precious time
> investing in something that's never going to 'get there'?
> I still want to love D, but I'm drifting away and using it less and
> less these days, and the main reason is that something so trivial as
> this, which has been a recorded bug for almost a decade and comes up
> often, still never moves. I'm always waiting... and so I find other
> things to do with my time.
>
> After being too busy to work on my side projects for a while, I
> finally had a small block of time. I jumped in, did a few things, then
> hit the same brick wall that I hit 3 years ago. My momentum comes to
> an instant halt, and I feel like I'm just less likely to return to the
> project again in the future wrt competing for priorities.
> Ideally, if I make my blockers known (this one is so simple!!), and
> try and re-awaken them semi-regularly... I'd like to think getting
> back to something 3 years later, I'm able to move forward. But it's
> still most of the same blockers I identified within my first 2-3 days
> of using D ~9 years ago; I still can't ARC, I still can't pass an
> rvalue by ref, and I still can't x^^y in ctfe.
> This one has gotta be by far the simplest thing I've ever complained about!
>
> Anyway, I've pretty much run out of energy to advocate a thing that
> still doesn't even solve my own needs (let along the needs of my
> companies), based on the assumption that it's fast moving, and
> deficiencies will be resolved 'soon enough' after it's made known that
> they are a blocker.
> I'm sorry, 'soon enough' is not soon enough... I've run out of
> patience, and I'm becoming increasingly frustrated and toxic.
>
> I was gonna spend today coding, but I think I'll go outside instead.

I want to just justify my apparent over-reaction... I think I'm not
the only one that feels this way fairly often.
Something that seems trivial only invokes over-reaction of this nature
when there is sufficient emotional energy behind it.
In my case, that is represented by investing a decade of my life into
something based on the promise (**wishful thinking?) that it'll get to
the point where I want it to be as a tool to do my work... but then
slowly awakening myself to the reality that that's actually unlikely
to happen, and the longer it takes, the less likely that eventual
reality becomes.
Perhaps it's breaking a delusion I imposed on myself years ago, but it
still produces a feeling of being robbed of time and energy.

Anyway, I suspect I'm not the only one that reaches this point and
tends to feel this way. I've seen a lot of good people come and go
after they 'burn out' in some way. Patience is finite.
There's no action item here... just wanted to share a reflection, and
perhaps there's some takeaway for the community with respect to
priorities?

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 02:19, Johan Engelen via Digitalmars-d
 wrote:
> On Sunday, 18 March 2018 at 04:25:48 UTC, 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.
>
>
> It's been available in LDC since 1.6.0.
> https://godbolt.org/g/Yx7PyK
>
> - Johan
>
> (PS. The aggressive style of your message would not motivate me to improve
> things for you.)

It's not aggression, it's a decade of compounded frustration.
I consider myself extremely patient with D, but how far am I supposed
to extend patience before I admit that I'm wasting my precious time
investing in something that's never going to 'get there'?
I still want to love D, but I'm drifting away and using it less and
less these days, and the main reason is that something so trivial as
this, which has been a recorded bug for almost a decade and comes up
often, still never moves. I'm always waiting... and so I find other
things to do with my time.

After being too busy to work on my side projects for a while, I
finally had a small block of time. I jumped in, did a few things, then
hit the same brick wall that I hit 3 years ago. My momentum comes to
an instant halt, and I feel like I'm just less likely to return to the
project again in the future wrt competing for priorities.
Ideally, if I make my blockers known (this one is so simple!!), and
try and re-awaken them semi-regularly... I'd like to think getting
back to something 3 years later, I'm able to move forward. But it's
still most of the same blockers I identified within my first 2-3 days
of using D ~9 years ago; I still can't ARC, I still can't pass an
rvalue by ref, and I still can't x^^y in ctfe.
This one has gotta be by far the simplest thing I've ever complained about!

Anyway, I've pretty much run out of energy to advocate a thing that
still doesn't even solve my own needs (let along the needs of my
companies), based on the assumption that it's fast moving, and
deficiencies will be resolved 'soon enough' after it's made known that
they are a blocker.
I'm sorry, 'soon enough' is not soon enough... I've run out of
patience, and I'm becoming increasingly frustrated and toxic.

I was gonna spend today coding, but I think I'll go outside instead.

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 06:57, Rubn via Digitalmars-d
 wrote:
>
> There was a PR a while ago IIRC, it's probably one of those sitting at the
> back of the queue from 4 years ago or something.

Unacceptable if true.

Re: The D Language Foundation at Open Collective

[Tony via Digitalmars-d-announce]

On Sunday, 18 March 2018 at 20:18:45 UTC, Tony wrote:

I have seen regular coffee at $4.50 and as high as $5.50 in the 
USA (and not always a large),


I believe they currently have a $5.50 pour over, but this undated 
third-party hosted menu for Voltaire Coffee House in San Jose, CA 
shows  "pour over" cups of coffee from $4 to $5:


http://places.singleplatform.com/voltaire-coffee-house/menu

Re: CTFE ^^ (pow)

[Manu via Digitalmars-d]

On 18 March 2018 at 00:47, Nicholas Wilson via Digitalmars-d
 wrote:
> On Sunday, 18 March 2018 at 04:25:48 UTC, 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.
>
>
> Not all that much. Can you give me an example that does't work yet that you
> want to use?

x^^y :)

Re: Logging Function Parameters

[Seb via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 10:34:41 UTC, dom wrote:

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(", "));


You can't get the parameters names at the moment, but there's a 
PR for it:


https://github.com/dlang/dmd/pull/7821

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

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

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

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

   What|Removed |Added

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

--

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

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

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

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

https://github.com/dlang/dmd/commit/2dbc2bd85d5e5a55a3bcbf362c60cb0648102a73
fix Issue 18282 part 2

https://github.com/dlang/dmd/commit/bbe466b97fe5d2fa9f2914937f42079a987579d2
Merge pull request #8045 from WalterBright/fix18282-2

fix Issue 18282 part 2
merged-on-behalf-of: Walter Bright 

--

Re: Logging Function Parameters

[Dennis via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 22:57:15 UTC, aliak wrote:

// But you get a:
// Error: Using the result of a comma expression is not 
allowed

// writeln(mixin(arguments!f));


You can't mix part of a function call in: "Mixed in text must 
form complete declarations, statements, or expressions." 
(https://dlang.org/articles/mixin.html)


In this case, it evaluates to a comma expression, which is 
deprecated. If you put the "writeln();" inside the mixin string 
it should form a complete statement and compile.

Re: Does the compiler inline the predicate functions to std.algorithm.sort?

[David Nadlinger via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 14:15:37 UTC, Stefan Koch wrote:

On Sunday, 18 March 2018 at 12:59:06 UTC, tipdbmp wrote:
I can't read assembly but it seems to me that it doesn't: 
https://godbolt.org/g/PCsnPT
I think C++'s sort can take a "function object" that can get 
inlined.


Correct it does not get in-lined.
Even with -O3 it does not.

The reason is that the code the sort instantiation produces is 
too big for the inliner cost function.


If you have a look at the the cg file produced when you specify 
-vcg-ast you can see that it's a massive amount of code.


I believe the original poster was asking about the *predicate* to 
sort, which is indeed inlined with optimizations on.


(@tipdbmp: The string gets turned into the function 
_D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.)


 — David

Re: Logging Function Parameters

[aliak via Digitalmars-d-learn]

On Saturday, 17 March 2018 at 10:34:41 UTC, dom wrote:

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(", "));


You may be able to do something with a mixin. I tried this but I 
think I'm hitting a compiler bug, or I'm just using mixins wrong.


import std.stdio;

string arguments(alias f)() {
import std.meta: AliasSeq;
import std.traits: ParameterIdentifierTuple;
import std.array: join;
string[] args;
foreach (a; [AliasSeq!(ParameterIdentifierTuple!f)]) {
args ~= `"` ~ a ~ `: ", ` ~ a;
}
return args.join(`, ", ", `);
}

// calling writeln(mixin(arguments!f)) should do what you want.

void f(int a, int b, int c) {

// But you get a:
// Error: Using the result of a comma expression is not 
allowed

// writeln(mixin(arguments!f));


auto value = arguments!f; // "a: ", a, ", ", "b: ", b, ", ", 
"c: ", c

writeln(value);

// This is ok:
writeln("a: ", a, ", ", "b: ", b, ", ", "c: ", c);
}

void main() {
f(1, 2, 3);
}

You might be able to start with that and get something that 
works. Or maybe someone knows how to make the mixin part above 
compile. I have a feeling you may need to make the arguments() 
function return a string("p0: ", arg0, ", p1: ", arg1" ...) 
instead so that it's a full string instead of a comma separated 
expression maybe.


Cheers

[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

   Assignee|nob...@puremagic.com|j...@neggie.net

--- Comment #7 from John Belmonte  ---
Besides the code's documented case of "{}" (could be empty struct initializer
or empty parameterless function literal), there is another ambiguous case:

  static MyStruct foo = {
{ return 1 + 1; }
  };

where RHS could either be a struct initializer (with member type "int
function()") or function literal with a needless added scope.

In the "{}" case, the code sides with struct initializer.  This makes sense
since the function literal could be disambiguated in several ways (e.g. as
"function() {}").

Given that, I propose to resolve this bug as follows:

   1) document this other ambiguous case
   2) document why we side with struct literal in ambiguous cases (i.e. since
you can disambiguate function literal cases via extra syntax)
   3) change the parser to only abort struct literal look-ahead if semicolon or
return token appears at top level of curly brackets, so that struct initializer
may contain function literals

--

[Issue 18629] std.algorithm.iteration.subsitute is slow

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

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

Basile B.  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 18629] New: std.algorithm.iteration.subsitute is slow

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

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

  Issue ID: 18629
   Summary: std.algorithm.iteration.subsitute is slow
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

In this benchmark i cast items as ubyte[] to prevent autodecoding. Still 2.5X
slower than a naive equivalent that uses cascaded `replace`.

```
#!dmd -O -release -inline -boundscheck=off
module runnable;

import std.stdio, std.algorithm,std.array, std.conv;

string v1(string message)
{
auto s = "{filepath}({line}:{column})[{type}]: {message}";
const string fileName = "/home/folder/folter/source.d";
const int line = 42;
const int column = 13;

s = s.replace("{filepath}", fileName);
s = s.replace("{line}", to!string(line));
s = s.replace("{column}", to!string(column));
s = s.replace("{type}", "warn");
s = s.replace("{message}", message);

return s;
}

string v3(string message)
{
auto s = "{filepath}({line}:{column})[{type}]: {message}";
const string fileName = "/home/folder/folter/source.d";
const int line = 42;
const int column = 13;
const string isError = "warn";

return cast(string) substitute(cast(ubyte[])s,
cast(ubyte[])"{filepath}", cast(ubyte[])fileName,
cast(ubyte[])"{line}", cast(ubyte[])to!string(column),
cast(ubyte[])"{column}", cast(ubyte[])to!string(column),
cast(ubyte[])"{type}", cast(ubyte[])isError,
cast(ubyte[])"{message}", cast(ubyte[])message
).array;
}

void main()
{
import std.datetime.stopwatch;
benchmark!((){v1("frst version");})(1_000_000).writeln;
benchmark!((){v3("thrd version");})(1_000_000).writeln;
}
```

gives:

[1 sec, 669 ms, 590 μs, and 8 hnsecs]
[3 secs, 5 ms, 266 μs, and 2 hnsecs]

which does not encourage to write idiomatic D code.

--

[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

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

   What|Removed |Added

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

--

[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 #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/70fb7cb46698ec6d6fba7efc64331cb76f73ef07
fix Issue 15624 - opApply with @safe and @system variants can't be used with
foreach syntax

https://github.com/dlang/dmd/commit/5bfa34232d104d75b189a84cc88f3dd4fc885daf
Merge pull request #8047 from WalterBright/fix15624

fix Issue 15624 - opApply with @safe and @system variants can't be us…
merged-on-behalf-of: Walter Bright 

--

Re: how to make private class member private

[Tony via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 18:04:13 UTC, Tony wrote:

On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:



D is not C++, C#, or Java. C++ uses friend to get around the 
issue. Java has no solution. I don't know about C#.




Java has four protection levels. If you don't explicitly 
specify [private, protected, public] the protection level is 
implicitly "package-private". That means that any class in the 
same package can access that attribute. I believe that Java 
packages are identical to D packages.


https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/accessibility-levels

C# has 6 accessibility levels:

public - Access is not restricted.
protected - Access is limited to the containing class or types 
derived from the containing class.

private - Access is limited to the containing type.
internal - Access is limited to the current assembly.
protected internal - Access is limited to the current assembly or 
types derived from the containing class.
private protected - Access is limited to the containing class or 
types derived from the containing class within the current 
assembly. Available since C# 7.2.


What is a C# Assembly? Someone says on a forum:
"An assembly is a "unit of deployment" for .NET, almost always a 
.exe or .dll.

In C# terms, it's basically a single C# project."

And also refers to
https://social.msdn.microsoft.com/Forums/en-US/088ce8ed-ef9b-4dea-88b3-ca016885e26d/what-is-an-assembly-in-terms-of-c?forum=csharplanguage
which says:
"Assemblies are the building blocks of .NET Framework 
applications; they form the fundamental unit of deployment, 
version control, reuse, activation scoping, and security 
permissions. An assembly is a collection of types and resources 
that are built to work together and form a logical unit of 
functionality. An assembly provides the common language runtime 
with the information it needs to be aware of type 
implementations. To the runtime, a type does not exist outside 
the context of an assembly."

[Issue 18078] [CTFE] wrong initialization of array member with inout opIndex

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Reduced to:

---
struct S
{
int x;
version (problem) void opAssign(S o) { x = o.x; }
}

struct Foo
{
S[1] data;
ref inout(S) g() inout { return data[0]; }
this(S a) { g() = a; }
}

void main()
{
enum x = Foo(S(42));
assert(x.data[0].x == 42);
}
---

The problem disappears if you remove `opAssign` (or the inout qualifiers).

--

[Issue 18628] @disable this(this) erroneously adds `__postblit` member

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

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 18628] New: @disable this(this) erroneously adds `__postblit` member

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

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

  Issue ID: 18628
   Summary: @disable this(this) erroneously adds `__postblit`
member
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

Testcase:
```
import std.traits;
import std.stdio;

void main() {
static struct S { @disable this(this); }

writeln(hasMember!(S, "__postblit")); // expected: false
writeln(hasElaborateCopyConstructor!S); // expected: false
}
```

The program prints twice "true", instead of "false".
Note that `hasElaborateCopyConstructor` does a `hasMember!(S, "__postblit")`
check, so that's the root cause of the problem.

--

Re: The D Language Foundation at Open Collective

[Tony via Digitalmars-d-announce]

On Thursday, 15 March 2018 at 12:36:24 UTC, Meta wrote:



Sorry to derail, but I had to ask: where does 1 coffee (even 
extra large) cost $5 USD? Let me know so I know to never move 
there.


I have seen regular coffee at $4.50 and as high as $5.50 in the 
USA (and not always a large), but in order to get there, it has 
to be "single cup pour over" made, as opposed to coming out of a 
machine into a pot. And the beans have to be organic or they are 
telling you exactly where they were grown and giving you alleged 
"flavor notes" and maybe they roasted them in-house or locally, 
and the place has to have an upscale or luxury vibe. But 
Starbucks in the USA gives you a 20oz out-of-a-machine for under 
$3. McDonald's beats everybody - $1 for a large. Although I am 
not a big fan of the McDonalds coffee (maybe psychological due to 
the low price). 7/11 convenience stores and Chevron gas stations 
both have several varieties of coffee on tap that they sell for 
under $2 for a large, that I think tastes good.

Re: help cast

[Jonathan M Davis via Digitalmars-d]

On Sunday, March 18, 2018 14:56:04 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 3/18/18 2:24 PM, Jonathan M Davis wrote:
> > On Sunday, March 18, 2018 13:10:28 Steven Schveighoffer via
> > Digitalmars-d
> >
> > wrote:
> >> On 3/18/18 4:34 AM, sdvcn wrote:
> >>> dchar v11=dchar.max;
> >>>
> >>>   auto vp11 = [v11];
> >>>
> >>>   auto v2 = cast(ubyte[]) (vp11);   //v2.length=4
> >>>   auto v22 = cast(ubyte[])( [v11]); //v2.length=1
> >>
> >> This seems like a bug to me.
> >>
> >> It appears that v22 has truncated v11 to a byte and made only a single
> >> byte array out of it.
> >
> > Except that that's precisely how you usually get an array any integral
> > type smaller than an integer. e.g.
> >
> > auto arr = cast(ubyte[])([1, 2, 3, 4]);
> >
> > In this case, you could do
> >
> > ubyte[] arr = [1, 2, 3, 4];
> >
> > instead, but if you're not dealing with an initializaton or assignment
> > like this (e.g. you're passing the array to a functon), then the cast
> > is the way you do it. Normally, you do it with integer literals, and I
> > could see an argument that it shouldn't allow it without VRP being used
> > to make it work, but it _is_ a cast, and casts are a bit of a blunt
> > instrument.
> >
> > So, I really don't think that it's a bug.
>
> It's quite possible that you aren't understanding what is happening:
>
> ubyte[] arr = cast(ubyte[])[555];
> writeln(arr); // [43]
>
> Why is this not a bug? I didn't cast the 555 to a ubyte, so it should
> either complain that it can't do it, or give me an array of 4 bytes.
>
> I guess it could be explained as the same thing as:
>
> ubyte[] arr = [cast(ubyte)555];
>
> But this is surprisingly weird behavior.

That's exactly what it's doing, and when you have multiple elements in the
literal, it quickly gets a lot more pleasant than casting each element
individually. e.g.

cast(ubyte[])[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

vs

[cast(ubyte)0, cast(ubyte)1, cast(ubyte)2, cast(ubyte)3, cast(ubyte)4,
 cast(ubyte)5, cast(ubyte)6, cast(ubyte)7, cast(ubyte)8, cast(ubyte)9,
 cast(ubyte)10]

I use this trick all the time when creating arrays of integral types smaller
than int, precisely because casting each element is a royal pain and way
harder to read.

- Jonathan M Davis

Re: Testing D database calls code for regression

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 18, 2018 19:51:18 aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via
> >
> > Digitalmars-d-learn wrote:
> >> [...]
> >
> > The usual way I do this is to decouple the code from the real
> > database backend by templatizing the database driver.  Then in
> > my unittest I can instantiate the template with a mock database
> > driver that only implements the bare minimum to run the test.
> >
> > [...]
>
> Mocking a fake database can also be huge pain. Especially when
> something like transactions and prepared statements are involved.
>
> Imagine testing your mock for introduced by future extension.

The other way would be to create a test database (or databases) and use
those with the normal code, though you have less control over some stuff
that way. What makes the most sense depends on what you're doing and how
much you're able to really unit test the pieces as opposed to component
testing large chunks of the code at once. And the reality of the matter is
that sometimes testing is a pain, though in the long run, it pretty much
always saves time and pain even if it's a pain to get set up.

- Jonathan M Davis

Re: how to make private class member private

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 18, 2018 18:59:39 Tony via Digitalmars-d-learn wrote:
> On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote:
> > They're similar, but there are differences. For instance, you
> > can do package(a) in D in order to do something like put the
> > stuff in a.b.c in package a rather than a.b.
>
> Is there a known situation where it makes sense to put module c
> in directory/package b - rather than directory/package a, and
> then tell the D compiler to treat it like it was in
> directory/package a?

I don't think that you can have anything in a/b/c.d marked as if it were in
package a/z. It's only for putting stuff higher up in the package hierarchy
while allowing it to be placed in modules deeper in the hierarchy, not for
moving it laterally within the package hierarchy. One place where it's used
(and which IIRC was the motivating reason for its implementation) is
std.internal.* in Phobos. At least some of what's there is marked with
package(std) (and probably all of it should be, but a lot of it predates the
improvement to package). That way, stuff that's essentially private to
Phobos can be organized there but be used by anything in Phobos, whereas
without the improvement to package, they'd all have to be modules directly
under std (probably all with internal in their module names) in order to
have them being treated as being in the std package. So, ultimately, it's
about better organization and probably is something that only makes sense
for when entire modules are essentially private to a library and not for
modules that mix public and package symbols.

- Jonathan M Davis

Re: Testing D database calls code for regression

[aberba via Digitalmars-d-learn]

On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via 
Digitalmars-d-learn wrote:

[...]


The usual way I do this is to decouple the code from the real 
database backend by templatizing the database driver.  Then in 
my unittest I can instantiate the template with a mock database 
driver that only implements the bare minimum to run the test.


[...]


Mocking a fake database can also be huge pain. Especially when 
something like transactions and prepared statements are involved.


Imagine testing your mock for introduced by future extension.

[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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
I would vote to close this as WONTFIX. You may want to test things inside your
unit test that have nothing to do with the example, but use the same code for
setup, and then you have to write that code twice. It's pretty easy to say //
private data, for testing only.

--

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 19:01:11 UTC, Joe wrote:
I managed to get it working by declaring a D dynamic array, 
appending n_recs pointers to it and using it as argument to 
sort. Unfortunately, I then had to copy from the dynamic array 
to the fixed array in order to continue using the latter. Any 
shortcuts around this?


I just saw your other reply.  Passing recs[0..n_recs] does the 
trick. Thanks.

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 18:11:02 UTC, Dmitry Olshansky wrote:
Well since recs is array of pointers this looks like a null 
pointer in your data.


The usual ways to fix that is either print stuff or poke around 
in debugger to see if a Record* is null or .name is null.


The problem is that although the "recs" array is declared as 
having 10 pointers, not all pointers are used.  In the qsort 
case, the second argument limited the sort to just the first 
n_recs (valid) pointers. There doesn't seem to be a way to tell 
std.algorithm.sorting.sort to only look at part of the fixed 
array.


I managed to get it working by declaring a D dynamic array, 
appending n_recs pointers to it and using it as argument to sort. 
Unfortunately, I then had to copy from the dynamic array to the 
fixed array in order to continue using the latter. Any shortcuts 
around this?

Re: help cast

[Steven Schveighoffer via Digitalmars-d]

On 3/18/18 2:24 PM, Jonathan M Davis wrote:

On Sunday, March 18, 2018 13:10:28 Steven Schveighoffer via Digitalmars-d
wrote:

On 3/18/18 4:34 AM, sdvcn wrote:

dchar v11=dchar.max;

  auto vp11 = [v11];

  auto v2 = cast(ubyte[]) (vp11);   //v2.length=4
  auto v22 = cast(ubyte[])( [v11]); //v2.length=1


This seems like a bug to me.

It appears that v22 has truncated v11 to a byte and made only a single
byte array out of it.


Except that that's precisely how you usually get an array any integral type
smaller than an integer. e.g.

auto arr = cast(ubyte[])([1, 2, 3, 4]);

In this case, you could do

ubyte[] arr = [1, 2, 3, 4];

instead, but if you're not dealing with an initializaton or assignment like
this (e.g. you're passing the array to a functon), then the cast is the way
you do it. Normally, you do it with integer literals, and I could see an
argument that it shouldn't allow it without VRP being used to make it work,
but it _is_ a cast, and casts are a bit of a blunt instrument.

So, I really don't think that it's a bug.



It's quite possible that you aren't understanding what is happening:

ubyte[] arr = cast(ubyte[])[555];
writeln(arr); // [43]

Why is this not a bug? I didn't cast the 555 to a ubyte, so it should 
either complain that it can't do it, or give me an array of 4 bytes.


I guess it could be explained as the same thing as:

ubyte[] arr = [cast(ubyte)555];

But this is surprisingly weird behavior.

-Steve

Re: how to make private class member private

[Tony via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 18:32:42 UTC, Jonathan M Davis wrote:



They're similar, but there are differences. For instance, you 
can do package(a) in D in order to do something like put the 
stuff in a.b.c in package a rather than a.b.


Is there a known situation where it makes sense to put module c 
in directory/package b - rather than directory/package a, and 
then tell the D compiler to treat it like it was in 
directory/package a?

Re: how to make private class member private

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/17/18 5:56 AM, Nick Treleaven wrote:

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`.


If we could go back in time and talk with a young Walter about the 
consequences of choosing the scheme the way it is, maybe he might have 
made different choices, but at this point, it's hard to change it.


Note, again, you can do pretty much every privacy scheme you want with 
package modules today. Before, it was a lot less nice.


It's pretty simple: all your friends go into the module. All your 
external functions that should only use the public API have to go 
elsewhere. I think the thing that bites people is simply that they 
aren't used to it.




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, 


While this is a limitation that I wish wasn't there, constructors aren't 
always the best way to build a type.


But there are other reasons to put functions that access private pieces 
outside the aggregate. For instance, if you want to accept a struct by 
value.





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

Why not?

unittest
{
   auto foo = new Foo;
   assert(foo.internalbuffer.empty); // note, this is a private symbol.
}

I can do the same thing in ddoc, but without the benefit of having the 
unit test run. Forcing me to do it that way is just annoying (I will 
have to duplicate the code).


-Steve

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

[Abdulhaq via Digitalmars-d-announce]

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


[...]


Congratulations, it's a nice bit of fun.

Re: core.stdc.stdlib._compare_fp_t and qsort

[Dmitry Olshansky via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 18:11:02 UTC, Dmitry Olshansky wrote:

On Sunday, 18 March 2018 at 16:45:16 UTC, Joe wrote:

[...]


No it just creates a pair of pointer to recs[0] + length of 
recs, like this:


struct Array
{
  size_t length;
  Record* ptr;
}

In D it’s typed as Record[] and has a number of nice 
properties, like not losing its length;)



[...]


Well since recs is array of pointers this looks like a null 
pointer in your data.


Or rather if 10 is capacity and num_recs is actual length, then:

recs[0..num_recs] is the slice with data that you want to sort.

Re: how to make private class member private

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 18, 2018 18:04:13 Tony via Digitalmars-d-learn wrote:
> On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
> > D is not C++, C#, or Java. C++ uses friend to get around the
> > issue. Java has no solution. I don't know about C#.
>
> Java has four protection levels. If you don't explicitly specify
> [private, protected, public] the protection level is implicitly
> "package-private". That means that any class in the same package
> can access that attribute. I believe that Java packages are
> identical to D packages.

They're similar, but there are differences. For instance, you can do
package(a) in D in order to do something like put the stuff in a.b.c in
package a rather than a.b. Also, package functions in D are never virtual,
which I expect is not the case for Java. The whole situation is also
complicated somewhat by the fact that D allows pretty much anything at
module-level, whereas as Java requires one class per module, though I'm not
sure that that has much direct effect on package itself other than the fact
that it's possible in D to mark stuff package that isn't in a class.

- Jonathan M Davis

Re: help cast

[Jonathan M Davis via Digitalmars-d]

On Sunday, March 18, 2018 13:10:28 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 3/18/18 4:34 AM, sdvcn wrote:
> > dchar v11=dchar.max;
> >
> >  auto vp11 = [v11];
> >
> >  auto v2 = cast(ubyte[]) (vp11);   //v2.length=4
> >  auto v22 = cast(ubyte[])( [v11]); //v2.length=1
>
> This seems like a bug to me.
>
> It appears that v22 has truncated v11 to a byte and made only a single
> byte array out of it.

Except that that's precisely how you usually get an array any integral type
smaller than an integer. e.g.

auto arr = cast(ubyte[])([1, 2, 3, 4]);

In this case, you could do

ubyte[] arr = [1, 2, 3, 4];

instead, but if you're not dealing with an initializaton or assignment like
this (e.g. you're passing the array to a functon), then the cast is the way
you do it. Normally, you do it with integer literals, and I could see an
argument that it shouldn't allow it without VRP being used to make it work,
but it _is_ a cast, and casts are a bit of a blunt instrument.

So, I really don't think that it's a bug.

- Jonathan M Davis

Re: core.stdc.stdlib._compare_fp_t and qsort

[Dmitry Olshansky via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 16:45:16 UTC, Joe wrote:
On Sunday, 18 March 2018 at 13:10:08 UTC, Dmitry Olshansky 
wrote:

Do this to get the usual ptr + length:

sort!((a, b) => to!string((*a).name) < 
to!string((*b).name))(recs[]);


Also to!string would be computed on each compare anew. May 
want to use schwartzSort to avoid that, on 10 elements there 
is no real difference though.


The 10 elements are just because it's a small test program.

What does changing "recs" to "recs[]" as the argument actually 
do?  Does it duplicate the fixed array on the fly? [I guess I 
have to study more!]


No it just creates a pair of pointer to recs[0] + length of recs, 
like this:


struct Array
{
  size_t length;
  Record* ptr;
}

In D it’s typed as Record[] and has a number of nice properties, 
like not losing its length;)


The change does pass the compiler, but at runtime it causes a 
segfault.  The next to last frame in the backtrace shows 
(having changed from to!string to fromStringz and using a 
string template instead of a lambda):


Well since recs is array of pointers this looks like a null 
pointer in your data.


The usual ways to fix that is either print stuff or poke around 
in debugger to see if a Record* is null or .name is null.


#6  0x55565760 in 
std.algorithm.sorting.sort!("fromStringz((*a).name.ptr) < 
fromStringz((*b).name.ptr)", 0, 
testd.Record*[]).sort(testd.Record*[]) (r=...)




Also you don’t need (*a).name, D understands that . can access 
data through pointer (what would be an error in C and require ->).


Then it goes through quickSortImpl, shortSort and sort5, moving 
on to either std.functional.binaryFun or processing of the 
lambda, with a and b equal to 0, ending with a segfault in a ?? 
call from fromStringz or in memcpy called from object._dup (in 
the to!string case).

Re: how to make private class member private

[Tony via Digitalmars-d-learn]

On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:



D is not C++, C#, or Java. C++ uses friend to get around the 
issue. Java has no solution. I don't know about C#.




Java has four protection levels. If you don't explicitly specify 
[private, protected, public] the protection level is implicitly 
"package-private". That means that any class in the same package 
can access that attribute. I believe that Java packages are 
identical to D packages.

[Issue 17759] struct that attempts to implicitly cast away const causes segfault

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

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

--- Comment #3 from Steven Schveighoffer  ---
Hm... so alias this resolution needs some kind of memoization to prevent
infinite expansion. Interesting.

--

Re: RBTree delegates and types

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/18/18 8:34 AM, Viktor wrote:

Hey,

I'm trying to convert an old legacy app to D and have a couple of 
questions. It has been a very fun weekend!


First, I could not make std.container.rbtree use a delegate for a 
comparator. The docs say it should be possible, but I got a weird error.


I tracked it down to RedBlackTreee.opEquals() using explicit function 
when calling equals():


return equal!(function(Elem a, Elem b) => !_less(a,b) && 
!_less(b,a))(thisRange, thatRange);


When I removed the "function" things started compiling (I have yet to 
test the code due to question #2 below). I've done a dub -b unittest 
without issues so it might be OK.


So, the first...several questions are: do you think this change is safe 
and should I raise an issue in the bugzilla or do a PR for it on github? 


Yes, seems like an oversight. RedBlackTree.opEquals was added almost 6 
years ago, and it's possible this wouldn't have worked back then 
(https://github.com/dlang/phobos/pull/900)



Should it include a new unittest that makes sure rbtree can be 
instantiated with a delegate?


Definitely. Thanks for thinking of this!



The other part I'm still struggling with is about auto types. Can I 
store the rbtree type in the following class so it can be used from 
another method?


class Indexer(T, alias pred)
{

  alias RBType = RedBlackTree!(uint, (a, b) => comp(a, b));

    this(T storage)
    {
   this.storage = storage;


 this.index = new RBType();


    }




    void dumpIndex()
    {
    // how to get my dirty hands on the index here?


  // answer: just use it?


    }

    bool comp(uint i1, uint i2)
    {
   auto rec1 = storage[i1];
   auto rec2 = storage[i2];
   return pred(rec1, rec2);
    }

    private T storage;


  RBType index;


}



-Steve

Re: help cast

[Steven Schveighoffer via Digitalmars-d]

On 3/18/18 4:34 AM, sdvcn wrote:

dchar v11=dchar.max;
 auto vp11 = [v11];

 auto v2 = cast(ubyte[]) (vp11);   //v2.length=4
 auto v22 = cast(ubyte[])( [v11]); //v2.length=1



This seems like a bug to me.

It appears that v22 has truncated v11 to a byte and made only a single 
byte array out of it.


-Steve

[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

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

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

--- Comment #2 from ponce  ---
I've posted there, thanks.

--

Re: core.stdc.stdlib._compare_fp_t and qsort

[Joe via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 13:10:08 UTC, Dmitry Olshansky wrote:

Do this to get the usual ptr + length:

sort!((a, b) => to!string((*a).name) < 
to!string((*b).name))(recs[]);


Also to!string would be computed on each compare anew. May want 
to use schwartzSort to avoid that, on 10 elements there is no 
real difference though.


The 10 elements are just because it's a small test program.

What does changing "recs" to "recs[]" as the argument actually 
do?  Does it duplicate the fixed array on the fly? [I guess I 
have to study more!]


The change does pass the compiler, but at runtime it causes a 
segfault.  The next to last frame in the backtrace shows (having 
changed from to!string to fromStringz and using a string template 
instead of a lambda):


#6  0x55565760 in 
std.algorithm.sorting.sort!("fromStringz((*a).name.ptr) < 
fromStringz((*b).name.ptr)", 0, 
testd.Record*[]).sort(testd.Record*[]) (r=...)


Then it goes through quickSortImpl, shortSort and sort5, moving 
on to either std.functional.binaryFun or processing of the 
lambda, with a and b equal to 0, ending with a segfault in a ?? 
call from fromStringz or in memcpy called from object._dup (in 
the to!string case).

[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
See also: https://github.com/dlang/dmd/pull/7640

--

[Issue 18627] New: std.complex is a lot slower than builtin complex types at number crunching

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

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

  Issue ID: 18627
   Summary: std.complex is a lot slower than builtin complex types
at number crunching
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: alil...@gmail.com

BENCHMARK:

Please consider the following program:

It's just number crunching, there is no complex exponential or such function
calls.
The FFT function features complex addition, multiplication and division.

--- main.d


import std.string;
import std.datetime;
import std.datetime.stopwatch : benchmark, StopWatch;
import std.complex;
import std.stdio;
import std.math;

void main()
{
cfloat[] A = new cfloat[1024];
cdouble[] B = new cdouble[1024];
Complex!float[] C = new Complex!float[1024];
Complex!double[] D = new Complex!double[1024];
foreach(i; 0..1024)
{
// Initialize with something
A[i] = i + 0i;
B[i] = i + 0i;
C[i] = Complex!float(i, 0);
D[i] = Complex!double(i, 0);
}

void fA()
{
bench!(float, cfloat, true)(A);
}

void fB()
{
bench!(double, cdouble, true)(B);
}

void fC()
{
bench!(float, Complex!float, false)(C);
}

void fD()
{
bench!(double, Complex!double, false)(D);
}

auto r = benchmark!(fA, fB, fC, fD)(1000);
Duration fAResult = r[0];
Duration fBResult = r[1];
Duration fCResult = r[2];
Duration fDResult = r[3];
writefln("With cfloat: %s", fAResult);
writefln("With cdouble: %s", fBResult);
writefln("With Complex!float: %s", fCResult);
writefln("With Complex!double: %s", fDResult);
}

void bench(T, ComplexType, bool usingBuiltinTypes)(ComplexType[] array)
{
// forward then reverse FFT
FFT!(T, ComplexType, true, usingBuiltinTypes)(array);
FFT!(T, ComplexType, false, usingBuiltinTypes)(array);
}

// just for the benchmark purpose
private void FFT(T, ComplexType, bool direction, bool
usingBuiltinTypes)(ComplexType[] buffer) pure nothrow @nogc
{
int size = cast(int)(buffer.length);
int m = 10;

ComplexType* pbuffer = buffer.ptr;

// do the bit reversal
int i2 = cast(int)size / 2;
int j = 0;
for (int i = 0; i < size - 1; ++i)
{
if (i < j)
{
auto tmp = pbuffer[i];
pbuffer[i] = pbuffer[j];
pbuffer[j] = tmp;
}

int k = i2;
while(k <= j)
{
j = j - k;
k = k / 2;
}
j += k;
}

// compute the FFT
static if (usingBuiltinTypes)
{
ComplexType c = -1+0i;
}
else
{
ComplexType c = -1;
}
int l2 = 1;
for (int l = 0; l < m; ++l)
{
int l1 = l2;
l2 = l2 * 2;
static if (usingBuiltinTypes)
{
ComplexType u = 1+0i;
}
else
{
ComplexType u = 1;
}
for (int j2 = 0; j2 < l1; ++j2)
{
int i = j2;
while (i < size)
{
int i1 = i + l1;
ComplexType t1 = u * pbuffer[i1];
pbuffer[i1] = pbuffer[i] - t1;
pbuffer[i] += t1;
i += l2;
}
u = u * c;
}

T newImag = sqrt((1 - c.re) / 2);
static if (direction)
newImag = -newImag;
T newReal = sqrt((1 + c.re) / 2);

static if (usingBuiltinTypes)
{
c = newReal + 1.0fi * newImag;
}
else
{
c = ComplexType(newReal, newImag);
}
}

// scaling when doing the reverse transformation, to avoid being multiplied
by size
static if (!direction)
{
T divider = 1 / cast(T)size;
for (int i = 0; i < size; ++i)
{
pbuffer[i] = pbuffer[i] * divider;
}
}
}




BENCHMARKS

- With DMD v2.079.0, Windows:

$ rdmd -O -inline -release main.d

With cfloat: 1 sec, 187 ms, 225 ╬╝s, and 5 hnsecs
With cdouble: 1 sec, 315 ms, 385 ╬╝s, and 7 hnsecs
With Complex!float: 2 secs, 451 ms, 319 ╬╝s, and 2 hnsecs  (!)
With Complex!double: 11 secs, 539 ms, and 96 ╬╝s  (!!!)

$ rdmd -O -inline -release main.d -m64

With cfloat: 1 sec, 196 ms, 312 ╬╝s, and 7 hnsecs
With cdouble: 1 sec, 295 ms, 927 ╬╝s, and 9 hnsecs
With Complex!float: 2 secs, 505 ms, 536 ╬╝s, and 4 hnsecs (!)
With Complex!double: 11 secs, 590 ms, 574 ╬╝s, and 4 hnsecs (!!!)

- With LDC 1.8.0 32-bit:

$ ldc2.exe -O3 -release -enable-inlining main.d

With cfloat: 564 ms, 669 us, and 9 hnsecs
With cdouble: 535 ms, 570 us, and 2 hnsecs
With Complex!float: 563 ms, 809 us, and 4 hnsecs
With Complex!double: 537 ms, 289 us, and 6 hnsecs

- With LDC 1.8.0 64-bit:

$ ldc2.exe -O3 -release 

[Issue 17758] assignment of different vector types should require cast

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
The specification states the following about the implicit conversion between
vectors

> Vector types of the same size can be implicitly converted among each other.

--

Re: How to delete element from array container or dlist?

[Michael via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 15:42:18 UTC, Andrey Kabylin wrote:

On Sunday, 18 March 2018 at 15:32:47 UTC, Michael wrote:

On Sunday, 18 March 2018 at 14:58:52 UTC, Andrey Kabylin wrote:
In DList we have method remove, but I can't understand how 
this method works, I want write somethink like this:

void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}


So I guess you would want something like

subscribers.remove!(a => a == subscriber));

which is the different definition of remove available here:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove.2


Yes this works, thanks!


No problem, glad to help!

[Issue 17988] [ICE] Segfault when using member in map

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bitter.ta...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bitter.ta...@gmx.com ---
Works in master w/ the following output:

---
/tmp/foo.d(5): Error: only one index allowed to index int
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(497):
   instantiated from here: MapResult!(__lambda2, int[])
/tmp/foo.d(5):instantiated from here: map!(int[])
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(602):
   instantiated from here: __lambda2!(int[])
./generated/linux/release/64/../../../../../phobos/std/algorithm/iteration.d(497):
   instantiated from here: MapResult!(__lambda2, int[][])
/tmp/foo.d(5):instantiated from here: map!(int[][])
---

--

[Issue 18025] ICE with __traits(compiles)

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bitter.ta...@gmx.com
 Resolution|--- |FIXED

--- Comment #1 from bitter.ta...@gmx.com ---
Works in master, closing this.

--

[Issue 17759] struct that attempts to implicitly cast away const causes segfault

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

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #2 from bitter.ta...@gmx.com ---
This happens because the built-in `opEquals' that's synthesized by the compiler
contains a condition such as `(p == q)` that's recursively expanded into
`(p.foo == q) and `(p.foo.foo == q)`.
The problem lies in `resolvePropertiesX' that keeps assembling this crazy chain
where the `p' is substituted every step.

--

Re: How to delete element from array container or dlist?

[Andrey Kabylin via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 15:32:47 UTC, Michael wrote:

On Sunday, 18 March 2018 at 14:58:52 UTC, Andrey Kabylin wrote:
In DList we have method remove, but I can't understand how 
this method works, I want write somethink like this:

void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}


So I guess you would want something like

subscribers.remove!(a => a == subscriber));

which is the different definition of remove available here:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove.2


Yes this works, thanks!

Re: How to delete element from array container or dlist?

[Michael via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 14:58:52 UTC, Andrey Kabylin wrote:
In DList we have method remove, but I can't understand how this 
method works, I want write somethink like this:

void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}


The remove function seems to expect an index, not an element.

Re: How to delete element from array container or dlist?

[Michael via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 14:58:52 UTC, Andrey Kabylin wrote:
In DList we have method remove, but I can't understand how this 
method works, I want write somethink like this:

void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}


So I guess you would want something like

subscribers.remove!(a => a == subscriber));

which is the different definition of remove available here:
https://dlang.org/phobos/std_algorithm_mutation.html#.remove.2

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

[bauss via Digitalmars-d-announce]

On Sunday, 18 March 2018 at 12:51:23 UTC, Anton Fediushin wrote:

On Friday, 16 March 2018 at 08:25:30 UTC, bauss wrote:
Besides your encoding isn't going to work with actual 
web-pages anyway, because your encoder doesn't have browser 
support.


Well, encoding is not *mine*, only D implementation is. What do 
you mean by "browser support"? Indeed, ecoji-d cannot be used 
on the client side, but since algorithm is simple and code is 
publically available anyone can implement decoding in 
JavaScript or any other language.




Yes, but that makes your example pointless, because having to 
decode in javascript is not exactly something that anybody in 
their sane mind would ever do with a webpage or anything like 
that anyway.

How to delete element from array container or dlist?

[Andrey Kabylin via Digitalmars-d-learn]

In DList we have method remove, but I can't understand how this 
method works, I want write somethink like this:

void unsubscribe(EventsSubscriber subscriber) {
subscribers.remove(subscriber);
}

Re: How to build static linked executable

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-17 16:42, Seb wrote:


Yes, use -static

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


FYI, -static is not support on macOS.

--
/Jacob Carlborg

Re: Does the compiler inline the predicate functions to std.algorithm.sort?

[Stefan Koch via Digitalmars-d-learn]

On Sunday, 18 March 2018 at 12:59:06 UTC, tipdbmp wrote:
I can't read assembly but it seems to me that it doesn't: 
https://godbolt.org/g/PCsnPT
I think C++'s sort can take a "function object" that can get 
inlined.


Correct it does not get in-lined.
Even with -O3 it does not.

The reason is that the code the sort instantiation produces is 
too big for the inliner cost function.


If you have a look at the the cg file produced when you specify 
-vcg-ast you can see that it's a massive amount of code.

Re: CTFE ^^ (pow)

[Rubn via Digitalmars-d]

On Sunday, 18 March 2018 at 04:37:32 UTC, ketmar wrote:

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).


There was a PR a while ago IIRC, it's probably one of those 
sitting at the back of the queue from 4 years ago or something.

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

[Anton Fediushin via Digitalmars-d-announce]

On Sunday, 18 March 2018 at 11:25:45 UTC, Cym13 wrote:

So I think ecoji-d just truncates its input at some point.


Indeed, there's an error somewhere. For some reason it stops 
after 7457792 bytes. I'll create an issue for that and will look 
into this later

Re: The D Language Foundation at Open Collective

[Dmitry Olshansky via Digitalmars-d-announce]

On Sunday, 18 March 2018 at 13:23:08 UTC, Dmitry Olshansky wrote:
On Thursday, 15 March 2018 at 17:08:28 UTC, Ola Fosheim Grøstad 
wrote:
On Thursday, 15 March 2018 at 17:06:00 UTC, Ola Fosheim 
Grøstad wrote:

On Thursday, 15 March 2018 at 14:13:10 UTC, Mike Parker wrote:
At the current exchange rate, a venti-sized cup of drip 
coffee at Starbucks in Korea is $4.51. When I go to GA, it's 
cheaper. A venti Americano is $4.79. But I think when people 
talk about $5 coffees, they're referring to lattes and all 
the other forms of polluted espresso abominations people 
drink.


According to this article Russian Starbucks charge $12.30 for 
a latte...


https://www.thespruce.com/how-much-is-starbucks-coffee-766065


Or actually, a tall cappuccino. Whatever.


More like 6$ I’d say by looking at the actual price over here.


Some facts for a change, the actual price list:

PS: 
http://www.starbucks.ru/media/Цены%20на%20основные%20напитки_2018_01_tcm84-35742.pdf


I do not see anything above ~300-400₽.
Which is 5-6$.