Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones use
deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Say that both liblzma and ncurses have a module called "util". What
happens if I want to use both of these libraries in the same
application. When I do "import util;" which one will the compiler pick?
I suggest there is a root package named after the library. If people
want a deimos package, that's fine with me as well. But there has to be
a package named after the library where all modules should be located,
except for, possibly, a module that imports the whole library.
--
/Jacob Carlborg

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Say that both liblzma and ncurses have a module called "util". What
happens if I want to use both of these libraries in the same
application. When I do "import util;" which one will the compiler pick?
I suggest there is a root package named after the library. If people
want a deimos package, that's fine with me as well. But there has to be
a package named after the library where all modules should be located,
except for, possibly, a module that imports the whole library.

That assumes ncurses/curses.d contains "module ncurses.curses;" and
otherproject/curses.d contains "module otherproject.curses;" otherwise
there will be a conflict:
"main.d(73): Error: module test from file foo/test.d conflicts with
another module test from file bar/test.d"
This is not the case with the current ncurses bindings:
https://github.com/D-Programming-Deimos/ncurses/blob/master/curses.d
It will look weird if top level modules contain something like "module
foo.bar;" and I don't think the modules should depend on the name of the
repository.
--
/Jacob Carlborg

young Dan-Laptop:~/bin/mytest$ vim otherproject/curses.d
young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses -I/otherproject test.d
I made it so that both projects have identical module names.
"module curses;"
DMD still works it out fine if you import "ncurses.curses,
otherproject.curses;"

Does that really work? You would need to do "dmd -I." which I think dmd
does by default so in this case it actually works.

The only way that I can see you running into errors is if you insist
upon using "import curses;".

Yeah, that's what I did.

