www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - [deimos] [tutorial] [rfc] How to set up a git repository to

reply Johannes Pfau <spam example.com> writes:
This explains a special repository setup which allows to merge changes
made in C headers into the correct place in the D import files
automatically. This new, merged parts still need to be translated into
D code, but the automatic merge makes sure you don't miss a change in
the C headers.

https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure

Comments are of course appreciated. The wiki page is also public, so
feel free to correct mistakes. If possible, this should go somewhere
into the official deimos project (wiki).

(Yes, I know there's a typo in the screenshots (daeamon) and the
screenshots don't match the text 100% as they were taken before the
text was written)
-- 
Johannes Pfau
Nov 11 2011
next sibling parent reply mta`chrono <chrono mta-international.net> writes:
Hey Johannes,

thanks for your great effort of writing a tutuorial. Later on you'll
have to import the bindings this way:

import systemd.deimos.sd_daeamon;
import systemd.deimos.sd_readahead;

I rather prefer something like this:

import deimos.systemd.sd_daeamon;
import deimos.systemd.sd_readahead;
import deimos.mysql.mysql;
import deimos.cairo.pdf;
import deimos.cairo.svg;
import deimos.gtk.gtk;

- mta`chrono
Nov 11 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Johannes Pfau wrote:

 
 Scratch that, turns out the headers are actually in a systemd folder.
 Ubuntu doesn't provide a systemd package, and the directory structure
 is not visible in the source package. So it'll be
 deimos.systemd.sd_readahead ;-)

You are my hero for making binding to systemd! \o/ I want to play with it on my Fedora box asap! :)
Nov 16 2011
parent Dejan Lekic <dejan.lekic gmail.com> writes:
Johannes Pfau wrote:

 Also writing a daemon in systemd is actually a lot easier that the
 traditional way (see
 http://0pointer.de/public/systemd-man/daemon.html ), so have fun :-)
 

Sure it is easier, but less portable. :) Systemd is going to be very nice once it is widely adopted by various Linux ecosystems.
Nov 18 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It seems to me that people already use arbitrary ways of naming
modules, IOW the deimos idea is becoming a mess:

module deimos.libsndfile.d.sndfile;
https://github.com/dawgfoto/deimos/blob/master/libsndfile/deimos/sndfile.di

module ncurses;
https://github.com/1100110/deimos-1/blob/master/ncurses/D/ncurses.d

module deimos.lzma;
https://github.com/jpf91/deimos/blob/liblzma/liblzma/deimos/lzma.d

Personally I think naming modules "deimos.modulename" is a bad idea.
What if you want to use two C libraries in a single app which both
define a module with the same name?

import deimos.tests;  // wanted lib1.tests
import deimos.tests;  // wanted lib2.tests, woops!

If deimos was just a directory name and not included in the module
name we could have this sort of directory tree:

/deimos/lbzma/file.di
/deimos/lbzma/c/file.h
/deimos/gtk/file.di
/deimos/gtk/c/file.h
/deimos/cairo/file.di
/deimos/cairo/c/file.h

The modules would be named as:
module lbzma.file;
module gtk.file;
module cairo.file;

