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 lubos.pin...@gmail.com
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(contentLength0) {
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.
status code/response
header
[header]
blank line
body
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 stdin, line 1, in module 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 andrej.mitrov...@gmail.com 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.
