On Monday, October 17, 2011 17:09 so wrote:
> With D being binary compatible with C, i don't know why we worry on such
> things.
> Wasn't being able to access C libraries the point? If it wasn't, what is
> the worthwhile point for this constraint?
> Wouldn't (sorry for the poor horse) separate compilers solve the most
> problems (if not all) we face on these issues?
> C never changes and every compiler vendor have an implementation.
> 
> --
> import anyapi; // anyapi would be a D module or a C header (anyapi.h...)
> in directory paths.
> --
> 
> Structs are pod in both languages.
> Matching of the standard types is something we can take care of with
> documentation (RTFM)
> and with compiler errors generated (when we call functions from the other
> language).
> 
> Sorry once again if this should sound stupid or impossible to implement (if so, someone please enlighten me), it probably is because everytime we open this discussion i feel i am the only one seeing the big picture, the potential of D.

The problem is that for C code to be usable in D code, the C declarations must be redone in D, since D can't just include header files. Translating C header files to D is a pain and time consuming, and it would benefit us all to have a place to go to find common C headers translated to D so that such work doesn't have to be duplicated. Hence CAPI has been proposed. And if we're going to have it, it also benefits us to be organized about how we lay it out. Programmers can name modules in their code whatever they want, but being organized about how modules are named and laid out in a large project such as this makes it much easier to maintain and find what you want in it.

- Jonathan M Davis

"so" <so@so.so> wrote in message news:op.v3itelnbmpw3zg@localhost.localdomain...
> With D being binary compatible with C, i don't know why we worry on such
> things.
> Wasn't being able to access C libraries the point? If it wasn't, what is
> the worthwhile point for this constraint?
> Wouldn't (sorry for the poor horse) separate compilers solve the most
> problems (if not all) we face on these issues?
> C never changes and every compiler vendor have an implementation.
>
> --
> import anyapi; // anyapi would be a D module or a C header (anyapi.h...) in directory paths.
> --
>

Thats would mean that every D compiler would have to *also* be a C compiler.

On Tue, 18 Oct 2011 03:52:13 +0300, Nick Sabalausky <a@a.a> wrote:

> Thats would mean that every D compiler would have to *also* be a C compiler.

Indeed, but i see nothing wrong with it, like i see nothing wrong with inline asm, C never changes,

On Tue, 18 Oct 2011 03:32:17 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:


> The problem is that for C code to be usable in D code, the C declarations must
> be redone in D, since D can't just include header files.

I don't understand why.

> Translating C header
> files to D is a pain and time consuming, and it would benefit us all to have a
> place to go to find common C headers translated to D so that such work doesn't
> have to be duplicated.

With the second compiler, there won't be any need for us to do anything, like C++ we could use C libraries seamlessly.

On 10/17/2011 4:04 PM, Peter Alexander wrote:
> int FOO()(int x) { return bar(x + 1); }
>
> would probably work better :-)

:-)

On 10/17/2011 5:56 PM, so wrote:
> On Tue, 18 Oct 2011 03:52:13 +0300, Nick Sabalausky <a@a.a> wrote:
>
>> Thats would mean that every D compiler would have to *also* be a C compiler.
>
> Indeed, but i see nothing wrong with it, like i see nothing wrong with inline
> asm, C never changes,

While C code can be directly translated to D, the C macros are another matter.

On 10/17/2011 12:42 AM, Jacob Carlborg wrote:
> Already working on a package manager for D:
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
> https://github.com/jacob-carlborg/orbit/


Is it possible (and worthwhile) to layer a package manager over a github repository?

Walter Bright wrote:

> On 10/17/2011 12:42 AM, Jacob Carlborg wrote:
>> Already working on a package manager for D:
>>
>> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D https://github.com/jacob-carlborg/orbit/
> 
> 
> Is it possible (and worthwhile) to layer a package manager over a github
> repository?

Yes, pip (for python) can do it.

Am 18.10.2011, 07:26 Uhr, schrieb Walter Bright <newshound2@digitalmars.com>:

> On 10/17/2011 12:42 AM, Jacob Carlborg wrote:
>> Already working on a package manager for D:
>>
>> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>> https://github.com/jacob-carlborg/orbit/
>
>
> Is it possible (and worthwhile) to layer a package manager over a github repository?

All package managers have to store their packages in some sort of repository. It's more like it solves Jacob's problem where to upload the files now that you proposed CAPI :)

On Mon, Oct 17, 2011 at 11:46 PM, Lutger Blijdestijn < lutger.blijdestijn@gmail.com> wrote:

> Walter Bright wrote:
>
> > On 10/17/2011 12:42 AM, Jacob Carlborg wrote:
> >> Already working on a package manager for D:
> >>
> >>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
> >> https://github.com/jacob-carlborg/orbit/
> >
> >
> > Is it possible (and worthwhile) to layer a package manager over a github
> > repository?
>
> Yes, pip (for python) can do it.
>

Homebrew[1] does too.  It's rather slick actually.  You can type "brew edit <package>" and it'll open the script it uses to install that package (typically just a configure and make install) in an editor.  You make your changes and save and it saves to a local git clone of the "formulas" (package installation scripts).  If you have a shared development environment you can share this modified repository among your developers so everyone is working with the same packages.  It's design is rather clever and makes full use of DVCSes.

Regards,
Brad Anderson

[1] http://mxcl.github.com/homebrew/