And then the only thing you would have to do to start using any of
these is add -I<path_to_deimos> to your projects, and you wouldn't
have name clashes if you used more than one library.
Nov 11 2011
next sibling parent mta`chrono <chrono mta-international.net> writes:
 According to the deimos manifesto:
 ---------------------------------
 Deimos is a collection of C header files to publicly available C
 libraries and their translations to D. The idea is that if, in C, to
 interface to a library one would write:
 #include "foo.h"
 then the corresponding D code would look like:
    import foo;
 or:
    import deimos.foo;

Sorry, that I've to say that, but I think this is crap. A very different approach that we know from C, the D language offers a great feature called namespaces. In fact we're able to arrange our modules in the namespace that doesn't have necessarily to match with the corresponding filename. There has always been the bump that some people wrote #include <mysql.h> and compiled with -I/usr/include instead of -I/usr/include/mysql. Most of the .h files that are stored directly (without subfolders) in /usr/include are already covered by druntime. So, why not just use __ONE__ convention for all the rest? import deimos.library.modulename; === Examples: === private import deimos.lzma.base, deimos.lzma.block, deimos.lzma.container, deimos.lzma.version; private import deimos.gtk.gtk, deimos.gtk.window, deimos.gtk.celllayout, deimos.gtk.assistant, deimos.gtk.misc; private import deimos.x11.xlib, deimos.x11.xutil, deimos.x11.xos, deimox.x11.keysym, deimos.x11.xatom; private import deimos.libpng.png, deimos.libpng.conf; private import deimos.cairo.pdf, deimos.cairo.svg, deimos.cairo.ps; private import deimos.mysql.global, deimos.mysql.embed, deimos.mysql.version; Additionally we could provide some shortcuts. If you do import deimos.library; it will public import deimos.library.*; === Examples: === import deimos.lzma; import deimos.gtk; import deimos.x11; import deimos.libpng; import deimos.cairo; import deimos.mysql; And last but not least I prefer using https://github.com/D-Programming-Deimos instead of https://github.com/D-Programming-Language/deimos. Imagine if deimos becomes bigger and we'll have more than 100 pending pull requests across different bindings. That will all result in a big mess. So please each binding should have it's own repository. If you're going to install all, then add d-p-l to your /etc/apt/sources.lst and enter apt-get install deimos-*. Or make use of a shell script that iterates through all repos in /usr/include/d/dmd/deimos and calls git pull.
Nov 12 2011
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I believe once Deimos will mature in time, especially if all authors of 
Deimos projects gather around and do some organisation...
Nov 15 2011
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--f46d0433a0f2070d9704b17dc181
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 11, 2011 at 1:43 PM, Johannes Pfau <spam example.com> wrote:

 This explains a special repository setup which allows to merge changes
 made in C headers into the correct place in the D import files
 automatically. This new, merged parts still need to be translated into
 D code, but the automatic merge makes sure you don't miss a change in
 the C headers.

 https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure

 Comments are of course appreciated. The wiki page is also public, so
 feel free to correct mistakes. If possible, this should go somewhere
 into the official deimos project (wiki).

 (Yes, I know there's a typo in the screenshots (daeamon) and the
 screenshots don't match the text 100% as they were taken before the
 text was written)
 --
 Johannes Pfau

bit thinking that you were just using a branch like a folder. Reading on, though, I found what you are doing rather clever and a great way to maintain things. Neat idea. Regards Brad Anderson --f46d0433a0f2070d9704b17dc181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2011 at 1:43 PM, Johannes Pfau <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:spam example.com">spam example.com</a>&gt;</span> wrote:<br><di= v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> This explains a special repository setup which allows to merge changes<br> made in C headers into the correct place in the D import files<br> automatically. This new, merged parts still need to be translated into<br> D code, but the automatic merge makes sure you don&#39;t miss a change in<b= r> the C headers.<br> <br> <a href=3D"https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structur= e" target=3D"_blank">https://github.com/jpf91/systemd/wiki/Deimos-git-branc= h-structure</a><br> <br> Comments are of course appreciated. The wiki page is also public, so<br> feel free to correct mistakes. If possible, this should go somewhere<br> into the official deimos project (wiki).<br> <br> (Yes, I know there&#39;s a typo in the screenshots (daeamon) and the<br> screenshots don&#39;t match the text 100% as they were taken before the<br> text was written)<br> <span class=3D"HOEnZb"><font color=3D"#888888">--<br> Johannes Pfau<br> <br> </font></span></blockquote></div><br><div>When I first saw you making a bra= nch for the c headers I kind of scoffed a bit thinking that you were just u= sing a branch like a folder. =A0Reading on, though, I found what you are do= ing rather clever and a great way to maintain things. =A0Neat idea.</div> <div><br></div><div>Regards</div><div>Brad Anderson</div> --f46d0433a0f2070d9704b17dc181--
Nov 11 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
On Fri, 11 Nov 2011 21:43:18 +0100, Johannes Pfau wrote:

 This explains a special repository setup which allows to merge changes
 made in C headers into the correct place in the D import files
 automatically. This new, merged parts still need to be translated into D
 code, but the automatic merge makes sure you don't miss a change in the
 C headers.
 
 https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure
 
 Comments are of course appreciated. The wiki page is also public, so
 feel free to correct mistakes. If possible, this should go somewhere
 into the official deimos project (wiki).
 
 (Yes, I know there's a typo in the screenshots (daeamon) and the
 screenshots don't match the text 100% as they were taken before the text
 was written)

Nice, I've tried to figure out how to get this behavior in the past, but hadn't succeeded.
Nov 11 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
mta`chrono wrote:
Hey Johannes,

