Re: string encryption

On 07/02/2016 12:23 AM, Hiemlick Hiemlicker wrote: This also seems like a bug in D because manifest constants used as sole arguments to ctfe'able functions should be replaced by the function result. No. There are functions that don't have any dynamic input, but still take a long time to

Re: string encryption

On Saturday, 2 July 2016 at 01:31:17 UTC, Hiemlick Hiemlicker wrote: But you are declaring string 1 and string 2 an enum. If you declare them as a string then the original is embedded in the binary! I don't know why that would change anything but it does. The reason it matter is because

Re: static __gshared struct

On Saturday, 2 July 2016 at 00:08:10 UTC, Hiemlick Hiemlicker wrote: I use a struct with static members so I do not have to instantiate it. It is essentially a singleton. I want all the variables to be __gshared. I guess I have to prefix all variables with it? Basically I have Foo.i; on

Re: static __gshared struct

On Saturday, 2 July 2016 at 00:08:10 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:36:35 UTC, Basile B. wrote: On Friday, 1 July 2016 at 23:26:19 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:03:17 UTC, Basile B. wrote: [...] Ok, Does that mean [...]

Re: daffodil, a D image processing library

On Friday, 1 July 2016 at 23:37:59 UTC, Leandro Lucarella wrote: On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: Alongside I've also written (an admittedly hacky) sphinx (http://www.sphinx-doc.org/en/stable/) extension that provides a domain and autodocumenter for D, using

Re: string encryption

On Saturday, 2 July 2016 at 01:31:17 UTC, Hiemlick Hiemlicker wrote: On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote: On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote: On Friday, 1 July 2016 at 23:23:19

Re: Thunking problems with arch issues

Couple of things could be happening. 1) Alignments are off, aligning of data really really matters when dealing with executable code. 2) For Windows only. Don't forget to call FlushInstructionCache. Before executing.

Re: string encryption

On Saturday, 2 July 2016 at 00:29:45 UTC, Adam D. Ruppe wrote: On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: Is there a way to write a wrapper around such that mystring s = "a string that will be converted and not appear in binary"; writeln(s); You just need to put a

Re: Does D has any support for thunks?

On Saturday, 25 June 2016 at 17:52:48 UTC, Andre Pany wrote: On Saturday, 25 June 2016 at 17:26:03 UTC, Andre Pany wrote: On Saturday, 25 June 2016 at 16:05:30 UTC, Vladimir Panteleev wrote: On Saturday, 25 June 2016 at 13:44:48 UTC, Andre Pany wrote: Does D/Phobos has any support for thunks?

Thunking problems with arch issues