Which I do not know how you will get around that anyways, so I think I
am entirely missing your point.
...and it appears that there is an error in ncurses about unctrl.d...
=(
I showed you an example, and there were no problems.
Show me an example where there will be problems, because everything you
have told me does not seem to apply to the current situation.

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Say that both liblzma and ncurses have a module called "util". What happens if
I
want to use both of these libraries in the same application. When I do "import
util;" which one will the compiler pick?

import liblzma.util;
import ncurses.util;

I suggest there is a root package named after the library. If people want a
deimos package, that's fine with me as well. But there has to be a package
named
after the library where all modules should be located, except for, possibly, a
module that imports the whole library.

That already is so. What I objected to was:
import liblzma.D.util;
as pointless.

Say that both liblzma and ncurses have a module called "util". What
happens if I
want to use both of these libraries in the same application. When I do
"import
util;" which one will the compiler pick?

import liblzma.util;
import ncurses.util;

I suggest there is a root package named after the library. If people
want a
deimos package, that's fine with me as well. But there has to be a
package named
after the library where all modules should be located, except for,
possibly, a
module that imports the whole library.

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Say that both liblzma and ncurses have a module called "util". What
happens if I want to use both of these libraries in the same
application. When I do "import util;" which one will the compiler pick?
I suggest there is a root package named after the library. If people
want a deimos package, that's fine with me as well. But there has to be
a package named after the library where all modules should be located,
except for, possibly, a module that imports the whole library.

Hey all,
currently, the 0mq and ncurses Deimos bindings place their modules in
the root (both package- and directory-wise), while the liblzma ones
use deimos.lzma and deimos.lzma_.*.
The actual choice probably doesn't matter at all, but could we maybe
pick one and then stick to it (including appropriate documentation of
this decision, of course)? In my eyes, consistency would improve the
"Just Works"-appeal of Deimos by quite a bit.
Thanks,
David

I asked Walter about it and he preferred the modules in the root.
Another guy claimed it would lead to namespace clashes but refused to
elaborate.
There is a lot about Deimos that isn't documented.
It'll get there.

Say that both liblzma and ncurses have a module called "util". What
happens if I want to use both of these libraries in the same
application. When I do "import util;" which one will the compiler pick?
I suggest there is a root package named after the library. If people
want a deimos package, that's fine with me as well. But there has to be
a package named after the library where all modules should be located,
except for, possibly, a module that imports the whole library.

Yeah that's the exact same thing I was thinking.
Unless There is some reason that this will not work, It feels like
making a mountain out of a molehill...
It would be great if there was a standard, but either way it's
completely workable.

That assumes ncurses/curses.d contains "module ncurses.curses;" and
otherproject/curses.d contains "module otherproject.curses;" otherwise
there will be a conflict:

errors. (other than something stupid I did along the way. which I
edited out...)
both curses.d file have "module curses;"

"main.d(73): Error: module test from file foo/test.d conflicts with
another module test from file bar/test.d"
This is not the case with the current ncurses bindings:
https://github.com/D-Programming-Deimos/ncurses/blob/master/curses.d
It will look weird if top level modules contain something like "module
foo.bar;" and I don't think the modules should depend on the name of
the repository.

young Dan-Laptop:~/bin/mytest$ vim otherproject/curses.d
young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses -I/otherproject test.d
I made it so that both projects have identical module names.
"module curses;"
DMD still works it out fine if you import "ncurses.curses,
otherproject.curses;"
The only way that I can see you running into errors is if you insist
upon using "import curses;".
Which I do not know how you will get around that anyways, so I think I
am entirely missing your point.
...and it appears that there is an error in ncurses about unctrl.d...
=(
I showed you an example, and there were no problems.
Show me an example where there will be problems, because everything you
have told me does not seem to apply to the current situation.
I will fix both Deimos and ZeroMQ (and the projects I'm currently
working on) if you can give me enough information to duplicate the
problems.

We talked about this on the irc://irc.freenode.org/d IRC channel a lot...
Deimos is young and we will come up with a good solution to this issue soon.
There is a good reason for having modules in the root of deimos. (lzma is a
good example) However, the problem with that is that one can't just simply
checkout the source straight from some VCS repository into the deimos dir.
Unfortunately a symlink is a must in such case...
If, however, project is in its own folder (like I do with my old ncurses
binding), than I can simply do: cd ~/src/deimos; svn co
svn://path.to.my.server/ncurses
After this I will have a working curses package...
There are several things to be clear before Deimos becomes more popular, and
it will make people contribute more.
I only have to say that I prefer convention over configuration. - We just
simply have to decide some Deimos conventions and all authors of deimos
bindings should follow them if they want their projects to be part of the
Deimos.

It would be great if a single include statement in /etc/dmd.conf would
be enough to use all deimos projects:
-I/usr/include/d/dmd/deimos
or
-I$HOME/include/d/deimos
Then just pickup your preferated deimos projects from the website and
put them into your local deimos folder.
I suggest to consistently use deimos.libname_.modulname;
import deimos.ncurses_.termcap;
import deimos.ncurses_.cursslk;
import deimos.ncurses_.eti;
import deimos.lzma_.delta;
import deimos.lzma_.index;
import deimos.zmq_.zmq;
import deimos.zmq_.utils;
import deimos.mysql_.keycache;
import deimos.mysql_.debug;
import deimos.mysql_.embed;
...
If you are going to import _all_ modules of a deimos lib then use this
shortcut:
import deimos.ncurses;
import deimos.lzma;
import deimos.zmq;
import deimos.mysql;
...
Free for comments!
- mta`chrono

Yes. Thanks for reminding us. We discussed this as well on
irc://irc.freenode.org/d ... I absolutely agree that if Deimos is
"installed" (or mayber better say "enabled"), then dmd.conf should contain
the abovementioned include line.
About the <project_> package... It *should not* be imported directly by a
user (developer). It should be imported by the module inside the deimos
package.
So we would have:
import deimos.lzma; // imports deimos.lzma_.delta and deimos.lzma_.index
As I wrote in one of my previous posts, it should be one-to-one
correspondence between deimos modules, and libraries.
So, liblzma binding would have only one module: deimos.lzma, while ncurses
binding will have 3 (or 4): deimos.ncurses, deimos.panel, deimos.menu,
deimos.form .
Why? - Because each import will trigger a different library as well. For
deimos.ncurses you need -lncurses flag, for deimos.panel you need the -
lpanel flag for the linker, and so on.
Regards

Yes. Thanks for reminding us. We discussed this as well on
irc://irc.freenode.org/d ... I absolutely agree that if Deimos is
"installed" (or mayber better say "enabled"), then dmd.conf should contain
the abovementioned include line.

Deimos is an organization that (if it is successful) will get very large.
People
aren't going to get the whole thing any more than they get every C library
header from Ubuntu's repository.

So, the question is if Deimos considers to be 'mentor' for some of GUI
bindings which are, imho, important part of building D's ecosystem?

All Deimos is is D bindings for popular C libraries. Anything else is outside
of
its charter.
The flow chart is:
1. I want to access C library libxx from D.
2. I look for it in Deimos.
3. It's there - download it and use it.
4. It's not there - create it and submit it to Deimos.

On a second thought... Why would that be a problem? Even if hundreds of
packages are inside $HOME/include/d/deimos ??? The -I$HOME/include/d/deimos
will just inform compiler where to look for modules. Is the "-I" flag really
such an overhead? o.O

On a second thought... Why would that be a problem? Even if hundreds of
packages are inside $HOME/include/d/deimos ??? The -I$HOME/include/d/deimos
will just inform compiler where to look for modules. Is the "-I" flag really
such an overhead? o.O

No, I don't think it's any overhead. But I want this to be handled by a
package manager. I want a file that says: "this project depends on these
libraries". Then it's up to the package manager to install and make them
available for the compiler.
--
/Jacob Carlborg

Well, if you carefully read my previous post about module/package structure
(ncurses example shows the point), you would see that i proposed a module-
per-library. It is a convention over configuration approach.
If you see "import deimos.foo;" in the code, that automatically means -lfoo
in your project! It is simple, and straightforward.
Regards

No, I don't think it's any overhead. But I want this to be handled by a
package manager. I want a file that says: "this project depends on these
libraries". Then it's up to the package manager to install and make them
available for the compiler.

I think your intention to make use of a package manager is implicit
shared by Dejan.
It would be cool to provide a packet manager for windows and to have a
deimos_to_deb converter. Think of apt-get install dpl-deimos-lzma :-)...

deimos as such. At best import deimos.ncurses or import deimos.zeromq
would be everything
thats needed.

Making "import deimos.ncurses" import everything is just wrong. NCurses
consists of 13 libraries. 4 of them are the most important to the user
(developer): curses, menu, panel and form. Importing panel if you never use
NCurses panels is pointless I think. It is not a big library though...
Libs:
/usr/lib64/libcurses.so
/usr/lib64/libcursesw.so
/usr/lib64/libform.so
/usr/lib64/libformw.so
/usr/lib64/libmenu.so
/usr/lib64/libmenuw.so
/usr/lib64/libncurses.so
/usr/lib64/libncursesw.so
/usr/lib64/libpanel.so
/usr/lib64/libpanelw.so
/usr/lib64/libtermcap.so
/usr/lib64/libtic.so
/usr/lib64/libtinfo.so

Making "import deimos.ncurses" import everything is just wrong. NCurses
consists of 13 libraries. 4 of them are the most important to the user
(developer): curses, menu, panel and form. Importing panel if you never use
NCurses panels is pointless I think. It is not a big library though...
...

I think in this case "import deimos.ncurses;" should _NOT_ be available.
It's pointless, I agree in what you said. It needs to be devided into
serveral modules.
import deimos.ncurses.curses;
import deimos.ncurses.menu;
import deimos.ncurses.panel;
import deimos.ncurses.form;
--------------------------
1. smart library bindings
Those bindings that fit in a _single_ module. They consists of a single
source file and can be imported via "import deimos.libname;"
2. bigger library bindings
They _don't_ fit in a single module and therefore they provide different
modules. they can be imported via "import deimos.libname.sub1; import
deimos.libname.sub2; ..."
3. aggregation of bindings
In _some_ cases it seems to be useful if you can import _all_ modules at
once. deimos.libname.sub{i} is renamed to deimos.libname_.sub{i} and a
dummy deimos.libname is added to import them all at once.
I'm very interessted in your personal opinion. So: Free for comments :-)

I think in this case "import deimos.ncurses;" should _NOT_ be available.
It's pointless, I agree in what you said. It needs to be devided into
serveral modules.

I disagree. There is nothing wrong with "import deimos.ncurses;"
That module will import all modules (read ncurses header files), that have
to be imported so an application linked with -lncurses flag work.
deimos.ncurses is basically the core module. If developer does not need
fancy stuff, he or she will import only this module, nothing else.

It makes sense to follow that pattern and wrap up everything under
deimos.ncurses or ncurses. Having an ncurses package currently disallows
to have a ncurses module under the same path, so this is no option.

True, that is the main reason why we suggested (the IRC discussion I talked
about) to use the "name_" for library packages. This is not a big deal
because a developer will never directly import from there anyway!
Example:
import deimos.ncurses;
This import statement will trigger importing of:
deimos.ncurses_.ncurses_h; // i name header file translations like: file.h -

file_h.d

This is, ofcoruse, just a suggestion. If there are better ways, please share
with us. :)
Regards

On a second thought... Why would that be a problem? Even if hundreds of
packages are inside $HOME/include/d/deimos ??? The -I$HOME/include/d/deimos
will just inform compiler where to look for modules. Is the "-I" flag really
such an overhead? o.O

On a second thought... Why would that be a problem? Even if hundreds of
packages are inside $HOME/include/d/deimos ??? The
-I$HOME/include/d/deimos
will just inform compiler where to look for modules. Is the "-I" flag
really
such an overhead? o.O

No, I don't think it's any overhead. But I want this to be handled by a
package manager. I want a file that says: "this project depends on these
libraries". Then it's up to the package manager to install and make them
available for the compiler.

That's the decision to be made. I'd personally prefer a library/package
approach for
deimos as such. At best import deimos.ncurses or import deimos.zeromq
would be everything
thats needed.
OTOH the D-Programming-Deimos is already suggesting to rather use a
package per binding approach
and if people wanted to distribute additional files it'd be the only
sensible choice.
Still I think this will loose some consistency.
By the way, how have you settled to request for adding a repository?
martin

If you are going to import _all_ modules of a deimos lib then use
this shortcut:
import deimos.ncurses; import deimos.lzma; import deimos.zmq;
import deimos.mysql;
...
Free for comments!
- mta`chrono

ncurses already has a file 'ncurses' which is just a symlink to curses.
It would be weird to have 'import deimos.ncurses' which imports
everything, and 'import deimos.ncurses.ncurses' which imports a single
file.
It's not how things are currently done(I don't think) and it would be
weird... It would seem to require a revamping of how imports are
currently done(which has actually been suggested) or including extra
files which aren't there in the C versions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOyrXhAAoJENcHIWLyQiSlEvUH/1CakOerm+Ar0YaYQouCKk/g
cnS8o3QTZR1cKXbl1Voxm/EzDSRkHbo0Qu396HrIS+r8W9Hs5ZzMtwdnKM+wS5+c
26RITKTlHPEk/Ym4sccWWhGCsBWCa7+TtK8J7/1Vz8j2BaNBMNJ3M5mZbw0+f/Qd
I+fEI+l43IltgI0hzdZaD1oCe9DpbG12XaPH3EIzU1FdT5s7Ac1xpxcZ6zll7BL3
WTg8KsE8bhvktQW9ZfDIRg/GGlOPpQSPjXLId02XA2M3m2maCFiiSDo6xntbOpvt
Irj9AFnFnPCnKtFZvsOPdEo/RZ8o584EUt0P08TYxLcbTcYPvzuNeeZBUyaQZS4=
=OD6B
-----END PGP SIGNATURE-----

Making "import deimos.ncurses" import everything is just wrong. NCurses
consists of 13 libraries. 4 of them are the most important to the user
(developer): curses, menu, panel and form. Importing panel if you never
use
NCurses panels is pointless I think. It is not a big library though...
...

I think in this case "import deimos.ncurses;" should _NOT_ be available.
It's pointless, I agree in what you said. It needs to be devided into
serveral modules.
import deimos.ncurses.curses;
import deimos.ncurses.menu;
import deimos.ncurses.panel;
import deimos.ncurses.form;

ncurses.h -> curses.h
curses.h | basic header
panel.h | includes curses.h
form.h | includes curses.h and eti.h
It makes sense to follow that pattern and wrap up everything under
deimos.ncurses or ncurses. Having an ncurses package currently disallows
to have a ncurses module under the same path, so this is no option.
martin

--------------------------
1. smart library bindings
Those bindings that fit in a _single_ module. They consists of a single
source file and can be imported via "import deimos.libname;"
2. bigger library bindings
They _don't_ fit in a single module and therefore they provide different
modules. they can be imported via "import deimos.libname.sub1; import
deimos.libname.sub2; ..."
3. aggregation of bindings
In _some_ cases it seems to be useful if you can import _all_ modules at
once. deimos.libname.sub{i} is renamed to deimos.libname_.sub{i} and a
dummy deimos.libname is added to import them all at once.
I'm very interessted in your personal opinion. So: Free for comments :-)

It makes sense to follow that pattern and wrap up everything under
deimos.ncurses or ncurses. Having an ncurses package currently disallows
to have a ncurses module under the same path, so this is no option.

True, that is the main reason why we suggested (the IRC discussion I
talked
about) to use the "name_" for library packages. This is not a big deal
because a developer will never directly import from there anyway!
Example:
import deimos.ncurses;
This import statement will trigger importing of:
deimos.ncurses_.ncurses_h; // i name header file translations like:
file.h -

file_h.d

This is, ofcoruse, just a suggestion. If there are better ways, please
share
with us. :)
Regards

Deimos is an organization that (if it is successful) will get very
large. People aren't going to get the whole thing any more than they
get every C library header from Ubuntu's repository.

We're strongly reconsidering to use D - this time using gtk+ or
wxwidgets bindings. The former is in a relatively good shape, but we're
not sure about the latter.
So, the question is if Deimos considers to be 'mentor' for some of GUI
bindings which are, imho, important part of building D's ecosystem?
Those are maybe not according to the manifesto, but play important role
for wider adoption of D.
Sincerely,
Gour
--=20
In this endeavor there is no loss or diminution,=20
and a little advancement on this path can protect=20
one from the most dangerous type of fear.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

All Deimos is is D bindings for popular C libraries. Anything else is
outside of its charter.

OK. Then I hope Sqlite3 applies?
Sincerely,
Gour
--=20
The embodied soul may be restricted from sense enjoyment,=20
though the taste for sense objects remains. But, ceasing=20
such engagements by experiencing a higher taste,=20
he is fixed in consciousness.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810