Re: Setting a list of values
On 04/30/2016 10:05 PM, Joel wrote:
> This has no effect:
> _bars.each!(a => { a._plots.fillColor = Color(255, 180, 0); });
This is a common issue especially for people who know lambdas from other
languages. :)
Your lambda does not do any work. Rather, your lambda returns another
lambda, which is promptly ignored:
import std.stdio;
import std.algorithm;
void main() {
auto arr = [ 1, 2 ];
arr.each!(a => { writeln(a); }); // returns lambda for each a
}
The lambda that 'each' takes above is "given a, produce this lambda". .
To do the intended work, you need to remove the curly braces (and the
semicolon):
arr.each!(a => writeln(a));
Or, you could insert empty () to call the returned lambda but that would
completely be extra work in this case:
arr.each!(a => { writeln(a); }());
Ali
Re: Can't use std.algorithm.remove on a char[]?
On Saturday, 30 April 2016 at 19:21:30 UTC, ag0aep6g wrote: On 30.04.2016 21:08, Jon D wrote: If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. Characters are not the problem. remove works fine on a range of chars, when the elements are assignable lvalues. char[] as a range has neither assignable elements, nor lvalue elements. That is, lines 3 and 4 here don't compile: import std.range: front; char[] a = ['f', 'o', 'o']; a.front = 'g'; auto ptr = Why exactly is it like this? I would understand why strings (immutable character arrays) behave like this, but I feel like plain old character arrays should work the same as an array of ubytes when treated as a range... Or is there some other string-related behavior that would get broken by this?
Using a string generated at compile-time in a @nogc function
Hi all, I'm working on removing the string mixins from my code, but have run into an issue: http://dpaste.dzfl.pl/ecd7eb53947e As far as I can tell, this should work; the enum should force compile-time execution (which it does, as evidenced by the pragma). I've worked around this by employing a string mixin, but it's not as clean: http://dpaste.dzfl.pl/021c4a849b32 Any insight would be appreciated :)
Setting a list of values
This has no effect:
_bars.each!(a => { a._plots.fillColor = Color(255, 180, 0); });
I tried putting ..each!((ref a) =>.. with no difference
This works:
foreach(b; _bars) {
b._plots.fillColor = Color(255, 180, 0);
}
Re: Rust piece on integer safety
On Saturday, 30 April 2016 at 23:11:20 UTC, Laeeth Isharc wrote: All the design/discussion/implementation of this scheme for handling integer overflow would be wasted if it didn’t actually find any bugs in practice. I personally have had quite a few bugs found nearly as I write them, with expressions like cmp::max(x - y, z) (they never hit the internet, so no links for them), especially when combined with testing infrastructure like quickcheck. The overflow checks have found bugs through out the ecosystem; for instance, (not exhaustive!) the standard library the compiler the built-in benchmark harness Servo image url webrender Beyond Rust, there’s a lot of evidence for the dangers of integer overflow and desire for detecting/protecting against them. It was on the CWE/SANS list of top 25 errors in 2011, languages like Swift will unconditionally check for overflow, and others like Python 3 and Haskell will avoid overflow entirely by default, via arbitrary precision integers. Furthermore, in C, several compilers have options to both make signed overflow defined as two’s complement wrapping (-fwrapv) and to catch it when it does happen (-fsanitize=signed-integer-overflow). http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/ I wonder if Rust uses the built-in "LLVM integer overflow checking". Recently this has been posted to r/programming: http://blog.regehr.org/archives/1384 Since LLVM is used as backend the Rust article might talk exactly about the same thing. (to be verified, actually I know nothing about Rust).
Rust piece on integer safety
All the design/discussion/implementation of this scheme for handling integer overflow would be wasted if it didn’t actually find any bugs in practice. I personally have had quite a few bugs found nearly as I write them, with expressions like cmp::max(x - y, z) (they never hit the internet, so no links for them), especially when combined with testing infrastructure like quickcheck. The overflow checks have found bugs through out the ecosystem; for instance, (not exhaustive!) the standard library the compiler the built-in benchmark harness Servo image url webrender Beyond Rust, there’s a lot of evidence for the dangers of integer overflow and desire for detecting/protecting against them. It was on the CWE/SANS list of top 25 errors in 2011, languages like Swift will unconditionally check for overflow, and others like Python 3 and Haskell will avoid overflow entirely by default, via arbitrary precision integers. Furthermore, in C, several compilers have options to both make signed overflow defined as two’s complement wrapping (-fwrapv) and to catch it when it does happen (-fsanitize=signed-integer-overflow). http://huonw.github.io/blog/2016/04/myths-and-legends-about-integer-overflow-in-rust/
Re: VariantPointer
On Wednesday, 20 April 2016 at 13:41:27 UTC, Nordlöw wrote: https://github.com/nordlow/phobos-next/blob/master/src/variant_pointer.d Moved here: https://github.com/nordlow/phobos-next/blob/master/src/variant_ex.d
Re: Can't use std.algorithm.remove on a char[]?
On 30.04.2016 21:41, Jon D wrote: I didn't mean to suggest making the documentation technically incorrect. Just that it be helpful in important cases that won't necessarily be obvious. To me, char[] is an important case, one that's not made obvious by listing the hasLvalueElements constraint by itself. Sure. I wouldn't object to having a little reminder there that char[] does not meet the requirements.
Re: Can't use std.algorithm.remove on a char[]?
On Saturday, 30 April 2016 at 19:21:30 UTC, ag0aep6g wrote: On 30.04.2016 21:08, Jon D wrote: If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. Characters are not the problem. remove works fine on a range of chars, when the elements are assignable lvalues. char[] as a range has neither assignable elements, nor lvalue elements. That is, lines 3 and 4 here don't compile: import std.range: front; char[] a = ['f', 'o', 'o']; a.front = 'g'; auto ptr = I didn't mean to suggest making the documentation technically incorrect. Just that it be helpful in important cases that won't necessarily be obvious. To me, char[] is an important case, one that's not made obvious by listing the hasLvalueElements constraint by itself. --Jon
Re: Can't use std.algorithm.remove on a char[]?
On 30.04.2016 21:08, Jon D wrote: If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. Characters are not the problem. remove works fine on a range of chars, when the elements are assignable lvalues. char[] as a range has neither assignable elements, nor lvalue elements. That is, lines 3 and 4 here don't compile: import std.range: front; char[] a = ['f', 'o', 'o']; a.front = 'g'; auto ptr =
Re: Can't use std.algorithm.remove on a char[]?
On Saturday, 30 April 2016 at 18:32:32 UTC, ag0aep6g wrote: On 30.04.2016 18:44, TheGag96 wrote: I was just writing some code trying to remove a value from a character array, but the compiler complained "No overload matches for remove", and if I specifically say use std.algorithm.remove() the compiler doesn't think it fits any definition. For reference, this would be all I'm doing: char[] thing = ['a', 'b', 'c']; thing = thing.remove(1); Is this a bug? std.algorithm claims remove() works on any forward range... The documentation is wrong. 1) remove requires a bidirectional range. The constraints and parameter documentation correctly say so. char[] is a bidirectional range, though. 2) remove requires lvalue elements. char[] fails this, as the range primitives decode the chars on-the-fly to dchars. Pull request to fix the documentation: https://github.com/dlang/phobos/pull/4271 By the way, I think requiring lvalues is too restrictive. It should work with assignable elements. Also, it has apparently been missed that const/immutable can make non-assignable lvalues. There's a ticket open related to the lvalue element requirement: https://issues.dlang.org/show_bug.cgi?id=8930 Personally, I think this example is more compelling than the one in the ticket. It seems very reasonable to expect that std.algorithm.remove will work regardless of whether the elements are characters, integers, ubytes, etc. If an initial step is to fix the documentation, it would be helpful to include specifically that it doesn't work with characters. It's not obvious that characters don't meet the requirement. --Jon
Re: Can't use std.algorithm.remove on a char[]?
On 30.04.2016 18:44, TheGag96 wrote: I was just writing some code trying to remove a value from a character array, but the compiler complained "No overload matches for remove", and if I specifically say use std.algorithm.remove() the compiler doesn't think it fits any definition. For reference, this would be all I'm doing: char[] thing = ['a', 'b', 'c']; thing = thing.remove(1); Is this a bug? std.algorithm claims remove() works on any forward range... The documentation is wrong. 1) remove requires a bidirectional range. The constraints and parameter documentation correctly say so. char[] is a bidirectional range, though. 2) remove requires lvalue elements. char[] fails this, as the range primitives decode the chars on-the-fly to dchars. Pull request to fix the documentation: https://github.com/dlang/phobos/pull/4271 By the way, I think requiring lvalues is too restrictive. It should work with assignable elements. Also, it has apparently been missed that const/immutable can make non-assignable lvalues. You can use std.utf.byCodeUnit to get a char range over an char[], but using it here is a bit awkward, because there's no (documented) way to get the array back from a byCodeUnit range: char[] thing = ['a', 'b', 'c']; thing = thing[0 .. thing.byCodeUnit.remove(1).length]; You could also use ubyte[] instead of char[]: ubyte[] thing = ['a', 'b', 'c']; thing = thing.remove(1);
Can't use std.algorithm.remove on a char[]?
I was just writing some code trying to remove a value from a character array, but the compiler complained "No overload matches for remove", and if I specifically say use std.algorithm.remove() the compiler doesn't think it fits any definition. For reference, this would be all I'm doing: char[] thing = ['a', 'b', 'c']; thing = thing.remove(1); Is this a bug? std.algorithm claims remove() works on any forward range...
Re: Garbage Collector : Ignoring a reference
On Tuesday, 26 April 2016 at 09:07:59 UTC, Begah wrote:
I am trying to create an asset manager for my textures. I had
the idea ( it may be a wrong idea ) to create a hashmap of my
textures with a string as the key. When the program request a
texture, it firts check if it is in the hashmap and then
returns if it is :
Texture[string] textures;
Texture loadTexture(string filename) {
if(filename in textures)
return textures[filename]
else
// Load image and put it in hashmap
}
Warning : I haven't tested if it actually doesn't work, but
thinking about it, i think it should not.
My problem is that i return a reference of the texture to the
program, but i keep one to myself and i want to free the
texture if my program isn't using it anymore ( no more
reference to it ). The problem i see, is that i will always
have atleast one reference to the texture in my hashmap, but i
want the garbage collector to ignore that reference and to free
the texture if there are no more references anywhere in my
program ( except in the hashmap ).
How could i tell the garbage collector to ignore the reference
in the hashmap and to free it if there isn't any other
reference that in my hashmap?
You should avoid to rely on the garbage collector to free
non-memory resources anyway. This is accidental correctness. You
are not guaranteed to get called by the GC, or by the appropriate
thread.
You can call .destroy() on these textures when in the texture
manager destructor.
Linking to library dependent on Objective-C functions
I have two files. The one has Objective-C functions and interfaces declarations written in D. Another file is main app and it imports the first and uses its functions. Imported file: http://codepad.org/jqdBb6sh Main file: http://codepad.org/0gKBqKxi When I compile them in one command it run without problems. dmd main.d domaindir.d -L-framework -LFoundation But I want domaindir.d to be static library and link main.d against this library. So I do: dmd -lib domaindir.d dmd main.d -I. -L-framework -LFoundation domaindir.a The second command prints warning: ld: warning: can't parse __DATA/__objc_imageinfo section in domaindir.a(domaindir_5_397.o) When I try to run ./main it fails: 2016-04-30 13:05:55.733 main[15762:685588] *** NSForwarding: warning: selector (0x1040f5e58) for message 'defaultManager' does not match selector known to Objective C runtime (0x7fff8aeed3af)-- abort 2016-04-30 13:05:55.734 main[15762:685588] +[NSFileManager defaultManager]: unrecognized selector sent to class 0x7fff7baaad28 2016-04-30 13:05:55.736 main[15762:685588] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSFileManager defaultManager]: unrecognized selector sent to class 0x7fff7baaad28' *** First throw call stack: ( 0 CoreFoundation 0x7fff95fab03c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x7fff99ac176e objc_exception_throw + 43 2 CoreFoundation 0x7fff95fadfad +[NSObject(NSObject) doesNotRecognizeSelector:] + 205 3 CoreFoundation 0x7fff95ef3e24 ___forwarding___ + 1028 4 CoreFoundation 0x7fff95ef3998 _CF_forwarding_prep_0 + 120 5 main0x0001040baf58 D9domaindir9domainDirFNemmbZAya + 56 6 main0x0001040ba9cb _Dmain + 283 7 main0x0001040d515c D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 40 8 main0x0001040d5090 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 36 9 main0x0001040d5101 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 45 10 main0x0001040d5090 D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 36 11 main0x0001040d4ff6 _d_run_main + 498 12 main0x0001040baa80 main + 16 13 libdyld.dylib 0x7fff92ee25c9 start + 1 14 ??? 0x0001 0x0 + 1 ) libc++abi.dylib: terminating with uncaught exception of type NSException Abort trap: 6 Using dmd v2.071.0 on OS X 10.10.5
Re: Garbage Collector : Ignoring a reference
On Tuesday, 26 April 2016 at 09:07:59 UTC, Begah wrote:
I am trying to create an asset manager for my textures. I had
the idea ( it may be a wrong idea ) to create a hashmap of my
textures with a string as the key. When the program request a
texture, it firts check if it is in the hashmap and then
returns if it is :
Texture[string] textures;
Texture loadTexture(string filename) {
if(filename in textures)
return textures[filename]
else
// Load image and put it in hashmap
}
Warning : I haven't tested if it actually doesn't work, but
thinking about it, i think it should not.
My problem is that i return a reference of the texture to the
program, but i keep one to myself and i want to free the
texture if my program isn't using it anymore ( no more
reference to it ). The problem i see, is that i will always
have atleast one reference to the texture in my hashmap, but i
want the garbage collector to ignore that reference and to free
the texture if there are no more references anywhere in my
program ( except in the hashmap ).
How could i tell the garbage collector to ignore the reference
in the hashmap and to free it if there isn't any other
reference that in my hashmap?
Texture[string] textures;
Texture* loadTexture(string filename) {
if(filename in textures)
return [filename]
else
// Load image and put it in hashmap
}
Texture* tex = loadTexture(...);
