digitalmars.D.announce - [deimos] [tutorial] [rfc] How to set up a git repository to
- Johannes Pfau (14/14) Nov 11 2011 This explains a special repository setup which allows to merge changes
- mta`chrono (13/13) Nov 11 2011 Hey Johannes,
- Johannes Pfau (14/27) Nov 12 2011 Hi,
- Johannes Pfau (7/37) Nov 12 2011 Scratch that, turns out the headers are actually in a systemd folder.
- Dejan Lekic (3/8) Nov 16 2011 You are my hero for making binding to systemd! \o/
- Johannes Pfau (13/21) Nov 16 2011 It's ready to be used:
- Dejan Lekic (3/7) Nov 18 2011 Sure it is easier, but less portable. :) Systemd is going to be very nic...
- Andrej Mitrovic (28/28) Nov 11 2011 It seems to me that people already use arbitrary ways of naming
- Johannes Pfau (25/53) Nov 12 2011 Well, once the first project is added to deimos, we'll have some kind
- mta`chrono (53/63) Nov 12 2011 Sorry, that I've to say that, but I think this is crap. A very different
- Dejan Lekic (2/2) Nov 15 2011 I believe once Deimos will mature in time, especially if all authors of
- Brad Anderson (7/21) Nov 11 2011 When I first saw you making a branch for the c headers I kind of scoffed...
- Jesse Phillips (3/18) Nov 11 2011 Nice, I've tried to figure out how to get this behavior in the past, but...
- Vladimir Panteleev (7/10) Nov 12 2011 For the screenshots, you have used a 3rd-party GUI which is only availab...
- Dejan Lekic (4/15) Nov 15 2011 I do not use Giggle and I understood all those screenshots. All git gui
- Dejan Lekic (2/17) Nov 15 2011 Brilliant! Thanks for that, Johannes! :)
- Dejan Lekic (36/36) Nov 18 2011 It is not uncommon that a certain project generates several libraries.
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
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
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`chronoHi, 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
Johannes Pfau wrote:mta`chrono 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 ;-)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`chronoHi, 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
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
Dejan Lekic wrote:Johannes Pfau wrote: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 PfauScratch 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
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
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
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.dWell, 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
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
I believe once Deimos will mature in time, especially if all authors of Deimos projects gather around and do some organisation...
Nov 15 2011
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 PfauWhen I first saw you making a branch for the c headers I kind of scoffed a 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
Nov 11 2011
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
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
Vladimir Panteleev wrote:On Fri, 11 Nov 2011 22:43:18 +0200, Johannes Pfau <spam example.com> wrote: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.(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.
Nov 15 2011
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
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: /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