The following code works on dmd x64. Fails on dmd x32 and ldc x64. The problem is the passed variable. import std.stdio; version (Windows) { import core.sys.windows.windows; void makeExecutable(ubyte[] code) { DWORD old; VirtualProtect(code.ptr, code.length,

Re: string encryption

On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote: On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote: On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: I've tried playing with opCall,

Re: -dip25 switch: time to make it always on?

On Wednesday, June 29, 2016 02:40:45 Walter Bright via Digitalmars-d wrote: > It was added for 2.067 back in March of 2015: > > https://dlang.org/changelog/2.067.0.html > > It's been a strong success. Time to make it the default instead of enabled > by a switch? Well, I don't know how you can

Bug in D type inferencing

public struct Foo { public void Create(T)(uint delegate(T) c, T param) { } } Foo f; f.Create((x) { }, "asdf"); cannot deduce arguments compiler error. Surely D can figure out that T is a string? If one simply changes this to public struct Foo(T) {

[Issue 16226] -dip25 doesn't work if the return type is not explicit

https://issues.dlang.org/show_bug.cgi?id=16226 Jonathan M Davis changed: What|Removed |Added Keywords||safe --

[Issue 16226] New: -dip25 doesn't work if the return type is not explicit

https://issues.dlang.org/show_bug.cgi?id=16226 Issue ID: 16226 Summary: -dip25 doesn't work if the return type is not explicit Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: string encryption

On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote: The syntax is not so bad. enum KryptedString string1 = "blablabla"; is impossible or maybe I don't know the trick yet. That's a constructor on KryptedString that takes a string.

Re: Do you want support for CTFE coverage ?

On Saturday, 2 July 2016 at 00:38:56 UTC, Stefan Koch wrote: On Saturday, 2 July 2016 at 00:34:05 UTC, Walter Bright wrote: On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and

Re: Do you want support for CTFE coverage ?

On Saturday, 2 July 2016 at 00:34:05 UTC, Walter Bright wrote: On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and coverage tested that way. Fair enough :) execpt for code

Re: string encryption

On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote: On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: I've tried playing with opCall, opAssign, alias this, @property but writeln(s) never calls what

Re: Do you want support for CTFE coverage ?

On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and coverage tested that way.

Re: string encryption

On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: Is there a way to write a wrapper around such that mystring s = "a string that will be converted and not appear in binary"; writeln(s); You just need to put a `string toString() { return whatever; }` function on

Re: Do you want support for CTFE coverage ?

there is no need in that, absolutely. CTFE is undebugabble anyway (and pragma(msg) not really helps -- i'm saying that as a fan of printf debugger), unittesting it is silly and so on. after all, as CTFE *should* behave the same if it is done in runtime, one can always test and debug CTFE code

Re: string encryption

On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote: On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: ok. For some reason I thought CTFE's applied to normal functions but I realize that doesn't make a lot of sense. It is applied to normal functions, just when they

Re: static __gshared struct

On Friday, 1 July 2016 at 23:36:35 UTC, Basile B. wrote: On Friday, 1 July 2016 at 23:26:19 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:03:17 UTC, Basile B. wrote: On Friday, 1 July 2016 at 22:47:21 UTC, Hiemlick Hiemlicker wrote: Ok, Does that mean void main() {

Re: string encryption

On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: This also seems like a bug in D because manifest constants used as sole arguments to ctfe'able functions should be replaced by the function result. I wouldn't call it a bug, but it could be seen as an enhancement request, in

Re: string encryption

On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: ok. For some reason I thought CTFE's applied to normal functions but I realize that doesn't make a lot of sense. It is applied to normal functions, just when they are used in the right context. int a = factorial(3); //

[Issue 16142] Adding a dtor / postblit (even disabled) forces opAssign

https://issues.dlang.org/show_bug.cgi?id=16142 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/517f14a949a2998e51517cbef444f2b3208a3789 Fix issue 16142: Disabled opEquals is overriden when a

Re: daffodil, a D image processing library

On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: Alongside I've also written (an admittedly hacky) sphinx (http://www.sphinx-doc.org/en/stable/) extension that provides a domain and autodocumenter for D, using libdparse and pyd. Where can I get the Sphinx extension? :-D

Re: static __gshared struct

On Friday, 1 July 2016 at 23:26:19 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:03:17 UTC, Basile B. wrote: On Friday, 1 July 2016 at 22:47:21 UTC, Hiemlick Hiemlicker wrote: Ok, Does that mean void main() { static struct Foo{} foo(); } void foo() { Foo f; }

Re: static __gshared struct

On Friday, 1 July 2016 at 23:03:17 UTC, Basile B. wrote: On Friday, 1 July 2016 at 22:47:21 UTC, Hiemlick Hiemlicker wrote: what exactly does this do? are all members _gshared? In this case __gshared is a complete NOOP. __gshared has only an effect on variables. It prevents them to reside in

Re: string encryption

On Friday, 1 July 2016 at 22:56:48 UTC, Basile B. wrote: On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: I know this is probably a lot to ask for an many won't see the point, but a secure program should not expose readable strings, it makes it far too easy for the attacker

Re: string encryption

On Friday, 1 July 2016 at 22:55:21 UTC, qznc wrote: On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: It seems D won't replace encrypt("This string will still end up in the binary"); with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or whatever the ctfe value of

Re: static __gshared struct

On Friday, 1 July 2016 at 22:47:21 UTC, Hiemlick Hiemlicker wrote: what exactly does this do? are all members _gshared? In this case __gshared is a complete NOOP. __gshared has only an effect on variables. It prevents them to reside in the TLS, so that they can be used by any thread of the

Re: string encryption

On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: I know this is probably a lot to ask for an many won't see the point, but a secure program should not expose readable strings, it makes it far too easy for the attacker to see what is going on. Is it possible to encrypt every

Re: string encryption

On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: It seems D won't replace encrypt("This string will still end up in the binary"); with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or whatever the ctfe value of encrypt actually is. This also seems like a bug in D

static __gshared struct

what exactly does this do? are all members _gshared?

string encryption

I know this is probably a lot to ask for an many won't see the point, but a secure program should not expose readable strings, it makes it far too easy for the attacker to see what is going on. Is it possible to encrypt every static string in D and decrypt before it is output in an automatic

Re: Get program stats at run time

On Thursday, 30 June 2016 at 21:56:57 UTC, Special opOps wrote: How can I get the program stats at run time such as minimum and maximum amount of memory and cpu used, cpu architecture, os, etc? OS is compile-time constant. http://dlang.org/phobos/std_system.html#.os Or do you look for

Re: daffodil, a D image processing library

On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote: When loading images, bit depth should be determined in the runtime, depending on the image you'd be loading at the moment. Or am I wrong? Generally most use cases for using an image library can be divided into: 1. You have

Re: Has someone encountered similar issues with -cov?

On 7/1/16 4:08 PM, Andrei Alexandrescu wrote: On 7/1/16 2:46 PM, Steven Schveighoffer wrote: On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 --

Do you want support for CTFE coverage ?

Hi, Exactly as per title. Do you want to see coverage for code executed at CTFE ? I ask because it is slightly tricky to support this and it needs to be factored in early in design. And please off-topic or thread hijacking this time. Thanks!

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 19:43:05 UTC, Patrick Schluter wrote: It looks like a loop, but isn't one. It doesn't look like a goto, but is one. Yes, it looks buggy, and the -cov did the right thing by marking it as uncovered as this could be a serious and difficult to find bug. I wonder why

Re: Has someone encountered similar issues with -cov?

On 7/1/16 3:43 PM, Patrick Schluter wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei That do { } while(0) construct is ridiculous. It's cargo cult at its worst. That escalated quickly. -- Andrei

Re: Has someone encountered similar issues with -cov?

On 7/1/16 2:46 PM, Steven Schveighoffer wrote: On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as

Re: Has someone encountered similar issues with -cov?

On 7/1/16 2:27 PM, Chris wrote: On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote: Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage).

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei That do { } while(0) construct is ridiculous. It's cargo cult at its worst. It is NOT more readable than an honest to god goto. It's an obfuscated way to

Re: Logical location of template instantiations

On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer wrote: On 7/1/16 3:02 PM, Timon Gehr wrote: The current module (that declares 'S') might not be the only module that uses emplace to construct 'S' instances. We want to hide the constructor of 'S' from other modules, but not from

Re: Logical location of template instantiations

On 7/1/16 3:02 PM, Timon Gehr wrote: The current module (that declares 'S') might not be the only module that uses emplace to construct 'S' instances. We want to hide the constructor of 'S' from other modules, but not from the current module. But both modules get identical template instances,

Re: Logical location of template instantiations

On 27.06.2016 18:25, Lodovico Giaretta wrote: import std.conv, core.memory; struct S { int x; private this(int val) { x = val; } } void main() { auto ptr = cast(S*)GC.malloc(S.sizeof); auto s = ptr.emplace(3); } This code does not work, as the call

Re: Logical location of template instantiations

On 01/07/16 16:14, Steven Schveighoffer wrote: Right, but this puts allocators at a lower footing than the GC which has no problem with private ctors. I would have expected to be able to build using allocators and private ctors. It's possible to bypass protection using pointers. -- /Jacob

Re: Has someone encountered similar issues with -cov?

On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the

[Issue 16225] [REG 2.068] Internal error cod1.c 1338 with -O

https://issues.dlang.org/show_bug.cgi?id=16225 Steven Schveighoffer changed: What|Removed |Added CC|

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote: Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Not sure if it's

Re: Has someone encountered similar issues with -cov?

On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do`

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 --- Comment #7 from Andrei Alexandrescu --- (In reply to Johan Engelen from comment #6) > > The coverage analyzer marks the line with "while (0);" as uncovered, > > although that is an useless tidbit. > > I don't think it is

[Issue 16225] Internal error cod1.c 1338 with -O

https://issues.dlang.org/show_bug.cgi?id=16225 --- Comment #1 from Nemanja Boric <4bur...@gmail.com> --- Looks like it got introduced in 2.068 --

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 --- Comment #6 from Johan Engelen --- > The coverage analyzer marks the line with "while (0);" as uncovered, > although that is an useless tidbit. I don't think it is useless. In the OP example, while(0) is uncovered

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 --- Comment #5 from Andrei Alexandrescu --- (In reply to Steven Schveighoffer from comment #4) > I don't see why while(true) is any worse. > > Essentially: > > while(true) > { > ... > break; > } > > Is the same as the

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in

[Issue 16225] Internal error cod1.c 1338 with -O

https://issues.dlang.org/show_bug.cgi?id=16225 Steven Schveighoffer changed: What|Removed |Added Keywords|

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 Steven Schveighoffer changed: What|Removed |Added CC|

[Issue 16225] Internal error cod1.c 1338 with -O

https://issues.dlang.org/show_bug.cgi?id=16225 Dicebot changed: What|Removed |Added CC||pub...@dicebot.lv

[Issue 16225] New: Internal error cod1.c 1338 with -O

https://issues.dlang.org/show_bug.cgi?id=16225 Issue ID: 16225 Summary: Internal error cod1.c 1338 with -O Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement

Re: Logical location of template instantiations

On Monday, 27 June 2016 at 16:25:27 UTC, Lodovico Giaretta wrote: [...] This is not the first time I run into this limitation (not only with functions, but also with structs), so I wonder: wouldn't it be worth a way to get this behaviour? Yes it would be worth. Several ppl have already hit

Re: Logical location of template instantiations

On Friday, 1 July 2016 at 14:14:00 UTC, Steven Schveighoffer wrote: On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: I wonder what the plans are for std.allocator on this, as I would think it would run into the same issues. Andrei?

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 --- Comment #3 from Andrei Alexandrescu --- For clarity, I'll paste the code (fixed to do something useful, i.e. compute the cube of an int) and the listing: int cube(int x) { do { if (x == 0) break;

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I've reported this one a while back: https://issues.dlang.org/show_bug.cgi?id=15590 if (__ctfe) branches are a problem because they really prevent to reach 100%

Re: Casting classes

On Friday, 1 July 2016 at 17:34:25 UTC, Basile B. wrote: On Friday, 1 July 2016 at 17:32:26 UTC, Basile B. wrote: On Friday, 1 July 2016 at 15:45:35 UTC, Jonathan Marler wrote: How do casts work under the hood? I'm mostly interested in what needs to be done in order to cast a class to a

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 --- Comment #2 from hst...@quickfur.ath.cx --- Nevermind, I get it now. Sorry for the noise. --

Re: Casting classes

On Friday, 1 July 2016 at 17:32:26 UTC, Basile B. wrote: On Friday, 1 July 2016 at 15:45:35 UTC, Jonathan Marler wrote: How do casts work under the hood? I'm mostly interested in what needs to be done in order to cast a class to a subclass. I'd like to know what is being done to determine

Re: Casting classes

On Friday, 1 July 2016 at 15:45:35 UTC, Jonathan Marler wrote: How do casts work under the hood? I'm mostly interested in what needs to be done in order to cast a class to a subclass. I'd like to know what is being done to determine whether the object is a valid instance of the cast type.

[Issue 16224] -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment

Re: Has someone encountered similar issues with -cov?

On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei Yeah: https://issues.dlang.org/buglist.cgi?quicksearch=coverage_id=209269

Has someone encountered similar issues with -cov?

https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei

[Issue 16224] New: -cov marks the last line of do/while(0); as uncovered

https://issues.dlang.org/show_bug.cgi?id=16224 Issue ID: 16224 Summary: -cov marks the last line of do/while(0); as uncovered Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement

Re: daffodil, a D image processing library

On Friday, 1 July 2016 at 14:30:17 UTC, Benjamin Schaaf wrote: The problem with not knowing bit depth at compile time, is that you're now forced to store the image internally as plain bytes. So if you wanted to add two colors, you end up with ubyte[4] + ubyte[4] instead of int + int. At some

[Issue 15193] DIP25 (implementation): Lifetimes of temporaries tracked incorrectly

https://issues.dlang.org/show_bug.cgi?id=15193 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/f2c50d0ba2fdff00bc58fa6be732e405f2ddf600 fix Issue 15193 - DIP25 (implementation): Lifetimes of

[Issue 15193] DIP25 (implementation): Lifetimes of temporaries tracked incorrectly

https://issues.dlang.org/show_bug.cgi?id=15193 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

Casting classes

How do casts work under the hood? I'm mostly interested in what needs to be done in order to cast a class to a subclass. I'd like to know what is being done to determine whether the object is a valid instance of the cast type. If the code is implemented in the druntime, a pointer to where

Re: Associative array of const items

On Friday, 1 July 2016 at 06:57:59 UTC, QAston wrote: On Thursday, 30 June 2016 at 17:08:45 UTC, Jonathan Marler wrote: Is there a way to have an associative array of const values? I thought it would have been: const(T)[K] map; map[x] = y; but the second line gives Error: cannot modify const

Re: Get current date and time with std.datetime

On Thursday, 30 June 2016 at 21:18:22 UTC, Luke Picardo wrote: Why is it so hard to simply get the current date and time formatted properly in a string? There are no examples of this in your documentation yet this is probably one of the most used cases. To get the current time, use

Re: daffodil, a D image processing library

On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote: On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: [...] Hi there. Took a quick look at the source and it seems really nice! I like your idea of extensibility for color conversion. Also, image I/O seems to be

Re: daffodil, a D image processing library

On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote: On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: daffodil is a image processing library inspired by python's Pillow (https://pillow.readthedocs.org/). It is an attempt at designing a clean, extensible and

Re: Logical location of template instantiations

On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: I wonder what the plans are for std.allocator on this, as I would think it would run into the same issues. Andrei? emplace only works with accessible constructors. I understand sometimes it's

Re: Ocean preview finally open sourced

On 01/07/16 12:31, Leandro Lucarella wrote: We know that, and again, the license was by far the biggest nightmare of the open sourcing effort. Honestly we don't have the time to take on this, but this is an area where external contributions would be extremely helpful. Anyone can contact the

Re: Logical location of template instantiations

On 01/07/16 15:46, Andrei Alexandrescu wrote: emplace only works with accessible constructors. I understand sometimes it's reasonable to ask for more flexibility, but there are limitations. It's possible to bypass the protection using a pointer. An alternative would be to not invoke the

Re: Another audio plugin in D

On 01/07/16 08:07, bitwise wrote: Sorry I haven't had much time to work on this lately. I'm not sure how soon I will have time. If anyone else wanted to champion this effort, we could discuss passing the torch and trying to make use of the work I've done thus far. I still plan to do it at some

Re: Logical location of template instantiations

On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: On 6/27/16 12:25 PM, Lodovico Giaretta wrote: import std.conv, core.memory; struct S { int x; private this(int val) { x = val; } } void main() { auto ptr = cast(S*)GC.malloc(S.sizeof); auto s = ptr.emplace(3);

Re: Logical location of template instantiations

On 01/07/16 11:57, Lodovico Giaretta wrote: Ping... Maybe I'm just saying bullshit, but... Am I really the only one who faced this need? You're not the only one, it's been brought up before. A solution/workaround is that "emplace" invokes the constructor using a function pointer, what will

Re: Call to Action: making Phobos @safe

On Thursday, 30 June 2016 at 21:55:33 UTC, Seb wrote: On Thursday, 30 June 2016 at 21:31:25 UTC, Walter Bright wrote: On 6/30/2016 11:54 AM, Bennet Leff wrote: On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek wrote: [...] Could you elaborate on list option 9 "create a module

Re: Logical location of template instantiations

On 6/27/16 12:25 PM, Lodovico Giaretta wrote: import std.conv, core.memory; struct S { int x; private this(int val) { x = val; } } void main() { auto ptr = cast(S*)GC.malloc(S.sizeof); auto s = ptr.emplace(3); } This code does not work, as the call

Re: post 2.071 mixin template & import rules

On 7/1/16 1:42 AM, captaindet wrote: apparently starting with 2.071 import declarations are not treated as declarations in the sense of mixin templates anymore. meaning that whole module imports (private and public) in mixin template definitions are not inserted into the instantiating scope

Re: Ocean preview finally open sourced

On Friday, 1 July 2016 at 10:31:59 UTC, Leandro Lucarella wrote: Oh, well. Sorting out the license(s) were one of the major pains and time consuming tasks we had to do to opensource this, and apparently despite our best efforts there are stuff that we didn't see. *nods* I was only looking at

Re: daffodil, a D image processing library

On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote: daffodil is a image processing library inspired by python's Pillow (https://pillow.readthedocs.org/). It is an attempt at designing a clean, extensible and transparent API. Nice. Minor nitpick, please make the width and

Re: Logical location of template instantiations

On Friday, 1 July 2016 at 12:08:49 UTC, Lodovico Giaretta wrote: On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully

Re: Logical location of template instantiations

On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully bypassed my issues with this thing, but I wanted to share my

Re: Range non-emptyness assertions and opIndex

On Friday, 1 July 2016 at 11:35:40 UTC, ag0aep6g wrote: Huh? Asserts are ignored with -release. The only exception is assert(false) which terminates the program immediately, even with -release. Aha, that's what I was testing against so therefore the confusion.

Re: Logical location of template instantiations

IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-)

Re: Range non-emptyness assertions and opIndex

On Friday, 1 July 2016 at 10:35:04 UTC, Nordlöw wrote: I think this is a important issue since asserts are not optimized away in release mode and D is very much about performance. Asserts are removed in release mode, enforce isn't. Here's an example: = void main(string[] args) {

Re: Range non-emptyness assertions and opIndex

On 07/01/2016 12:35 PM, Nordlöw wrote: What's the preferred way of reacting to emptyness in the members front, back, popFront, popBack --- using assert, enforce, throw, or simply relying on range-checking in the _store? I think assert is the most common way of checking. Simply ignoring the

  1   2   >