Re: CTFE ^^ (pow)
On 18 March 2018 at 21:34, bachmeier via Digitalmars-d wrote: > 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. I dun supported.
Re: Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?
On Thursday, 15 March 2018 at 14:13:25 UTC, jmh530 wrote:
On Thursday, 15 March 2018 at 12:49:22 UTC, jmh530 wrote:
[snip]
It looks like it should expand the alias earlier. No problem
with auto foo (T)(S!(1, T) v) {};
Also, this issue also shows up in mir.ndslice.traits. I had to
do the equivalent of isV below. It doesn't work to do the
alternate version. However, given that you have the traits,
then you can use them in a template constraint. So you have to
repeat yourself in the trait once, rather than bunches of times
in each function that calls them.
enum bool isV(T) = is(T : S!(1, U), U);
enum bool isV_alternate(T) = is(T : V!(U), U);
This does not help in practice because ndslice has an alias this
primitive to be implicitly convertible to const version.
For example for array one can write:
auto foo(T)(const(T)[] ar) {}
And this would work with double[] and immutable(double)[] as
well. The same true for ndslice:
auto foo(T)(Slice!(Contiguous, [1], const(T)*)[] ar) {}
It is very important to do not create additional institutions for
numeric code because usually it is quite heavy.
I don't know DMD internals. How the aliasing issue can be solved?
Best regards,
Ilya
Re: Lazy caching map | Mir version
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)
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)
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)
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)
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: CTFE ^^ (pow)
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)
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: CTFE ^^ (pow)
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)
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)
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)
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
Re: CTFE ^^ (pow)
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: CTFE ^^ (pow)
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)
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)
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)
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)
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: CTFE ^^ (pow)
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: CTFE ^^ (pow)
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: CTFE ^^ (pow)
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)
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)
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)
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: help cast
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)
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: CTFE ^^ (pow)
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: CTFE ^^ (pow)
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.
Re: CTFE ^^ (pow)
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)
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)
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: CTFE ^^ (pow)
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: help cast
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: help cast
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: help cast
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: help cast
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
Re: CTFE ^^ (pow)
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: CTFE ^^ (pow)
On Sunday, 18 March 2018 at 07:47:24 UTC, Nicholas Wilson 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?
Hello, I also needed this recently! I was surprised to see that
^^ isn't CTFE but just a pow call.
- main.d ---
T convertDecibelToLinearGain(T)(T dB) pure nothrow @nogc
{
static immutable T ln10_20 = cast(T)LN10 / 20;
return exp(dB * ln10_20);
}
void main()
{
enum foo = convertDecibelToLinearGain!float(-24);
}
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Sunday, 18 March 2018 at 06:28:11 UTC, Amorphorious wrote: And who the fuck are you? See, it's funny how you say I'm a noob with mental problems that says shit about people yet you are doing THE EXACT SAME THING! At the very least, you are no better than me, in fact worse, because you pretend you are all high and mighty and then throw your underhanded attacks in. hey. I understand that someone saying you have mental problems can be taken as an attack. I think the person that made the comment, should not have said it. I think we all have mental problems... it's comes from being human ;-) I volunteer in the mental health sector, so I know the mental health issues and being human seem highly correlated ;-) In any case, you are clearly a very intelligent person (based on my analysis of your previous discussions over a long... period of time), so why not use your brain to benefit people instead of attacking them? Try to explain how people are wrong, so they can learn. Don't call people morons. It's pointless, and just reflects badly on you.
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Saturday, 17 March 2018 at 06:46:17 UTC, Uknown wrote: https://opensource.com/article/18/3/avoid-humiliating-newcomers Its a blog post about how sometimes expert programmers treat newcomers badly. I haven't really noticed any of what he mentions in the D community, as most of the regular members are very polite and friendly, but I thought it was an important read nonetheless. Most assholes in programming forums are intermediate level, and young. They've got enough experience to overvalue their own opinion, and they are young enough that they get offended easily when someone disagrees with them.
Re: D beyond the specs
On Sunday, 18 March 2018 at 07:06:37 UTC, Ali Çehreli wrote: It may not be distributor greed: I was one of the founders of a WordPerfect distributor in Turkey in around 1991. Cool :-) I don't know whether it was the US government rules or WordPerfect rules but they simply could not sell us anywhere near what US consumers were paying. $500 in Turkey is still an impossibly high price. *nods* I find it kinda interesting that the global distribution that came with the Internet may have made it more difficult to differentiate prices, both ways. Also harder to sell with lower margins in 3rd world countries. E.g. on Amazon you can now find cheaper reprints of textbooks targeting universities in India... Of course, localized software (language barrier) may still be used to differentiate.
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Sunday, 18 March 2018 at 06:28:11 UTC, Amorphorious wrote: We might as well add an IQ test too it, the one with the lower IQ kills himself and does the rest of humanity a favor? Or is this another deal you will reject? Just wow.
Re: CTFE ^^ (pow)
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.)
help cast
dchar v11=dchar.max; auto vp11 = [v11]; auto v2 = cast(ubyte[]) (vp11); //v2.length=4 auto v22 = cast(ubyte[])( [v11]); //v2.length=1 y22.length <> v2.length
Re: CTFE ^^ (pow)
Nicholas Wilson 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? building gamma tables in CTFE. and LUT tables for XYZ color space.
Re: CTFE ^^ (pow)
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?
Re: Disallowing the creation of objects using new should have default object functions and parent functions be @nogc by definition.
On Saturday, 17 March 2018 at 13:30:25 UTC, 12345swordy wrote: It makes no sense otherwise. This logically implies that manual memory management is required, yet there is a possibility that the parent of the class may use the garbage collection. Which in this case, it begs the question on why the GC is forbid in the first place. Does anyone dispute this? No, it's even required. Mixing GC and non-GC is a known source of memory errors, but rather in the opposite way that the one you describe. Errors happen when non-GC instances has GC-managed members. To be consistent on this point there are templates like in the Containers library (ShouldAddGcRange) or like in IZ (MustAddGcRange). The latter is inspired by the first and is enhanced with a system of UDA (@NoGc). Also compilation can be stopped if by error a GC-managed field is found. After developing this in IZ, many memory problems i had in KHEOPS suddenly disappeared and a kind of animated 2D scene started to run for hours without disappearing elements (previously a GC collection was causing this). Enriched by this experience i can confirm that there's nothing to dispute at all. You're 100% correct.
Re: D beyond the specs
On 03/17/2018 02:31 AM, Ola Fosheim Grøstad wrote: > I don't know about compilers specifically, but the big distributors in > Europe charged some hefty margins on their imports. So pricing in US was > often much lower than here... It may not be distributor greed: I was one of the founders of a WordPerfect distributor in Turkey in around 1991. When retail price was around $500, we were paying around $400 to WordPerfect when US consumers were getting it for something like $120 at retail shops. (I cannot be sure about the amounts after all those years.) I don't know whether it was the US government rules or WordPerfect rules but they simply could not sell us anywhere near what US consumers were paying. $500 in Turkey is still an impossibly high price. We survived for a while selling to large companies. Ali
