Re: package methods are final? huh?

On 2 October 2016 at 21:40, rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 03/10/2016 12:37 AM, Manu via Digitalmars-d wrote: >> >> module x.a; >> >> class A >> { >>

package methods are final? huh?

module x.a; class A { package: int f() { return 0; } } module x.b; import x.a; class B : A { package: override int f() { return 0; } } > error : function x.b.B.f package method is not virtual and cannot override Why? I have a UI system with

Re: inout delegate

And what's the logic behind this: class Test { int f() { return 10; } static assert(is(typeof((this).f) == int function())); // huh? static void t() { // as expected: f(); // error : need 'this' for 'f' of type 'int()' // calling a method without a context pointer...

inout delegate

Can someone explain this to me? class Test { inout(int) f() inout { return 10; } void t() { f(); // calls fine with mutable 'this' auto d = // error : inout method Test.f is not callable using a mutable this d(); } } That error message seems very unhelpful, and it's not

Re: std.math.isPowerOf2

On 2 October 2016 at 13:46, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 10/01/2016 11:05 PM, Manu via Digitalmars-d wrote: >> >> Unsigned case is: >> return (x & -x) > (x - 1); >> >> Wouldn't this be better: >

debugging mixins

This comes up a lot. As far as I know, it's not solved. What shall we do? I feel like a simple solution would be to have the compiler emit a _mixin.d file populated with all the mixin expansions beside the .obj files, and have the debuginfo refer to that fabricated source file? It might look a

std.math.isPowerOf2

Unsigned case is: return (x & -x) > (x - 1); Wouldn't this be better: return (sz & (sz-1)) == 0; I also don't understand the integer promotion and recursive call in the integer case. Can someone explain how the std.math implementation is ideal?

Re: LDC, GDC command line args

On 1 October 2016 at 04:13, Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 30 September 2016 at 14:16, Manu via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: >> I've been googling for a comprehensive list of LDC and GDC command >> li

Re: LDC, GDC command line args

Perfect! How can we protect against this going stale? On 30 September 2016 at 23:23, Nicholas Wilson via Digitalmars-d wrote: > On Friday, 30 September 2016 at 12:16:14 UTC, Manu wrote: >> >> I've been googling for a comprehensive list of LDC and GDC command line >>

Re: LDC, GDC command line args

How did you get there? Even knowing it exists, I can't find a path to that page from other pages... Is this complete and up to date? I have '-fdeprecated' in some existing makefiles, but this doc says '-Wdeprecated' is the flag... not sure which is correct? :/ Also, there seems to be a lot of

LDC, GDC command line args

I've been googling for a comprehensive list of LDC and GDC command line args for ages. I can't find one. I have had to download and install both compilers just to run the --help. Can these compilers please both have such a document in an obvious accessible place like DMD has?

Re: ddoc latex/formulas?

On 15 September 2016 at 23:48, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 09/15/2016 09:12 AM, Manu via Digitalmars-d wrote: >> >> On 15 September 2016 at 22:40, Adam D. Ruppe via Digitalmars-d >> <digitalmars-d@puremagic.com>

Re: ddoc latex/formulas?

On 15 September 2016 at 22:40, Adam D. Ruppe via Digitalmars-d wrote: > On Wednesday, 14 September 2016 at 15:49:27 UTC, bachmeier wrote: >> >> I agree. That's why I quickly gave up on ddoc. > > > My doc generator just pipes special input text through the latex

Re: ddoc latex/formulas?

On 15 September 2016 at 21:39, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/15/16 5:50 AM, Johan Engelen wrote: >> >> On Wednesday, 14 September 2016 at 11:36:11 UTC, Andrei Alexandrescu >> wrote: >>> >>> On

Re: colour lib needs reviewers

On 15 September 2016 at 19:23, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 2016-09-15 09:11, Manu via Digitalmars-d wrote: >> >> Do we mind moving this discussion to the other topic I started >> actually on this topic? &g

Re: ddoc latex/formulas?

On 15 September 2016 at 19:50, Johan Engelen via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Wednesday, 14 September 2016 at 11:36:11 UTC, Andrei Alexandrescu wrote: >> >> On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote: >>> >>> Can we produce fo

Re: colour lib needs reviewers

On 15 September 2016 at 17:38, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/15/2016 12:06 AM, Manu via Digitalmars-d wrote: >> >> I think I have a sense of uneasy-ness that comes from my intuition >> that macros are macros, and I don't k

Re: colour lib needs reviewers

Do we mind moving this discussion to the other topic I started actually on this topic? It's slightly upsetting that this discussion about ddoc is more popular than the colour lib I spent months workinng on :( On 15 September 2016 at 16:55, Jacob Carlborg via Digitalmars-d

Re: colour lib needs reviewers

On 15 September 2016 at 16:44, Walter Bright via Digitalmars-d wrote: > On 9/14/2016 11:11 PM, Walter Bright wrote: >> >> On 9/14/2016 2:31 PM, Andrei Alexandrescu wrote: >>> >>> The resulting look is alien too, as opposed to the more familiar >>> $MACRO(a1, a2, >>>

Re: colour lib needs reviewers

On 15 September 2016 at 13:49, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/14/16 9:28 PM, Manu via Digitalmars-d wrote: >> >> Like, I really just don't care enough to try and understand ddoc >> sufficiently to have a bag of tricks

Re: colour lib needs reviewers

On 15 September 2016 at 07:31, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 09/14/2016 09:28 AM, Manu via Digitalmars-d wrote: >> >> ... I'm just gonna go on the record and say that I am really, really >> not enjoying ddoc ;) &

Re: ddoc latex/formulas?

On 14 September 2016 at 21:36, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote: >> >> Can we produce formulas, or latex in ddoc? Are there any examples in >> phobos I can refer to? >

Re: colour lib needs reviewers

On 14 September 2016 at 22:47, Meta via Digitalmars-d wrote: > On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. It >> really needs reviews. >> >> I added packed-RGB support, including

ddoc latex/formulas?

Can we produce formulas, or latex in ddoc? Are there any examples in phobos I can refer to?

Re: Should debug{} allow GC?

On 14 September 2016 at 10:37, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/12/2016 6:26 PM, Manu via Digitalmars-d wrote: >> >> I'm concerned this would undermind @nogc... If this is supplied in the >> std library, people will use it,

Re: colour lib needs reviewers

On 14 September 2016 at 04:10, Random D user via Digitalmars-d wrote: > > In general, I think basics should be dead simple (even over simplified for > the very basic case) I think they are: import std.experimental.color; RGB8 color("red"); I don't think i's

Re: colour lib needs reviewers

e: >>> >>> Am Tue, 13 Sep 2016 00:37:22 +1000 >>> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: >>> Alright, but hybrid gamma is really not something that can be googled. Or >>> rather I end up at Toyota's Gamma Hybrid product page

Re: colour lib needs reviewers

On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Tue, 13 Sep 2016 12:00:44 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> What is the worth of storing alpha data if it's uniform 0xFF an

Re: colour lib needs reviewers

On 14 September 2016 at 00:56, John Colvin via Digitalmars-d wrote: > On Tuesday, 13 September 2016 at 09:31:53 UTC, Manu wrote: >> >> On 13 September 2016 at 17:47, John Colvin via Digitalmars-d >> wrote: >>> >>> On Tuesday, 13 September

Re: colour lib needs reviewers

On 13 September 2016 at 20:19, ketmar via Digitalmars-d wrote: > On Tuesday, 13 September 2016 at 02:50:02 UTC, Manu wrote: >> >> std.conv.to seems to 'just work' for color type conversion. >> I'd like to support string -> color conversion via std.conv.to; ie: >>

Re: colour lib needs reviewers

On 13 September 2016 at 17:47, John Colvin via Digitalmars-d wrote: > On Tuesday, 13 September 2016 at 01:05:56 UTC, Manu wrote: >>> >>> Also can I swizzle channels directly? >> >> >> I could add something like: >> auto brg = c.swizzle!"brg"; >> >> The result would

Re: colour lib needs reviewers

On 13 September 2016 at 12:05, Walter Bright via Digitalmars-d wrote: > On 9/12/2016 2:08 PM, John Colvin wrote: >> >> On Monday, 12 September 2016 at 19:59:58 UTC, Edwin van Leeuwen wrote: >>> >>> On Monday, 12 September 2016 at 19:55:57 UTC, Guillaume Piolat wrote:

Re: colour lib needs reviewers

On 13 September 2016 at 07:00, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Tue, 13 Sep 2016 00:37:22 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: >> I flip-flopped on this multiple times. >> It's not so simple. &

Re: Should debug{} allow GC?

On 13 September 2016 at 01:14, Gary Willoughby via Digitalmars-d wrote: > On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote: >> >> I'm having a lot of trouble debugging @nogc functions. I have a number of >> debug functions that use GC, but I can't call them

Re: colour lib needs reviewers

On 13 September 2016 at 08:51, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/11/2016 9:14 PM, Manu via Digitalmars-d wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. >> It really needs reviews. > >

Re: colour lib needs reviewers

On 13 September 2016 at 06:29, Random D user via Digitalmars-d wrote: > On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. It >> really needs reviews. >> >> - Manu > > > Hi. I'm just a

Re: colour lib needs reviewers

On 13 September 2016 at 01:30, John Colvin via Digitalmars-d wrote: > On Monday, 12 September 2016 at 13:04:49 UTC, Manu wrote: >> >> >>> 2. Q: is there anything to convert a color to grey scale ? >> >> >> This isn't a short-answer question :) .. There are many ways

Re: colour lib needs reviewers

On 13 September 2016 at 00:37, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 09/12/2016 12:14 AM, Manu via Digitalmars-d wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. >> It really needs reviews. >

Re: colour lib needs reviewers

On 12 September 2016 at 21:13, Guillaume Chatelet via Digitalmars-d wrote: > On Monday, 12 September 2016 at 09:09:29 UTC, Manu wrote: >> >> I thought about it, but it added (even more) complexity, and I'm not >> really sure it's the MO of a color lib to worry about

Re: colour lib needs reviewers

On 12 September 2016 at 21:28, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Mon, 12 Sep 2016 14:14:27 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> I think I'm about as happy with my colour lib as I'm going to be.

Re: colour lib needs reviewers

On 12 September 2016 at 21:31, Guillaume Chatelet via Digitalmars-d wrote: > On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. It >> really needs reviews. >> >> I added packed-RGB support,

Re: colour lib needs reviewers

On 12 September 2016 at 19:30, Basile B. via Digitalmars-d wrote: > On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote: >> >> I think I'm about as happy with my colour lib as I'm going to be. It >> really needs reviews. >> >> I'm not sure what else should be in

Re: colour lib needs reviewers

I thought about it, but it added (even more) complexity, and I'm not really sure it's the MO of a color lib to worry about the endian-ness of storage. I could support "_le"/"_be" suffix on the PackedRGB format string, but then you have to also specify the word size, ie, is the packed color 32bit

colour lib needs reviewers

I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews. I added packed-RGB support, including weird micro-float and shared-exponent formats. They're important for interacting with any real-time rendering libraries. There is only one texture format I'm aware of

Re: [OT] Re: Let's kill 80bit real at CTFE

On 12 September 2016 at 00:31, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Sun, 11 Sep 2016 15:00:12 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> On 9 September 2016 at 21:50, Stefan Koch via Digitalmars-d >

Re: Should debug{} allow GC?

On 11 September 2016 at 21:26, Q. Schroll via Digitalmars-d wrote: > On Sunday, 11 September 2016 at 07:46:09 UTC, Manu wrote: >> >> I'm having a lot of trouble debugging @nogc functions. I have a number of >> debug functions that use GC, but I can't call them from

Should debug{} allow GC?

I'm having a lot of trouble debugging @nogc functions. I have a number of debug functions that use GC, but I can't call them from @nogc code... should debug{} allow @nogc calls, the same as impure calls?

Re: Let's kill 80bit real at CTFE

On 9 September 2016 at 21:50, Stefan Koch via Digitalmars-d wrote: > Hi, > > In short 80bit real are a real pain to support cross-platform. > emulating them in software is prohibitively slow, and more importantly hard > to get right. > 64bit floating-point numbers are

Re: workspace-d 2.7.2 & code-d 0.10.14

On 7 September 2016 at 13:29, WebFreak001 via Digitalmars-d-announce wrote: > On Wednesday, 7 September 2016 at 02:04:21 UTC, Manu wrote: >> >> Awesome work, thanks again! >> Suggest getting the deb hosted in d-apt along with the other tools >> already there,

Re: Taking pipeline processing to the next level

On 7 September 2016 at 12:00, finalpatch via Digitalmars-d wrote: > On Wednesday, 7 September 2016 at 01:38:47 UTC, Manu wrote: >> >> On 7 September 2016 at 11:04, finalpatch via Digitalmars-d >> wrote: >>> >>> >>> It shouldn't be hard to

Re: workspace-d 2.7.2 & code-d 0.10.14

Awesome work, thanks again! Suggest getting the deb hosted in d-apt along with the other tools already there, and set them as dependencies? On 7 September 2016 at 07:05, WebFreak001 via Digitalmars-d-announce wrote: > I just pushed a new release of

Re: Taking pipeline processing to the next level

On 7 September 2016 at 11:04, finalpatch via Digitalmars-d wrote: > > It shouldn't be hard to have the framework look at the buffer size and > choose the scalar version when number of elements are small, it wasn't done > that way simply because we didn't need it. No,

Re: Taking pipeline processing to the next level

On 7 September 2016 at 07:11, finalpatch via Digitalmars-d wrote: > On Tuesday, 6 September 2016 at 14:47:21 UTC, Manu wrote: > >>> with a main loop that reads the source buffer in *12* pixels step, call >>> MySimpleKernel 3 times, then call AnotherKernel 4 times. >>

Re: Taking pipeline processing to the next level

On 7 September 2016 at 01:54, Wyatt via Digitalmars-d wrote: > On Monday, 5 September 2016 at 05:08:53 UTC, Manu wrote: >> >> >> A central premise of performance-oriented programming which I've >> employed my entire career, is "where there is one, there is probably >>

Re: Taking pipeline processing to the next level

On 7 September 2016 at 00:26, finalpatch via Digitalmars-d wrote: > On Tuesday, 6 September 2016 at 14:21:01 UTC, finalpatch wrote: >> >> Then some template magic will figure out the LCM of the 2 kernels' pixel >> width is 3*4=12 and therefore they are fused together

Re: Why is this?

On 6 September 2016 at 21:28, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 06.09.2016 08:07, Manu via Digitalmars-d wrote: >> >> I have weird thing: >> >> template E(F){ >> enum E { >> K = F(1) >> } &

Re: Why is this?

On 6 September 2016 at 16:10, rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 06/09/2016 6:07 PM, Manu via Digitalmars-d wrote: >> >> I have weird thing: >> >> template E(F){ >> enum E { >> K = F(1) >>

Why is this?

I have weird thing: template E(F){ enum E { K = F(1) } } struct S(F = float, alias e_ = E!double.K) {} S!float x; // Error: E!double.K is used as a type alias T = E!double.K; struct S2(F = float, alias e_ = T) {} S2!float y; // alias makes it okay... struct S3(F = float, alias

Re: dlang-vscode

On 6 September 2016 at 14:22, Daniel Kozak via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Dne 6.9.2016 v 03:41 Manu via Digitalmars-d napsal(a): > > >> On 6 September 2016 at 09:51, John Colvin via Digitalmars-d >> <digitalmars-d@puremagic.com> wrote: &g

Re: Taking pipeline processing to the next level

On 5 September 2016 at 23:38, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/5/16 1:43 PM, Ethan Watson wrote: >> >> On Monday, 5 September 2016 at 08:21:53 UTC, Andrei Alexandrescu wrote: >>> >>> What are the benchmarks and the numbers? What loss are you looking

Re: Taking pipeline processing to the next level

On 5 September 2016 at 20:32, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Mon, 5 Sep 2016 10:21:53 +0200 > schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>: > >> On 9/5/16 7:08 AM, Manu via Digitalmars-d wrote: >&

Re: Taking pipeline processing to the next level

On 5 September 2016 at 18:21, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/5/16 7:08 AM, Manu via Digitalmars-d wrote: >> >> I mostly code like this now: >> data.map!(x => transform(x)).copy(output); >> >> It's conve

Re: Taking pipeline processing to the next level

On 5 September 2016 at 16:21, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Mon, Sep 05, 2016 at 03:08:53PM +1000, Manu via Digitalmars-d wrote: >> I mostly code like this now: >> data.map!(x => transform(x)).copy(output); >> >> It's c

Re: dlang-vscode

On 6 September 2016 at 09:51, John Colvin via Digitalmars-d wrote: > On Monday, 5 September 2016 at 22:17:59 UTC, Andrei Alexandrescu wrote: >> >> Google Alerts just found this: >> >> https://marketplace.visualstudio.com/items?itemName=dlang-vscode.dlang >> >> Is

Taking pipeline processing to the next level

I mostly code like this now: data.map!(x => transform(x)).copy(output); It's convenient and reads nicely, but it's generally inefficient. This sort of one-by-one software design is the core performance problem with OOP. It seems a shame to be suffering OOP's failures even when there is no OOP

Re: colour lib

On 4 September 2016 at 03:44, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Sat, 3 Sep 2016 16:01:26 +1200 > schrieb rikki cattermole <ri...@cattermole.co.nz>: > >> On 03/09/2016 12:17 PM, Manu via Digitalmars-d wrote: >> ...snip... &g

Re: ADL

On 5 September 2016 at 10:50, Walter Bright via Digitalmars-d wrote: > On 9/4/2016 2:36 PM, Timon Gehr wrote: >> >> Declare-call ordering issues for overload sets are not limited to local >> scopes. >> This problem needs to be solved anyway. The fact that the scope is

Re: ADL

On 5 September 2016 at 14:05, Manu wrote: > > I've seen this one. Again, we're not talking about C++. It hasn't been > explored (to my knowledge) how a similar mechanism it would look and > affect D. I suspect (with no evidence) it would be relatively benign > by comparison

Re: ADL

On 4 September 2016 at 07:38, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 11:31 AM, Manu via Digitalmars-d wrote: >>> >>> > In any case, these difficulties are the consequence of trying to write >>> > C++ >>

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 22:24, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 7:29 AM, Manu via Digitalmars-d wrote: >> >> On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d >> <digitalmars-d@puremagic.com>

Re: ADL

On 3 September 2016 at 23:04, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 1:24 PM, Walter Bright wrote: >> >> On 9/3/2016 3:12 AM, Walter Bright wrote: >>> >>> If you are still determined to use it, you can use: >>> >>>__traits(compiles, ...) >>> >>>

Re: ADL

On 3 September 2016 at 22:42, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 1:51 AM, Manu via Digitalmars-d wrote: >> >> I've >> never thought about this problem in C++, or had any problems with ADL. > > > How do yo

Re: ADL

On 3 September 2016 at 21:16, Walter Bright via Digitalmars-d wrote: > On 9/3/2016 3:51 AM, Timon Gehr wrote: >> >> By default, name lookup does not work in a way that would allow you to >> actually >> extend types using UFCS, and therefore none of Phobos works that

Re: ADL

On 3 September 2016 at 21:24, Walter Bright via Digitalmars-d wrote: > On 9/3/2016 3:12 AM, Walter Bright wrote: >> >> If you are still determined to use it, you can use: >> >>__traits(compiles, ...) >> >> like you would SFINAE in C++ to select which of the

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 19:19, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 8/31/2016 10:37 PM, Manu via Digitalmars-d wrote: >> >> So, consider a set of overloads: >> >> void f(T)(T t) if(isSomething!T) {} >> void f(T)(T t) if

Re: ADL

On 3 September 2016 at 18:56, Walter Bright via Digitalmars-d wrote: > On 9/3/2016 1:37 AM, Walter Bright wrote: >> >> I thought #4 in particular was rather cool, I plan to use it as an >> example. > > > https://github.com/dlang/phobos/pull/4762 Complexity ramps up

Re: ADL

On 3 September 2016 at 11:09, Walter Bright via Digitalmars-d wrote: > > First solution: > >module bob; >struct S { >void f(); >} This is my current workaround. I'm not happy with it at all. UFCS exists for a reason. > Second solution: > >

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote: >> >> On 3 September 2016 at 00:18, Xinok via Digitalmars-d >> <digitalmars-d@puremagic.com> wrote: >>

Re: ADL

On 3 September 2016 at 11:25, Walter Bright via Digitalmars-d wrote: > On 9/2/2016 6:12 PM, Stefan Koch wrote: >> >> If this feature were supported, it would probably break our module system. >> Even if we could shoehorn it into the language it would make the compiler

phobos unit tests

This document: https://wiki.dlang.org/Contributing_to_Phobos States: "Avoid unittest in templates (it will generate a new unittest for each instance) - put your tests outside" Sounds reasonable, but then I realised that most of my unit tests are documenting unittests... this recommendation is in

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 00:18, Xinok via Digitalmars-d wrote: > > In the past, I have suggested using the "default" keyword to specify a > fallback function of this kind. I think it's a useful pattern for generic > algorithms that have optimized variants on specific

Re: colour lib

On 3 September 2016 at 03:25, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Fri, 2 Sep 2016 15:58:05 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> I wonder, should NormalizedInt be a module beneath the

Re: colour lib

On 2 September 2016 at 22:36, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 8/31/16 1:58 AM, Manu via Digitalmars-d wrote: >> >> I have this implementation issue, which I'm having trouble applying >> good judgement, I'd like to surve

Re: ADL

On 3 September 2016 at 08:38, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/2/2016 5:15 AM, Manu via Digitalmars-d wrote: >> >> In C++, there is this ADL thing (argument dependent lookup). > > > Yeah, I know about Koening lookup. It w

ADL

In C++, there is this ADL thing (argument dependent lookup). What it does is, when searching for overloads, in addition to looking in the local namespace, it also looks in the namespace of the function arguments. D doesn't seem to have this, and that is proving to be quite problematic. What's the

Re: colour lib

On 2 September 2016 at 06:09, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > Am Wed, 31 Aug 2016 15:58:28 +1000 > schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>: > >> I have this implementation issue, which I'm having trouble applying

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 20:43, Dominikus Dittes Scherkl via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: >> >> Consider that more overloads are being introduced by users spread out >> across many modules that define their own kind

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 19:16, Stefan Koch via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 09:08:31 UTC, Manu wrote: >> >> >> This was my fallback plan, but it seems a bit shit. > > > Hmm I get your point. > But there is not really another way within the

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 18:44, Stefan Koch via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: >> >> So, consider a set of overloads: >> >> void f(T)(T t) if(isSomething!T) {} >> void f(T)(T t) if(isSomethingElse!T) {} >> void

Fallback 'catch-all' template functions

So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used in lieu of a more precise match. This is obviously an

Re: colour lib

On 31 August 2016 at 18:04, Andrea Fontana via Digitalmars-d wrote: > On Wednesday, 31 August 2016 at 07:58:36 UTC, Andrea Fontana wrote: > > I forgot that in this way it's quite easy to wrap external class/struct to > make them works with library. If we have a custom

Re: colour lib

On 31 August 2016 at 17:58, Andrea Fontana via Digitalmars-d wrote: > On Wednesday, 31 August 2016 at 06:17:15 UTC, Manu wrote: >> >> On 31 August 2016 at 16:01, Chris Wright via Digitalmars-d >> wrote: >>> >>> The color models I'm aware

Re: colour lib

On 31 August 2016 at 16:01, Chris Wright via Digitalmars-d wrote: > The color models I'm aware of are HSV, HSL, RGB[A], CMYK, Lab, Pantone, > and the Open Colour Standard. I'll initially support, XYZ/xyY, RGB (which is a gigantic set), HSx, Lab, Yuv. > I'm not sure

Re: colour lib

I have this implementation issue, which I'm having trouble applying good judgement, I'd like to survey opinions... So, RGB colours depend on this 'normalised integer' concept, that is: unsigned: luminance = val / IntType.max signed: luminance = max(val / IntType.max, -1.0) So I introduce

Re: colour lib

On 31 August 2016 at 15:01, rikki cattermole via Digitalmars-d wrote: > > 2. As part of your argument I personally would prefer that it is at least > tested in the context of an image library. We don't want any hidden problems > there even if that is not your goal to

colour lib

I'm blowing the dust off my colour proposal implementation. I want to get it into a state where it may be accepted into std.experimental, but I'm having trouble deciding on the scope of the initial offering. Some people are arguing for 'complete', and I tend to argue for minimal/un-contentious. It

Looking for work

Hey people, I left my job, looking for work... just thought I'd cast a net out there to see if there's any interesting job opportunities floating around in these parts? I've spent the last 6 years trying to make D a substantial part of my career by integrating it into my existing working

Re: Binderoo - we're open sourcing our binding system

On 16 August 2016 at 22:30, Ethan Watson via Digitalmars-d wrote: > https://github.com/Remedy-Entertainment/binderoo > > So I just announced at GDC Europe in my talk. We're open sourcing our > binding system. > > It's currently a complete reengingeering of the system,

Re: Things that make writing a clean binding system more difficult

On 5 August 2016 at 03:33, Seb via Digitalmars-d wrote: > On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote: >> >> On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d >> wrote: >>> >>> [...] >> >> >> Bingo! But it's much

Re: Things that make writing a clean binding system more difficult

On 29 July 2016 at 19:55, Walter Bright via Digitalmars-d wrote: > On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote: >> >> I've always looked at D's ref as being essentially the same as C++'s & >> except that it's not considered to be part of the type,

<    2   3   4   5   6   7   8   9   10   11   >