www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deimos: Consistent structure?

reply David Nadlinger <see klickverbot.at> writes:
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
Nov 20 2011
next sibling parent reply Jude Young <10equals2 gmail.com> writes:
On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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.
Nov 20 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-20 22:52, Jude Young wrote:

 On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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
Nov 20 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 21, 2011 08:31:32 Jacob Carlborg wrote:

 On 2011-11-20 22:52, Jude Young wrote:

 On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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.


I completely agree.

- Jonathan M Davis
Nov 20 2011
prev sibling next sibling parent reply Kapps <Kapps NotValidEmail.com> writes:
This seems the obvious choice to me. Something like "import 
ncurses.util" seems natural and, well, package based.

On 21/11/2011 1:31 AM, Jacob Carlborg wrote:

 On 2011-11-20 22:52, Jude Young wrote:

 On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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.
Nov 20 2011
parent reply Jude Young <10equals2 gmail.com> writes:
On Mon 21 Nov 2011 01:42:54 AM CST, Kapps wrote:

 This seems the obvious choice to me. Something like "import
 ncurses.util" seems natural and, well, package based.

 On 21/11/2011 1:31 AM, Jacob Carlborg wrote:

 On 2011-11-20 22:52, Jude Young wrote:

 On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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.
Nov 20 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 08:56, Jude Young wrote:

 On Mon 21 Nov 2011 01:42:54 AM CST, Kapps wrote:

 This seems the obvious choice to me. Something like "import
 ncurses.util" seems natural and, well, package based.


 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 will work, all modules at the top without a root package will NOT 
work, as far as I know. It's important to get it right.


 It would be great if there was a standard, but either way it's
 completely workable.


No, it's not workable to have all modules at the top without root package.

-- 
/Jacob Carlborg
Nov 21 2011
next sibling parent reply Jude Young <10equals2 gmail.com> writes:
young Dan-Laptop:~/bin$ mkdir mytest
young Dan-Laptop:~/bin$ cd mytest/
young Dan-Laptop:~/bin/mytest$ git clone 
git://github.com/D-Programming-Deimos/ncurses
Cloning into 'ncurses'...
remote: Counting objects: 99, done.
remote: Compressing objects: 100% (66/66), done.
remote: Total 99 (delta 44), reused 86 (delta 31)
Receiving objects: 100% (99/99), 73.24 KiB, done.
Resolving deltas: 100% (44/44), done.
young Dan-Laptop:~/bin/mytest$ l
ncurses/
young Dan-Laptop:~/bin/mytest$ touch test.d
young Dan-Laptop:~/bin/mytest$ l
ncurses/  test.d
young Dan-Laptop:~/bin/mytest$ vim test.d
young Dan-Laptop:~/bin/mytest$ mkdir otherproject
young Dan-Laptop:~/bin/mytest$ touch otherproject/curses.d
young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses test.d
young Dan-Laptop:~/bin/mytest$ ./test
I didn't bother to actually use the files compile-time will sort that 
outl.
young Dan-Laptop:~/bin/mytest$ 



Yes DMD will try to compile blank files, yes 'test.d' had the exact 
phrase "import ncurses.curses;"

since git will automatically create the folder 'ncurses' when you clone 
the project, that acts as the root package.
What is wrong with this?

