Re: Release D 2.090.0
On 2/25/20 2:40 PM, uranuz wrote: Seems that I managed to slightly reduce the problemme. I suspect that error is somehow connected with running my code inside TaskPool: https://dlang.org/library/std/parallelism/task_pool.html `Memory allocation failed` error occurs when I throw any exception even trivial one: throw new Exception(`Test`) I have 3 modes of my small web server: 1. The main mode uses TaskPool to create fixed pool of working threads. 2. The second mode just creates new thread for every connection using class inherited from: import core.thread: Thread; 3. And the third variation is most stupid. It handles all requests in single thread. The second and third variant working normally. But the first generates memory allocation error when I throw Exception inside of it. There was no such error before 2.090. I have tried forcibly recompile the same version of my code with 2.089 and 2.090. And version compiled with 2.089 doesn't have this issue. Do anybody knows what could be changed or what else to try? Have you tried valgrind or similar tools? Memory errors are the worst. "Memory allocation failed" seems to suggest however that you are out of memory. But with memory errors - it's quite possible the problem is still in 2.089, but some small change causes the memory issue to come out. -Steve
Re: Release D 2.090.0
Seems that I managed to slightly reduce the problemme. I suspect that error is somehow connected with running my code inside TaskPool: https://dlang.org/library/std/parallelism/task_pool.html `Memory allocation failed` error occurs when I throw any exception even trivial one: throw new Exception(`Test`) I have 3 modes of my small web server: 1. The main mode uses TaskPool to create fixed pool of working threads. 2. The second mode just creates new thread for every connection using class inherited from: import core.thread: Thread; 3. And the third variation is most stupid. It handles all requests in single thread. The second and third variant working normally. But the first generates memory allocation error when I throw Exception inside of it. There was no such error before 2.090. I have tried forcibly recompile the same version of my code with 2.089 and 2.090. And version compiled with 2.089 doesn't have this issue. Do anybody knows what could be changed or what else to try?
Re: DIP 1027---String Interpolation---Format Assessment
On Mon, Feb 24, 2020 at 10:54:34PM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] > Writing that an implementation must refer to specific templates > implies that the behavior is customizable by the user via modifying > those templates. I think this is where the misunderstanding is. The proposed template is defined by druntime, and is NOT customizable by the user. Unless, of course, they modify druntime, but then, if they're going to do that, they could just as easily modify the meaning of various internal symbols in druntime that dmd refers to, like change _adEq2 to do something completely alien. But the expectation is that users generally would not do this. Similarly, wrapping the interpolated tuple in a template is not customizable by the user. Rather, its sole purpose is to provide a distinct type from `string` that user can overload on, if they so wish. T -- The easy way is the wrong way, and the hard way is the stupid way. Pick one.
Re: DIP 1027---String Interpolation---Format Assessment
On 2/25/20 10:13 AM, Adam D. Ruppe wrote: On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote: I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type! Well, compiler magic, possibly with more @attributes. But that gets far messier than a simple struct, so we rejected it in the other thread. I just added a section to my dip text explaining this though: https://github.com/dlang/DIPs/pull/186/files#diff-2d3c5bf5c5d1f001279a15e3449b2338R325 basically once we address all the inevitable questions such a new thing would raise, we would essentially reinvent a struct with a new, awkward syntax anyway. So my view is a struct is a simple, understandable, and proven solution. I think it's important that the compiler isn't involved with type construction, just lowering. It keeps things simple in the compiler. -Steve
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote: On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote: [...] Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago and it is now on github too! https://github.com/dlang/DIPs/pull/186 [...] I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type! ``How to distinguish a different type? Use a different type. No, is there another simpler way to do that instead?`` Is this really the line of thinking going on here? It seems Walter has these arbitrary rules he's following which led up to the impractical and buggy solution that was DIP1027. Rules aren't meant to be followed blindly.
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote: I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type! Well, compiler magic, possibly with more @attributes. But that gets far messier than a simple struct, so we rejected it in the other thread. I just added a section to my dip text explaining this though: https://github.com/dlang/DIPs/pull/186/files#diff-2d3c5bf5c5d1f001279a15e3449b2338R325 basically once we address all the inevitable questions such a new thing would raise, we would essentially reinvent a struct with a new, awkward syntax anyway. So my view is a struct is a simple, understandable, and proven solution.
Re: DIP 1027---String Interpolation---Format Assessment
On 2/25/20 8:39 AM, Aliak wrote: On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote: [...] Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago and it is now on github too! https://github.com/dlang/DIPs/pull/186 [...] I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type! I think there is not, unless you wanted to implement special rules in the compiler for string interpolations. And that would be akin to overloading (something like "you have to tag a function as @acceptsinterpolation to have it work with interpolated strings"). Much simpler to just have a different type. -Steve
Re: DIP 1027---String Interpolation---Format Assessment
On 2/25/20 1:54 AM, Walter Bright wrote: On 2/24/2020 2:45 PM, Steven Schveighoffer wrote: My inference of the discussion about this in the n.g. was the templates would be used so users could customize the behavior to be whatever they wanted. By accepting a different type from string. In other words, an overload. This means you can have code that treats an interpolated string differently than a string. Overloads based on literal types are not a new feature. Were you proposing that an i"" be a different type? (DIP 1027 did not assign a type to it at all.) No, I proposed that the first element of the tuple be specified as a new spec-defined type instead of a string. I would love to have there be a way to specify that it's a specialized type that is akin to string literals. I'm not qualified to do that, and I'm not sure it's something we want to do (this WOULD be extra complicated and require some compiler magic). I would note that it seems uncharacteristic for string enums to not be equivalent to string literals. If that were the case, this type WOULD be easy to set up effectively as a string literal. Having the type detailed in the spec and implemented in the library is a "low cost" solution. Effectively, even though it doesn't need to be specified how this works, the compiler-library interaction is done via simple lowering, and the existing compiler has all the tools to implement the new type already. This would be radically different from DIP 1027, and a large increase in complexity (adding any new basic types is a big deal and a very intrusive change, and is tough to justify). It's not a basic type in terms of a type defined by the compiler, but a type defined by the spec and implemented in the library (with existing language mechanisms). It's not intrusive at all, the changes to your proposed DIP are minimal, as it's still lowering. This is different enough from DIP 1027 that it would merit a separate DIP. Adam is working on this: https://github.com/dlang/DIPs/pull/186 DIPs for the core language specify only behaviors, not implementations. Implementation possibilities can be included in an advisory manner only. Note that nowhere in the (massive and complicated) C++ core language specification is there any description of how the compiler should be implemented. Writing that an implementation must refer to specific templates implies that the behavior is customizable by the user via modifying those templates. I understand, and I think we can reword the DIP proposal to reflect that. -Steve
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 13:39:40 UTC, Aliak wrote: On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote: [...] Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago and it is now on github too! https://github.com/dlang/DIPs/pull/186 [...] I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type! In my opinion the only really viable solutions are either to lower to a function call to format (or similar) such that typeof(i"") == string or a new type such as Adam describes so that functions can add overloads for it (and specialized compiler errors for common misuse cases). Anything else and you risk users running into inexplicable errors because their string isn't a string.
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 13:04:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote: [...] Yes, that is the key impetus of our amendment, which I also wrote up on a gist weeks ago and it is now on github too! https://github.com/dlang/DIPs/pull/186 [...] I should’ve been more specific I was wondering if the same could be achieved without a introducing a new aggregate type!
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 09:36:25 UTC, aliak wrote:
This may have already been answered in the other threads, but I
was just wondering if anyone managed to propose a way to avoid
this scenario with DIP1027?
Yes, that is the key impetus of our amendment, which I also wrote
up on a gist weeks ago and it is now on github too!
https://github.com/dlang/DIPs/pull/186
By putting a new type around the generated format string, the
f(i"") is a type mismatch error, so the user can decide what they
want to do (I propose having the compiler suggest you call
`.idup` on it to copy it into an ordinary GC string for new users
to quickly get going with it.)
That's all our amendment fundamentally does.
Walter's: i"test $foo" -> "test %s", foo
Our's:i"test $foo" -> wrapper!("test ", thing(null)), foo
The `thing` there represents the interpolated item and
user-defined format string. Since there isn't one, it is passed
null.
The `wrapper` there is a new type.
Both `thing` and `wrapper` are defined by the language and their
actual implementations live in druntime
struct thing { string specifier; }
struct wrapper(format_string_pieces...) {}
From the language perspective, the rest is the same was Walter's
proposal. Just with that wrapper type:
foo(string, int) // type error, cannot convert wrapper to string
to protect from that.
Re: DIP 1027---String Interpolation---Format Assessment
On Tuesday, 25 February 2020 at 07:07:50 UTC, Walter Bright wrote: All DIP1027 did was turn an istring into a tuple. That's it. The user can then do whatever they want with the tuple, including overloading a custom function based on the tuple arguments. DIP1027 did not actually do ANY formatting at all. This may have already been answered in the other threads, but I was just wondering if anyone managed to propose a way to avoid this scenario with DIP1027? void f(string s, int i = 0); f(i"hello $a"); // silent unwanted bahviour. ?
Re: Earcut polygon triangulation
On Monday, 24 February 2020 at 20:28:20 UTC, Ben Jones wrote: On Monday, 24 February 2020 at 19:15:13 UTC, JN wrote: On Sunday, 23 February 2020 at 16:20:09 UTC, Ahmet Sait wrote: Out of curiosity, why would you need to triangulate polygons instead of using stencil buffer? I'm assuming you're using OpenGL (or something similar) since you talked about your hobby game. Any advantage of triangulating shapes? (anti-aliasing maybe?) Triangulation goes beyond rendering. I imagine this library might be useful when making a level editor for a DOOM-like 2.5D engine. It's very poorly documented, but I wrote a delaunay refinement triangulator: https://github.com/benjones/dtriangulate . It's mostly a reimplementation of Shewchuk's Triangle which is probably the most common delaunay triangulator. Both of these libraries would have been useful a year ago when I was writing my 3d printable vases generator in D :)
