On 6/3/13, bearophile <bearophileHUGS@lycos.com> wrote:
> Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html

Because it's on this page:

http://dlang.org/interfaceToC.html

> It seems it lacks some of them, this gives an import error: import core.stdc.config: c_ulonglong, c_longlong;

Again see http://dlang.org/interfaceToC.html

On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:
> http://dlang.org/interfaceToC.html

aaaaah then what is this page doing there?
http://dlang.org/htomodule.html

The documentation could def use a lil cleanup.

Andrej Mitrovic:

> Because it's on this page:
>
> http://dlang.org/interfaceToC.html
>
>> It seems it lacks some of them, this gives an import error:
>> import core.stdc.config: c_ulonglong, c_longlong;
>
> Again see http://dlang.org/interfaceToC.html

Good, thank you. I missed that.

Bye,
bearophile

Am Mon, 03 Jun 2013 01:02:12 +0200
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> 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.

XCB is generated from these XML files. They have nothing to do
with Xlib. You can find the XML files here:
http://cgit.freedesktop.org/xcb/proto/tree/src
A generator tool for the target language (C in this case)
parses them and creates include files from them that define
all the remote procedure calls to the X Server. Internally
those calls rely on a small generic set of functions that
serializes the requests for transmission.

What is needed are those generic functions written in D to
establish the connection to the server and handling
serialization, probably relying on std.socket.
And then an XML parser that would write out .d files for the
different modules of the X Server, like xrandr, xkb and so on,
which are all available as separate XML files.

This is what a RPC from glx.xml looks like:

	<request name="GenTextures" opcode="145">
		<field type="CONTEXT_TAG" name="context_tag" />
		<field type="INT32" name="n" />
		<reply>
			<pad bytes="1" />
			<pad bytes="24" />
			<list type="CARD32" name="data">
				<fieldref>length</fieldref>
			</list>
		</reply>
	</request>

In general they also include documentation tags which can be made available through DDoc automatically and displayed in IDEs like Mono-D already does.

> 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...

The big deal about it is asynchronous RCP especially over internet connections to X Servers, since with Xlib you have to way for each response before the next request.

-- 
Marco

On 6/3/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:
>> http://dlang.org/interfaceToC.html
>
> aaaaah then what is this page doing there? http://dlang.org/htomodule.html
>
> The documentation could def use a lil cleanup.

There's a bug report for everything: http://d.puremagic.com/issues/show_bug.cgi?id=7346

I'm like a handy little bugzilla bot. :p

On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:
> all the remote procedure calls to the X Server. Internally
> those calls rely on a small generic set of functions that
> serializes the requests for transmission.

I see. I just skimmed an xcb tutorial and it isn't all that different than xlib so maybe I'll spend a weekend on it at some point and make it work in D.

There's a few things we can do to make the async stuff pretty too, thanks to delegates and the sort.

And perhaps I can add a concept of a sprite to simplediplay. This represents an XPixmap - distinct from an XImage in that it is on the server - or on Windows, we can probably just us an HBITMAP. These wouldn't offer direct pixel manipulation like simplediplay's current Image (which is an XImage and HBITMAP in implementation) but would be able to avoid transferring a lot of data to the X server.

And lastly (optionally, like with terminal.d) tie it into my generic eventloop.d. Then we'll really be cooking with gas! It'll have to wait a while though, hacking on this stuff doesn't make my house payments :(

On Monday, 3 June 2013 at 01:31:27 UTC, Adam D. Ruppe wrote:
> On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:
>> all the remote procedure calls to the X Server. Internally
>> those calls rely on a small generic set of functions that
>> serializes the requests for transmission.
>
> I see. I just skimmed an xcb tutorial and it isn't all that different than xlib so maybe I'll spend a weekend on it at some point and make it work in D.
>
> There's a few things we can do to make the async stuff pretty too, thanks to delegates and the sort.
>
> And perhaps I can add a concept of a sprite to simplediplay. This represents an XPixmap - distinct from an XImage in that it is on the server - or on Windows, we can probably just us an HBITMAP. These wouldn't offer direct pixel manipulation like simplediplay's current Image (which is an XImage and HBITMAP in implementation) but would be able to avoid transferring a lot of data to the X server.
>
> And lastly (optionally, like with terminal.d) tie it into my generic eventloop.d. Then we'll really be cooking with gas! It'll have to wait a while though, hacking on this stuff doesn't make my house payments :(

There is already a functional XCB binding somewhere on GitHub. I managed to compiled it and play with it last year with success.

On Wednesday, 5 June 2013 at 16:33:57 UTC, Dejan Lekic wrote:
> There is already a functional XCB binding somewhere on GitHub. I managed to compiled it and play with it last year with success.

cool... I found one on dsource but not github yet. The dsource one transforms the XML but doesn't seem to implement all needed functions. Shouldn't be hard to complete anyway though.

This is kinda exciting. I gotta say, part of me wants to write an X /server/ now too. How hard can it be? Run the protocol generator in reverse if you will and implement the functions I want. Why? Cuz then I'll add extensions I want to play with easily and ultimately compile it to javascript :P

Very good news that I can now compile it on my 64 bit machine,
because dmd not only refused to in the past but I couldn't even
get -m32 working. (Probably installed something somewhere
incorrectly?)

Thank you :)

Am Thu, 06 Jun 2013 01:27:58 +0200
schrieb "Adam D. Ruppe" <destructionator@gmail.com>:

> cool... I found one on dsource but not github yet. The dsource one transforms the XML but doesn't seem to implement all needed functions. Shouldn't be hard to complete anyway though.

Does that mirror XCB (independent of XCB, implements RPC) or
add a wrapper layer around the C bindings? Because it would be
kinda cool to have a real X sever binding in D and not just
D bindings to the C bindings to the X server. :p

-- 
Marco