If I'm missing something, please tell me.
Nov 21 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 09:41, Jude Young wrote:

 young Dan-Laptop:~/bin$ mkdir mytest
 young Dan-Laptop:~/bin$ cd mytest/
 young Dan-Laptop:~/bin/mytest$ git clone
 git://github.com/D-Programming-Deimos/ncurses
 Cloning into 'ncurses'...
 remote: Counting objects: 99, done.
 remote: Compressing objects: 100% (66/66), done.
 remote: Total 99 (delta 44), reused 86 (delta 31)
 Receiving objects: 100% (99/99), 73.24 KiB, done.
 Resolving deltas: 100% (44/44), done.
 young Dan-Laptop:~/bin/mytest$ l
 ncurses/
 young Dan-Laptop:~/bin/mytest$ touch test.d
 young Dan-Laptop:~/bin/mytest$ l
 ncurses/  test.d
 young Dan-Laptop:~/bin/mytest$ vim test.d
 young Dan-Laptop:~/bin/mytest$ mkdir otherproject
 young Dan-Laptop:~/bin/mytest$ touch otherproject/curses.d
 young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses test.d
 young Dan-Laptop:~/bin/mytest$ ./test
 I didn't bother to actually use the files compile-time will sort that
 outl.
 young Dan-Laptop:~/bin/mytest$



 Yes DMD will try to compile blank files, yes 'test.d' had the exact
 phrase "import ncurses.curses;"

 since git will automatically create the folder 'ncurses' when you clone
 the project, that acts as the root package.
 What is wrong with this?

 If I'm missing something, please tell me.


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
Nov 21 2011
parent reply Jude Young <10equals2 gmail.com> writes:
On Mon 21 Nov 2011 03:06:56 AM CST, Jacob Carlborg wrote:

 On 2011-11-21 09:41, Jude Young wrote:

 young Dan-Laptop:~/bin$ mkdir mytest
 young Dan-Laptop:~/bin$ cd mytest/
 young Dan-Laptop:~/bin/mytest$ git clone
 git://github.com/D-Programming-Deimos/ncurses
 Cloning into 'ncurses'...
 remote: Counting objects: 99, done.
 remote: Compressing objects: 100% (66/66), done.
 remote: Total 99 (delta 44), reused 86 (delta 31)
 Receiving objects: 100% (99/99), 73.24 KiB, done.
 Resolving deltas: 100% (44/44), done.
 young Dan-Laptop:~/bin/mytest$ l
 ncurses/
 young Dan-Laptop:~/bin/mytest$ touch test.d
 young Dan-Laptop:~/bin/mytest$ l
 ncurses/  test.d
 young Dan-Laptop:~/bin/mytest$ vim test.d
 young Dan-Laptop:~/bin/mytest$ mkdir otherproject
 young Dan-Laptop:~/bin/mytest$ touch otherproject/curses.d
 young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses test.d
 young Dan-Laptop:~/bin/mytest$ ./test
 I didn't bother to actually use the files compile-time will sort that
 outl.
 young Dan-Laptop:~/bin/mytest$



 Yes DMD will try to compile blank files, yes 'test.d' had the exact
 phrase "import ncurses.curses;"

 since git will automatically create the folder 'ncurses' when you clone
 the project, that acts as the root package.
 What is wrong with this?

 If I'm missing something, please tell me.


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


False.  I actually ran the test that I showed you and encountered no 
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.
Nov 21 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-21 10:30, Jude Young wrote:

 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.


jacob des-051 ~/development/d/foobar$ ls
lib    main.d
jacob des-051 ~/development/d/foobar$ cat main.d
module main;

import foo.test;
import bar.test;

void main ()
{
	
}jacob des-051 ~/development/d/foobar$ cd lib/
jacob des-051 ~/development/d/foobar/lib$ ls
bar foo
jacob des-051 ~/development/d/foobar/lib$ cd bar/
jacob des-051 ~/development/d/foobar/lib/bar$ cat test.d
module test;jacob des-051 ~/development/d/foobar/lib/bar$ cd ../foo/
jacob des-051 ~/development/d/foobar/lib/foo$ cat test.d
module test;jacob des-051 ~/development/d/foobar/lib/foo$ cd ../../
jacob des-051 ~/development/d/foobar$ dmd main.d -I./lib/foo -I./lib/bar
main.d(3): Error: module test is in file 'foo/test.d' which cannot be read
import path[0] = ./lib/foo
import path[1] = ./lib/bar
import path[2] = /Users/jacob/.dvm/compilers/dmd-1.070/bin/../import
jacob des-051 ~/development/d/foobar$ dmd main.d -I./lib
main.d(4): Error: module test from file ./lib/bar/test.d conflicts with 
another module test from file ./lib/foo/test.d
jacob des-051 ~/development/d/foobar$

If I change both test files to include the package, e.g. "module 
foo.test;" and "module bar.test;" it works. But in that case I have to 
add the whole "lib" to the include path, which I may not want to. Then I 
have to manually put the projects in their own directories.


 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.


It's just weird if the module and import declarations doesn't match, 
i.e. "module curses;" and "import ncurses.curses;".

-- 
/Jacob Carlborg
Nov 21 2011
prev sibling parent Jude Young <10equals2 gmail.com> writes:
young Dan-Laptop:~/bin/mytest$ dmd -I/ncurses -I/otherproject test.d

I'm retarded.  Still works
Nov 21 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2011 11:31 PM, Jacob Carlborg wrote:

 On 2011-11-20 22:52, Jude Young wrote:

 On Sun 20 Nov 2011 02:20:18 PM CST, David Nadlinger wrote:

 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.