thanks for your great effort of writing a tutuorial. Later on you'll
have to import the bindings this way:

import systemd.deimos.sd_daeamon;
import systemd.deimos.sd_readahead;

I rather prefer something like this:

import deimos.systemd.sd_daeamon;
import deimos.systemd.sd_readahead;
import deimos.mysql.mysql;
import deimos.cairo.pdf;
import deimos.cairo.svg;
import deimos.gtk.gtk;

- mta`chrono

Hi, the tutorial focuses on setting up branches to allow easy merging of c changes, the directory names aren't that important. Although I don't want to have a systemd.deimos namespace, it's meant to be deimos.sd_daemon and deimos.sd_readahead. I think adding a 'systemd' in there would make sense but Walter wanted libraries in deimos to follow the naming convention deimos.[c header name] and systemd uses two toplevel headers. The reason for the additional systemd folder is that you don't want all repositories to be named as "deimos". However, it'd probably be good to add explicit moule names to the modules to make that clear. -- Johannes Pfau
Nov 12 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Andrej Mitrovic wrote:
It seems to me that people already use arbitrary ways of naming
modules, IOW the deimos idea is becoming a mess:

module deimos.libsndfile.d.sndfile;
https://github.com/dawgfoto/deimos/blob/master/libsndfile/deimos/sndfile.di

module ncurses;
https://github.com/1100110/deimos-1/blob/master/ncurses/D/ncurses.d

module deimos.lzma;
https://github.com/jpf91/deimos/blob/liblzma/liblzma/deimos/lzma.d

Well, once the first project is added to deimos, we'll have some kind of standard.
Personally I think naming modules "deimos.modulename" is a bad idea.
What if you want to use two C libraries in a single app which both
define a module with the same name?

According to the deimos manifesto: --------------------------------- Deimos is a collection of C header files to publicly available C libraries and their translations to D. The idea is that if, in C, to interface to a library one would write: #include "foo.h" then the corresponding D code would look like: import foo; or: import deimos.foo; --------------------------------- liblzma and systemD follow these conventions. Note that C libraries with multiple headers often have a kind of namespace system: #include "cairo/foo.h" #include "cairo/file.h" --> import deimos.cairo.foo; --> import deimos.cairo.file;
import deimos.tests;  // wanted lib1.tests
import deimos.tests;  // wanted lib2.tests, woops!

If deimos was just a directory name and not included in the module
name we could have this sort of directory tree:

/deimos/lbzma/file.di
/deimos/lbzma/c/file.h
/deimos/gtk/file.di
/deimos/gtk/c/file.h
/deimos/cairo/file.di
/deimos/cairo/c/file.h

The modules would be named as:
module lbzma.file;
module gtk.file;
module cairo.file;

And then the only thing you would have to do to start using any of
these is add -I<path_to_deimos> to your projects, and you wouldn't
have name clashes if you used more than one library.

I think the C headers already have to be named in a way to avoid clashes, '/usr/include/tests.h' can only be provided by one library, so usually we shouldn't get conflicts in deimos. -- Johannes Pfau
Nov 12 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Johannes Pfau wrote:
mta`chrono wrote:
Hey Johannes,

thanks for your great effort of writing a tutuorial. Later on you'll
have to import the bindings this way:

import systemd.deimos.sd_daeamon;
import systemd.deimos.sd_readahead;

I rather prefer something like this:

import deimos.systemd.sd_daeamon;
import deimos.systemd.sd_readahead;
import deimos.mysql.mysql;
import deimos.cairo.pdf;
import deimos.cairo.svg;
import deimos.gtk.gtk;

