Re: OpenCL bindings
On Tuesday, 19 March 2013 at 15:03:11 UTC, Lemonfiend wrote: I see. That's a larger project than I'd hoped. Considering I've never created a binding before, is there some kind of tutorial/recommended reading available? There's a page at dlang.org[1], and I have a series of 5 blog posts on the topic over at gamedev.net, starting with part 1[2]. [1] http://dlang.org/interfaceToC.html [2] http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Re: OpenCL bindings
On Wednesday, 20 March 2013 at 08:13:45 UTC, Mike Parker wrote: On Tuesday, 19 March 2013 at 15:03:11 UTC, Lemonfiend wrote: I see. That's a larger project than I'd hoped. Considering I've never created a binding before, is there some kind of tutorial/recommended reading available? There's a page at dlang.org[1], and I have a series of 5 blog posts on the topic over at gamedev.net, starting with part 1[2]. [1] http://dlang.org/interfaceToC.html [2] http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/ You're missing dstep. Using dstep I converted some c-libraries in short time. It's quite easy to use and usually just some minor modification are needed to adjust auto-generated d interface.
Re: recursive equal, and firstDifference functions
On Wednesday, 20 March 2013 at 03:10:41 UTC, Jonathan M Davis wrote: The way == is defined is very clean and straightforward. There _are_ bugs which complicate things (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=3789 ), but those can and will be fixed. The design itself is solid. Thanks for the detailed explanation. If 3789 covers strings, dynamic arrays and associative arrays and it were fixed then I agree, it is clean and straightforward. If I read it correctly with this fix it would change the current opEquals from semantically shallow to semantically deep by default. Semantically deep equality is comfortable to me, but I would imagine by now there is a fair amount of code that might rely on a false result from opEquals if the members (slices, associative arrays) are not bitwise the same. Thanks Dan
Re: OpenCL bindings
On 2013-03-20 12:09, Andrea Fontana wrote: You're missing dstep. Using dstep I converted some c-libraries in short time. It's quite easy to use and usually just some minor modification are needed to adjust auto-generated d interface. I was just about to suggest to use dstep. I'm glad to see that you found it useful. -- /Jacob Carlborg
Re: OpenCL bindings
On Wednesday, 20 March 2013 at 12:43:13 UTC, Jacob Carlborg wrote: On 2013-03-20 12:09, Andrea Fontana wrote: You're missing dstep. Using dstep I converted some c-libraries in short time. It's quite easy to use and usually just some minor modification are needed to adjust auto-generated d interface. I was just about to suggest to use dstep. I'm glad to see that you found it useful. Can dstep output function declarations as aliased function pointers in the format I use in Derelict?
Re: OpenCL bindings
On Wednesday, 20 March 2013 at 12:43:13 UTC, Jacob Carlborg wrote: On 2013-03-20 12:09, Andrea Fontana wrote: You're missing dstep. Using dstep I converted some c-libraries in short time. It's quite easy to use and usually just some minor modification are needed to adjust auto-generated d interface. I was just about to suggest to use dstep. I'm glad to see that you found it useful. *Very* useful. I hope it will be updated with some small changes (like anonymous struct alias replacement and d keyword replacement) :)
looking for V[string] workarounds
Can the following be made to build and run, but keep the intent of what is shown. I realize it touches on several bugs related to const, postblit, and map - but I'm having trouble finding the magic combination. The idea is simply have assets store multiple series of data in a map indexed by the asset name. Thanks, Dan import std.stdio; struct Series { // REQUIRED - need to have no aliasing this(this) { data = data.dup; } private double[] data; } struct Assets { this(this) { itemToSeries.dup; } // REQUIRED - want ctor to dup arg to ensure no aliasing this(const(Series[string]) source) { itemToSeries = source.dup; } private Series[string] itemToSeries; } void main() { auto data = [ "house" : Series([1,2,3.0])]; auto assets = Assets(data); writeln(assets); }
Re: SocketStream and weird 0xA character
On Sun, 17 Feb 2013 16:53:23 -, Lubos Pintes wrote: I am writing little program which downloads simple data file from server through HTTP. The file is static, but updated regularly, so I am using "Range: bytes" header to optimize the traffic a bit. After I analyzed HTTP status line and headers, I started to read the raw data through SocketStream.read(buffer). There seems to be one single '\n' character in buffer[0] after first read. I cannot figure out why this character is appearing. It is not there when I download that file through wget. Here is relevant part of code: //Parse status line + headers string[string] header; auto line=ss.readLine(); auto statusLine=line.split(" "); auto responseCode=to!int(statusLine[1]); while(true) { line=ss.readLine(); if(!line.length) break; auto h=line.split(":"); header[h[0].idup]=h[1].strip.idup; } int contentLength=to!uint(header["Content-Length"]); if(responseCode==416 && contentLength==fileSize) return; //nothing to download if(responseCode==200 || responseCode==216) { ubyte[] buffer=new ubyte[4096]; auto first=true; while(contentLength>0) { auto bytesRead=ss.read(buffer); if(first) {writeln(buffer[0..20]); first=false; } f.rawWrite(buffer[0..bytesRead]); contentLength-=bytesRead; } } IIRC there is a blank line after headers in the HTTP protocol, that's how you know you're at the end of the headers i.e. [] R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: looking for V[string] workarounds
On 03/20/2013 07:34 AM, Dan wrote: Can the following be made to build and run, but keep the intent of what is shown. I realize it touches on several bugs related to const, postblit, and map - but I'm having trouble finding the magic combination. The idea is simply have assets store multiple series of data in a map indexed by the asset name. Thanks, Dan import std.stdio; struct Series { // REQUIRED - need to have no aliasing this(this) { data = data.dup; } private double[] data; } struct Assets { this(this) { itemToSeries.dup; } // REQUIRED - want ctor to dup arg to ensure no aliasing this(const(Series[string]) source) { The code compiles with 2.062 and an earlier version of 2.063 if you accept letting go of const-correctness there: this(Series[string] source) { itemToSeries = source.dup; } private Series[string] itemToSeries; } void main() { auto data = [ "house" : Series([1,2,3.0])]; auto assets = Assets(data); writeln(assets); } Ali
Re: looking for V[string] workarounds
On Wednesday, 20 March 2013 at 17:11:02 UTC, Ali Çehreli wrote: The code compiles with 2.062 and an earlier version of 2.063 if you accept letting go of const-correctness there: this(Series[string] source) { Thanks Ali. But, removing const there then requires non-const instances to be passed in, due to const transitivity. So that requirement would ripple a change to all already const correct instances to now need to flip to non-const. I'm looking for a const correct solution. It should be doable ... I just have had no luck with it. Thanks Dan
Re: looking for V[string] workarounds
On 03/20/2013 10:24 AM, Dan wrote: On Wednesday, 20 March 2013 at 17:11:02 UTC, Ali Çehreli wrote: The code compiles with 2.062 and an earlier version of 2.063 if you accept letting go of const-correctness there: this(Series[string] source) { Thanks Ali. But, removing const there then requires non-const instances to be passed in, due to const transitivity. So that requirement would ripple a change to all already const correct instances to now need to flip to non-const. I'm looking for a const correct solution. It should be doable ... I just have had no luck with it. In that case, brute force to the rescue (nc stands for non-const): :) this(const(Series[string]) source) { auto nc_source = cast(Series[string])source; itemToSeries = nc_source.dup; } Ali
Re: recursive equal, and firstDifference functions
On Wednesday, March 20, 2013 12:47:38 Dan wrote: > I would > imagine by now there is a fair amount of code that might rely on > a false result from opEquals if the members (slices, associative > arrays) are not bitwise the same. I think that it's more likely that there's a lot of code that expects strings and the like to have their elements checked for equality when they're in a struct and is therefore buggy at present due to the fact that they aren't. As for AAs (which I forgot about), I don't remember what they're supposed to do with ==. They might just do a pointer comparison - or they may do a deeper comparison; I don't know. But the big problem there is that structs need to compare each of their members with ==, and that's not working properly at the moment, so that throws a major wrench in how == works. - Jonathan M Davis
initializing const maps with value types having aliasing
The following works and is the only way I have found to initialize m. Unfortunately it requires the cast. Is this safe to do? Is there a better way? Is this a bug or are future features coming to clean it up? Thanks Dan -- import std.stdio; struct S { this(this) { x = x.dup; } char[] x; } const(S[string]) m; static this() { // Is there a cleaner way? cast(S[string])m = [ "foo" : S(['a']) ]; } void main() { writeln(m["foo"]); }
Re: A little of coordination for Rosettacode
On Tuesday, 19 March 2013 at 18:53:21 UTC, bearophile wrote: Small changes on your version: http://codepad.org/E9KHKvAi It's now on Rosettacode. I have added more changes to make it able to deal with immutable input. Bye, bearophile Another issue to consider as the question I was attempting ended up requiring this, I wasn't aware of it when I made the original post: The prime factorization of 1 is an empty set, so surely to be correct it should return [] when given 1 and not throw an exception. This also suggests a possible modification to [].reduce!"a * b" as mathematically the product of the empty set is defined as 1.
Re: initializing const maps with value types having aliasing
On Wednesday, March 20, 2013 19:41:00 Dan wrote: > The following works and is the only way I have found to > initialize m. > Unfortunately it requires the cast. > > Is this safe to do? > Is there a better way? > Is this a bug or are future features coming to clean it up? > > Thanks > Dan > > -- > import std.stdio; > struct S { > this(this) { x = x.dup; } > char[] x; > } > > const(S[string]) m; > static this() { > // Is there a cleaner way? > cast(S[string])m = [ "foo" : S(['a']) ]; > } > > void main() { > writeln(m["foo"]); > } Why are you casting? The cast shouldn't be necessary, because you're doing the initialization inside a static constructor. If you had problems, I'd expect it to be that AAs don't work properly when const (I know that there are issues when they're immutable) or that you can't insert elements into a const or immutable AA (which you'll never be able to do). But what you're doing here should work just fine without the cast. Assuming that AAs worked with const or immutable correctly, then it would be normal to do something like immutable int[string] aa; static this() { int[string] temp; temp["foo"] = 7; temp["blah"] = 12; aa = assumeUnique(temp); } - Jonathan M Davis
Re: A little of coordination for Rosettacode
ixid: The prime factorization of 1 is an empty set, so surely to be correct it should return [] when given 1 and not throw an exception. The Task says that the input can't be 1, so the input 1 needs to be a pre-condition violation: Write a function which returns an array or collection which contains the prime decomposition of a given number, n, greater than 1< This also suggests a possible modification to [].reduce!"a * b" as mathematically the product of the empty set is defined as 1. reduce() is a general function, so it's not supposed to know that. Python reduce does the same: reduce(lambda a, b: a * b, []) Traceback (most recent call last): File "", line 1, in TypeError: reduce() of empty sequence with no initial value If you want that, then you have to use: reduce!"a * b"(1, items) And some time from now: items.reduce!"a * b"(1) If we add a product() function to Phobos similar to sum() (http://d.puremagic.com/issues/show_bug.cgi?id=4725 ) then I agree that for empty ranges it will need to return the multiplicative identity element. Bye, bearophile
Re: OpenCL bindings
On 2013-03-20 14:25, Mike Parker wrote: Can dstep output function declarations as aliased function pointers in the format I use in Derelict? I guess I could make an option for that. -- /Jacob Carlborg
Re: OpenCL bindings
On 2013-03-20 14:59, Andrea Fontana wrote: *Very* useful. I hope it will be updated with some small changes (like anonymous struct alias replacement and d keyword replacement) :) It should already to D keyword replacement, if not, please report an issue with a test case: https://github.com/jacob-carlborg/dstep/issues/new What is "anonymous struct alias replacement"? You can also create issues for enhancement requests. -- /Jacob Carlborg
Re: initializing const maps with value types having aliasing
Dan: this(this) { x = x.dup; } I think this(this) doesn't work well with const. cast(S[string])m = [ "foo" : S(['a']) ]; I think I have never seen code like that. What's the meaning? :-) (Also if you remove that cast then dmd gives bad error messages with no line numbers: Error: mutable method temp.S.__postblit is not callable using a const object Error: cannot modify struct this Slot with immutable members ). Bye, bearophile
Re: initializing const maps with value types having aliasing
On Wednesday, 20 March 2013 at 19:01:27 UTC, Jonathan M Davis wrote: Why are you casting? The cast shouldn't be necessary, because you're doing the initialization inside a static constructor. Without it I get: Error: mutable method cmap.S.__postblit is not callable using a const object Error: cannot modify struct this Slot with immutable members If you had problems, I'd expect it to be that AAs don't work properly when const (I know that there are issues when they're immutable) or that you can't insert elements into a const or immutable AA (which you'll never be able to do). But what you're doing here should work just fine without the cast. Assuming that AAs worked with const or immutable correctly, then it would be normal to do something like immutable int[string] aa; static this() { int[string] temp; temp["foo"] = 7; temp["blah"] = 12; aa = assumeUnique(temp); } For now it seems the cast is necessary - so as long as it is safe. I am not using 'immutable S[string]aa', but it would be interesting to see how that could be initialized. So, how to initialize aa. Does assumeUnique work for associative arrays? -- import std.exception; struct S { this(this) { x = x.dup; } char[] x; } immutable S[string] aa; static this() { // now what } Thakns Dan
Re: Trying to implement a reference counting mechanism
On 03/19/2013 11:06 PM, Martin wrote: http://pastebin.com/8M2EuyfT I'm fairly new to D, but would this work? Obviously I would need to make my own kind of associative array that uses manual memory management to completely circumvent the GC, but besides that? It looks like your refCount is off by one, i think you need to set it to 1 in the refCountedObj function, or check for refCount < 0 before freeing the value. -- Mike Wey
Re: Trying to implement a reference counting mechanism
On Wednesday, 20 March 2013 at 19:19:09 UTC, Mike Wey wrote: On 03/19/2013 11:06 PM, Martin wrote: http://pastebin.com/8M2EuyfT I'm fairly new to D, but would this work? Obviously I would need to make my own kind of associative array that uses manual memory management to completely circumvent the GC, but besides that? It looks like your refCount is off by one, i think you need to set it to 1 in the refCountedObj function, or check for refCount < 0 before freeing the value. Oh, my bad, I actually had that in the code, but when I copy/pasted it on pastebin, I had to remove some comments n stuff and I accidentally removed it along with a "import std.conv".
Re: looking for V[string] workarounds
On Wednesday, 20 March 2013 at 17:44:16 UTC, Ali Çehreli wrote: In that case, brute force to the rescue (nc stands for non-const): :) this(const(Series[string]) source) { auto nc_source = cast(Series[string])source; itemToSeries = nc_source.dup; } Wow - that worked. Thanks! I hope it is safe.
Re: initializing const maps with value types having aliasing
On Wednesday, March 20, 2013 20:15:46 Dan wrote: > On Wednesday, 20 March 2013 at 19:01:27 UTC, Jonathan M Davis > > wrote: > > Why are you casting? The cast shouldn't be necessary, because > > you're doing the > > initialization inside a static constructor. > > Without it I get: > Error: mutable method cmap.S.__postblit is not callable using a > const object > Error: cannot modify struct this Slot with immutable members postblits do not work with const or immutable. Once you have a postblit, you can't copy your object. It's a major problem with postblits. They simply fundamentally can't work with them (because the way that they work would require modifying a const or immutable variable), and it almost certainly means that we're going to need to add copy constructors to the language, but that hasn't been sorted out yet. > > If you had problems, I'd expect it > > to be that AAs don't work properly when const (I know that > > there are issues > > when they're immutable) or that you can't insert elements into > > a const or > > immutable AA (which you'll never be able to do). But what > > you're doing here > > should work just fine without the cast. Assuming that AAs > > worked with const or > > immutable correctly, then it would be normal to do something > > like > > > > immutable int[string] aa; > > > > static this() > > { > > > > int[string] temp; > > temp["foo"] = 7; > > temp["blah"] = 12; > > aa = assumeUnique(temp); > > > > } > > For now it seems the cast is necessary - so as long as it is safe. Well, it may work, but I believe that it's undefined behavior. Casting away const and modifying an object is undefined behavior, and while the AA itself may not have that problem due to the fact that it's being initialized rather than assigned to, the fact that it's working by making a postblit work _is_ undefined behavior, because that means that you're modifying a const object inside of the postblit constructor. > I am not using 'immutable S[string]aa', but it would be > interesting to see how that could be initialized. So, how to > initialize aa. Does assumeUnique work for associative arrays? > -- > import std.exception; > > struct S { > this(this) { x = x.dup; } > char[] x; > } > > immutable S[string] aa; > > static this() { > // now what > } All assumeUnique does is cast to immutable. It's just the idiomatic way to initialize an immutable variable from a unique mutable object, because it makes it clearer what you're doing. - Jonathan M Davis
Re: OpenCL bindings
On 2013-03-20 14:25, Mike Parker wrote: Can dstep output function declarations as aliased function pointers in the format I use in Derelict? BTW, why does it uses aliases and not declare a function pointer directly? -- /Jacob Carlborg
getChar() vs. getChar!true()
In std.json is a function getchar() with this signature: dchar getChar(bool SkipWhitespace = false); But it is called differently: getChar(); // obviously SkipWhitespace = true; getChar!true(); // probably getchar(true) What is the reason for the different notation ? Peter
Re: getChar() vs. getChar!true()
On Wednesday, 20 March 2013 at 20:11:47 UTC, Peter Sommerfeld wrote: In std.json is a function getchar() with this signature: dchar getChar(bool SkipWhitespace = false); It looks like the signature (line 115) is: dchar getChar(bool SkipWhitespace = false)() Note the extra set of parens at the end, making the bool a template parameter.
Re: getChar() vs. getChar!true()
On 03/20/2013 01:11 PM, Peter Sommerfeld wrote: > In std.json is a function getchar() with this signature: > > dchar getChar(bool SkipWhitespace = false); That 'false' up there is the default value of SkipWhitespace. > But it is called differently: > > getChar(); // obviously SkipWhitespace = true; No, in that case SkipWhitespace==true. > getChar!true(); // probably getchar(true) > > What is the reason for the different notation ? The same thing; just being explicit. Aside: bool parameters (regular or template) hurt readability. It would be better to have defined a type similar to std.stdio.KeepTerminator and its use with byLine(): http://dlang.org/phobos/std_stdio.html#.File.byLine Ali
Re: getChar() vs. getChar!true()
On 03/20/2013 01:27 PM, Ali Çehreli wrote: > > getChar(); // obviously SkipWhitespace = true; > > No, in that case SkipWhitespace==true. I said "No" but kept your value. :) I meant "No, in that case SkipWhiteSpace==false." Ali
Re: getChar() vs. getChar!true()
cal wrote: On Wednesday, 20 March 2013 at 20:11:47 UTC, Peter Sommerfeld wrote: In std.json is a function getchar() with this signature: dchar getChar(bool SkipWhitespace = false); It looks like the signature (line 115) is: dchar getChar(bool SkipWhitespace = false)() Note the extra set of parens at the end, making the bool a template parameter. Thanks, I must look more carefully... Peter
Re: OpenCL bindings
On Wednesday, 20 March 2013 at 19:10:28 UTC, Jacob Carlborg wrote: On 2013-03-20 14:59, Andrea Fontana wrote: *Very* useful. I hope it will be updated with some small changes (like anonymous struct alias replacement and d keyword replacement) :) It should already to D keyword replacement, if not, please report an issue with a test case: Maybe I have a old (binary) version for linux. For example params named "out" are not replaced with something else (f.e. _out) https://github.com/jacob-carlborg/dstep/issues/new What is "anonymous struct alias replacement"? You can also create issues for enhancement requests. I mean that typedef struct { ... } hello; is translate as an anonymous struct and then "aliased". I think it can be translated directly as a named struct.
Re: getChar() vs. getChar!true()
Ali Çehreli: Aside: bool parameters (regular or template) hurt readability. It would be better to have defined a type similar to std.stdio.KeepTerminator and its use with byLine(): http://dlang.org/phobos/std_stdio.html#.File.byLine I see. On the other hand: For an internal function like getChar()() the implementation seem so be a bit to intricate. But for a public API certainly preferable. Peter
Re: OpenCL bindings
On 2013-03-20 22:02, Andrea Fontana wrote: Maybe I have a old (binary) version for linux. For example params named "out" are not replaced with something else (f.e. _out) I checked the history and see that I added a fixed for this for function parameters just after the release. I'm pretty sure that in all other place it will handle it correctly. I mean that typedef struct { ... } hello; is translate as an anonymous struct and then "aliased". I think it can be translated directly as a named struct. I see, I'm not so how easy this would be. But I can have a look. Please add an issue so it's not forgotten. -- /Jacob Carlborg
Are there D bindings for Win7's Core Audio anywhere?
It seems to be COM-based, so it should be usable from D.
Re: Are there D bindings for Win7's Core Audio anywhere?
On 3/20/13, Andrej Mitrovic wrote: > It seems to be COM-based, so it should be usable from D. Actually slight correction, for example the endpointvolume.h header in the Windows SDK defines both a COM and a C API, but the COM API is probably easier to use.
Re: OpenCL bindings
On Wednesday, 20 March 2013 at 19:54:42 UTC, Jacob Carlborg wrote: On 2013-03-20 14:25, Mike Parker wrote: Can dstep output function declarations as aliased function pointers in the format I use in Derelict? BTW, why does it uses aliases and not declare a function pointer directly? Because some time ago DMD started shipping with '--export-dynamic' in the config file on Linux to (AFAIK) facilitate generation of exception stack traces. I was using straight function pointers at the time and, as a result, no one could use Derelict on Linux because of symbol clashes (e.g. the function pointer for glClear would clash with the glClear symbol in the shared lib). Switching to aliased function pointers was the work around. I will never "get" Linux.