I know someone here was asking about my simpledisplay.d on 64 bit a while ago.. I don't remember who so here's a general announcement.

I got it working for at least the parts I tried (display image, get keyboard input) compiled with -m64:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d

Quite a hassle, my xlib binding was apparently almost completely wrong, and it worked on 32 bit just by sheer luck. Many of the structs were the wrong sizes even there! General tip to C porters: do a static assert(S.sizeof) and make sure it matches what your C program gives. I got snagged in part here because unsigned long in X is apparently 64 bit. I thought it was the same as D's uint in all cases.

The file it also depends on color.d from the same repo. Another minor change is the key event used to take a delegate (int key){}. Now it takes (int key, bool pressed) instead. There's a static assert with a reminder message too, so just compile and if you need it, it will tell you. The (dchar){} event remains the same as before.

Been a few random bug fixes in the last few months too, timer events now work right on windows and linux is the big one that comes to mind.

I'm sorry to hear that you ran into the unsigned long problem. I noticed it in time and asked about it on the NG and was told that the difference is between Windows and Posix. One takes long as int32, the other as the native machine word size on 64-bit. We do the same stupid mistakes over and over. :p

Also eventually we should generate X bindings for all platforms (including Windows) from the XML definitions like XCB does. That means a small core written in D that enables RPC to the X Server and a generator tool that creates functions, structs and DDoc from what is the XML files. (See /usr/share/xcb.)

-- 
Marco

On 6/2/13, Marco Leise <Marco.Leise@gmx.de> wrote:
> I'm sorry to hear that you ran into the unsigned long problem.

This is why we have core.std.config:

import core.stdc.config : c_long, c_ulong;

On Sunday, 2 June 2013 at 22:16:57 UTC, Andrej Mitrovic wrote:
> This is why we have core.std.config:
>
> import core.stdc.config : c_long, c_ulong;

I would never have thought to look in "config" for types! Well, hopefully I'll remember for next time.

On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote:
> Also eventually we should generate X bindings for all
> platforms (including Windows) from the XML definitions like
> XCB does.

hmm I don't see an xml file for Xlib.h on my system, do you know if there is supposed to be one? Though I'm pretty sure I have most of it correct now, so I guess it isn't really necessary.

I know everybody says Xlib is dying but I still use it. It is simple enough and gets the job done without having to learn a whole thing library...

Andrej Mitrovic:

> This is why we have core.std.config:
>
> import core.stdc.config : c_long, c_ulong;

Why isn't that linked in this page?
http://dlang.org/phobos/std_stdint.html

I'd like to open a little documentation enhancement request for that.

Bye,
bearophile

On 6/2/13 7:10 PM, bearophile wrote:
> Andrej Mitrovic:
>
>> This is why we have core.std.config:
>>
>> import core.stdc.config : c_long, c_ulong;
>
> Why isn't that linked in this page?
> http://dlang.org/phobos/std_stdint.html
>
> I'd like to open a little documentation enhancement request for that.
>
> Bye,
> bearophile

And while you are at it, please also contribute the corresponding pull request. Time to inaugurate bearophile's additions!

Andrei

> Why isn't that linked in this page?
> http://dlang.org/phobos/std_stdint.html

It seems it lacks some of them, this gives an import error:

import core.stdc.config: c_ulonglong, c_longlong;

Bye,
bearophile

On Sunday, 2 June 2013 at 23:19:18 UTC, bearophile wrote:
> It seems it lacks some of them, this gives an import error:

It only defines c_long and c_ulong. I guess this is ok because the other types don't vary, though I kinda think it should do them all just so you can be consistent.

Not long ago I thought int on 64 bit was 64 bit too, because int on 16 bit is 16 bit so I figured it just did that the whole way up. But no, C's int is always D's int.

A nice c_int alias would make that mindless too, even though it isn't strictly necessary.

Andrei Alexandrescu:

> And while you are at it, please also contribute the corresponding pull request. Time to inaugurate bearophile's additions!

As my friend, please understand, I can't afford to get addicted to that :-)

Hugs,
bearophile