- mta`chrono

Hi, the tutorial focuses on setting up branches to allow easy merging of c changes, the directory names aren't that important. Although I don't want to have a systemd.deimos namespace, it's meant to be deimos.sd_daemon and deimos.sd_readahead. I think adding a 'systemd' in there would make sense but Walter wanted libraries in deimos to follow the naming convention deimos.[c header name] and systemd uses two toplevel headers.

Scratch that, turns out the headers are actually in a systemd folder. Ubuntu doesn't provide a systemd package, and the directory structure is not visible in the source package. So it'll be deimos.systemd.sd_readahead ;-)
The reason for the additional systemd folder is that you don't want
all repositories to be named as "deimos". However, it'd probably be
good to add explicit moule names to the modules to make that clear. 

-- Johannes Pfau
Nov 12 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Fri, 11 Nov 2011 22:43:18 +0200, Johannes Pfau <spam example.com> wrote:

 (Yes, I know there's a typo in the screenshots (daeamon) and the
 screenshots don't match the text 100% as they were taken before the
 text was written)

For the screenshots, you have used a 3rd-party GUI which is only available on *nix. Consider using gitk, which is included with git and runs on Windows. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Nov 12 2011
parent Dejan Lekic <dejan.lekic gmail.com> writes:
Vladimir Panteleev wrote:

 On Fri, 11 Nov 2011 22:43:18 +0200, Johannes Pfau <spam example.com>
 wrote:
 
 (Yes, I know there's a typo in the screenshots (daeamon) and the
 screenshots don't match the text 100% as they were taken before the
 text was written)

For the screenshots, you have used a 3rd-party GUI which is only available on *nix. Consider using gitk, which is included with git and runs on Windows.

I do not use Giggle and I understood all those screenshots. All git gui frontends are similar, and if a developer is familiar with any of them, understanding Giggle screenshots won't be a problem at all.
Nov 15 2011
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Johannes Pfau wrote:

 This explains a special repository setup which allows to merge changes
 made in C headers into the correct place in the D import files
 automatically. This new, merged parts still need to be translated into
 D code, but the automatic merge makes sure you don't miss a change in
 the C headers.
 
 https://github.com/jpf91/systemd/wiki/Deimos-git-branch-structure
 
 Comments are of course appreciated. The wiki page is also public, so
 feel free to correct mistakes. If possible, this should go somewhere
 into the official deimos project (wiki).
 
 (Yes, I know there's a typo in the screenshots (daeamon) and the
 screenshots don't match the text 100% as they were taken before the
 text was written)

Brilliant! Thanks for that, Johannes! :)
Nov 15 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Dejan Lekic wrote:
Johannes Pfau wrote:

 
 Scratch that, turns out the headers are actually in a systemd folder.
 Ubuntu doesn't provide a systemd package, and the directory structure
 is not visible in the source package. So it'll be
 deimos.systemd.sd_readahead ;-)

You are my hero for making binding to systemd! \o/ I want to play with it on my Fedora box asap! :)

It's ready to be used: https://github.com/jpf91/systemd But writing the bindings was really trivial, only ~12 functions and ~300 LOC(most of that documentation). Note that there's no special function to log to the systemd log. You have to log to stdout(for example using the standard stderr.writefln()) in a specific (but simple) format. Also writing a daemon in systemd is actually a lot easier that the traditional way (see http://0pointer.de/public/systemd-man/daemon.html ), so have fun :-) -- Johannes Pfau
Nov 16 2011
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
It is not uncommon that a certain project generates several libraries.
Example: ncurses (libcurses, libpanel, libforms)

I propose each library has a one-to-one correspondent D module inside the 
deimos package. All D modules that correspond to C/C++ header files with the 
same name should reside in subdirectories.

So, say we use ncurses for an example. We whould have:

# "library" modules
/deimos/ncurses.d # -lncurses
/deimos/panel.d   # -lpanel
/deimos/form.d    # -lform
/deimos/menu.d    # -lmenu
# these are made by /usr/include/ncurses/*.h --> .d transformation
/deimos/ncurses/cursesapp.d
/deimos/ncurses/curses.d
/deimos/ncurses/cursesp.d
/deimos/ncurses/cursslk.d
/deimos/ncurses/etip.d
/deimos/ncurses/menu.d
/deimos/ncurses/ncurses_dll.d
/deimos/ncurses/panel.d
/deimos/ncurses/term_entry.d
/deimos/ncurses/tic.d
/deimos/ncurses/cursesf.d
/deimos/ncurses/cursesm.d
/deimos/ncurses/cursesw.d
/deimos/ncurses/eti.d
/deimos/ncurses/form.d
/deimos/ncurses/nc_tparm.d
/deimos/ncurses/ncurses.d
/deimos/ncurses/termcap.d
/deimos/ncurses/term.d
/deimos/ncurses/unctrl.d

Another thing to consider is the fact that if I make such hierarchy in my 
project, I will have to SYMLINK ncurses directory into my deimos/ncurses 
folder, and also have to symlink all "library" D modules...

dmd.conf should contain -I$HOME/include/d/deimos by default. :)
Nov 18 2011