Nov 21 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 20:14, Walter Bright wrote:

 On 11/20/2011 11:31 PM, Jacob Carlborg wrote:

 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:


No it's not. Have a look at the curses module in the ncurses repository.

https://github.com/D-Programming-Deimos/ncurses/blob/master/curses.d

It has the following module declaration: "module curses;", which means 
it will conflict with any other library the has a module with the same name.


 import liblzma.D.util;

 as pointless.


Yeah, that D package won't to anything good.

-- 
/Jacob Carlborg
Nov 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2011 12:13 PM, Jacob Carlborg wrote:

 https://github.com/D-Programming-Deimos/ncurses/blob/master/curses.d

 It has the following module declaration: "module curses;", which means it will
 conflict with any other library the has a module with the same name.


Yeah, that should be fixed.
Nov 21 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 22:12, Walter Bright wrote:

 On 11/21/2011 12:13 PM, Jacob Carlborg wrote:

 https://github.com/D-Programming-Deimos/ncurses/blob/master/curses.d

 It has the following module declaration: "module curses;", which means
 it will
 conflict with any other library the has a module with the same name.


 Yeah, that should be fixed.


Yes, thank you. Finally someone understands :)

-- 
/Jacob Carlborg
Nov 21 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Jacob, if you read my previous posts you will see that I proposed exactly 
what you talked about... :)
Nov 22 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-11-22 10:58, Dejan Lekic wrote:

 Jacob, if you read my previous posts you will see that I proposed exactly
 what you talked about... :)


Maybe, there was something I didn't like with your proposal if I recall 
correctly.

-- 
/Jacob Carlborg
Nov 22 2011
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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.
Nov 21 2011
parent reply mta`chrono <chrono mta-international.net> writes:
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
Nov 21 2011
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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
Nov 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2011 7:05 AM, Dejan Lekic wrote:

 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.
Nov 21 2011
parent reply Gour <gour atmarama.net> writes:
On Mon, 21 Nov 2011 11:21:37 -0800
Walter Bright <newshound2 digitalmars.com> wrote:


 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
Nov 21 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2011 11:32 AM, Gour wrote:

 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.
Nov 21 2011
parent Gour <gour atmarama.net> writes:
On Mon, 21 Nov 2011 12:00:26 -0800
Walter Bright <newshound2 digitalmars.com> wrote:


 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
Nov 23 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 15:54, mta`chrono wrote:

 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


I don't like this. It will include modules that one may not have any use 
for. It may also make it more complicated for a package manager.

-- 
/Jacob Carlborg
Nov 21 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Good point Jacob. I did not think about that possibility. Especially if 
Deimios grows big...
Nov 21 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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
Nov 21 2011
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Good point. D's imports are nothing like C's includes, which
dramatically slow down compilation if their numbers grow beyond 3
digits.

On Mon, Nov 21, 2011 at 8:58 PM, Dejan Lekic <dejan.lekic gmail.com> wrote:

 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
Nov 21 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-21 17:58, Dejan Lekic wrote:

 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
Nov 21 2011
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
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
Nov 21 2011
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Mon, 21 Nov 2011 18:27:42 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-11-21 17:58, Dejan Lekic wrote:

 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
Nov 21 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
 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
Nov 22 2011
parent reply mta`chrono <chrono mta-international.net> writes:
 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 :-)
Nov 22 2011
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
 
 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.
Nov 22 2011
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 22 Nov 2011 13:00:31 +0100, mta`chrono  
<chrono mta-international.net> wrote:


 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;


 From /usr/include:
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 :-)
Nov 22 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
 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


(and probably termcap_h.d too)

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

Regards
Nov 22 2011
parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 22 Nov 2011 17:38:43 +0100, Dejan Lekic <dejan.lekic gmail.com>  
wrote:


 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


 (and probably termcap_h.d too)

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

 Regards


Well, implementing
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP13
and something in the direction of
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP15
;).

I spend some time thinking about a good import structure for deimos
and somehow couldn't find a good fit.
Reflecting /usr/include or /usr/local/include would be a plain and simple  
convention
but that doesn't pair with individual repositories.
Nov 22 2011
prev sibling parent mta`chrono <chrono mta-international.net> writes:
 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 :-)...
Nov 21 2011
prev sibling parent Jude Young <10equals2 gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


 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
 


Not always gonna work.
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-----
Nov 21 2011