On 2011-10-18 07:26, 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?

I'm planning to support github repositories as packages. Have a look at "Source Code Management":

https://github.com/jacob-carlborg/orbit/wiki/integration

-- 
/Jacob Carlborg

On 10/17/2011 11:40 PM, Jacob Carlborg wrote:
> On 2011-10-18 07:26, Walter Bright wrote:
>> Is it possible (and worthwhile) to layer a package manager over a github
>> repository?
>
> I'm planning to support github repositories as packages. Have a look at "Source
> Code Management":
>
> https://github.com/jacob-carlborg/orbit/wiki/integration


Great!

"so" <so@so.so> wrote in message news:op.v3ivsvb8mpw3zg@localhost.localdomain...
> On Tue, 18 Oct 2011 03:32:17 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> 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.

The only reason C++ is able to do that is because C++ (realistically, even if not *technically*) is a proper superset of C. D isn't.

On Tue, 18 Oct 2011 06:01:37 +0300, Walter Bright <newshound2@digitalmars.com> wrote:

> 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.

You are right, i forgot about macros, Is it only this or is there anything else?

On Thu, 20 Oct 2011 00:26:58 +0300, Nick Sabalausky <a@a.a> wrote:

> "so" <so@so.so> wrote in message
> news:op.v3ivsvb8mpw3zg@localhost.localdomain...
>> On Tue, 18 Oct 2011 03:32:17 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
>> wrote:
>>
>>> 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.
>
> The only reason C++ is able to do that is because C++ (realistically, even
> if not *technically*) is a proper superset of C. D isn't.

Right, but more importantly it is ABI compatible which is what D also has, this opens some doors.
For most C libraries if you exclude macros, you just fill structs, and call functions.

That's ALL you can do in C. fill structs and call functions
(fundamental type manipulation doesn't count).
My personal research shows the following use cases of C macros (sorted
by popularity in descending order):
1. enum
2. alias (most notably, conditionally compiled ones)
3. CTFE function
4. mixin template
5. syntactic alias
6. syntactic mixin template

only the last 2 out of 6 cannot be translated to D.
An example of a syntactic alias is this very common piece of C code:
#ifdef __VERY_VERY_OLD_C_COMPILER__
    #define CONST
#else
    #define CONST const
#endif

An example of a syntactic mixin template is this piece of code, which
i never actually saw anywhere (possible only in C99 and C++):
#define N_TIMES(n) for(int i = 0; i != n; ++i)

The last use case is very rare. The only legitimate example i ever saw
is in libjpeg, where a macro is used to define function pointers of
API functions.
The use case before that is mostly used for portability reasons, which
is not necessary in D.
Some non-standard extension encapsulating macros are almost always
used in C libraries, which can be removed altogether.

The translation can go on regarding the above use cases and the last two cases can be evaluated in-line, commented out and warned about for manual translation.

On Fri, Oct 21, 2011 at 11:48 AM, so <so@so.so> wrote:
> On Thu, 20 Oct 2011 00:26:58 +0300, Nick Sabalausky <a@a.a> wrote:
>
>> "so" <so@so.so> wrote in message news:op.v3ivsvb8mpw3zg@localhost.localdomain...
>>>
>>> On Tue, 18 Oct 2011 03:32:17 +0300, Jonathan M Davis
>>> <jmdavisProg@gmx.com>
>>> wrote:
>>>
>>>> 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.
>>
>> The only reason C++ is able to do that is because C++ (realistically, even if not *technically*) is a proper superset of C. D isn't.
>
> Right, but more importantly it is ABI compatible which is what D also has,
> this opens some doors.
> For most C libraries if you exclude macros, you just fill structs, and call
> functions.
>

Indeed, macros is a language in itself.
Then again it all boils down to type manipulation and function calls.
Not sure if it is doable but a special operator like "__cmacro" might be an answer.

#define FUN(a, b) ....
#define DATA ....

could be accessed like:

__cmacro(FUN, a, b);
__cmacro(DATA);

I am pushing this because the outcome well worths all these ugly hacks.

On Fri, 21 Oct 2011 11:32:32 +0300, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> That's ALL you can do in C. fill structs and call functions
> (fundamental type manipulation doesn't count).
> My personal research shows the following use cases of C macros (sorted
> by popularity in descending order):
> 1. enum
> 2. alias (most notably, conditionally compiled ones)
> 3. CTFE function
> 4. mixin template
> 5. syntactic alias
> 6. syntactic mixin template
>
> only the last 2 out of 6 cannot be translated to D.
> An example of a syntactic alias is this very common piece of C code:
> #ifdef __VERY_VERY_OLD_C_COMPILER__
>     #define CONST
> #else
>     #define CONST const
> #endif
>
> An example of a syntactic mixin template is this piece of code, which
> i never actually saw anywhere (possible only in C99 and C++):
> #define N_TIMES(n) for(int i = 0; i != n; ++i)
>
> The last use case is very rare. The only legitimate example i ever saw
> is in libjpeg, where a macro is used to define function pointers of
> API functions.
> The use case before that is mostly used for portability reasons, which
> is not necessary in D.
> Some non-standard extension encapsulating macros are almost always
> used in C libraries, which can be removed altogether.
>
> The translation can go on regarding the above use cases and the last
> two cases can be evaluated in-line, commented out and warned about for
> manual translation.

This will defeat the philosophy of D, which stands for core
correctness, simplicity, maintainability and flexibility.
A much better solution would be to implement the AST macros, which
were discussed in a video-talk a long time ago by Walter and Andrei,
for which the macro keyword was reserved.
After that, all C macros will be translatable.

On Fri, Oct 21, 2011 at 2:17 PM, so <so@so.so> wrote:
> Indeed, macros is a language in itself.
> Then again it all boils down to type manipulation and function calls.
> Not sure if it is doable but a special operator like "__cmacro" might be an
> answer.
>
> #define FUN(a, b) ....
> #define DATA ....
>
> could be accessed like:
>
> __cmacro(FUN, a, b);
> __cmacro(DATA);
>
> I am pushing this because the outcome well worths all these ugly hacks.
>
> On Fri, 21 Oct 2011 11:32:32 +0300, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>
>> That's ALL you can do in C. fill structs and call functions
>> (fundamental type manipulation doesn't count).
>> My personal research shows the following use cases of C macros (sorted
>> by popularity in descending order):
>> 1. enum
>> 2. alias (most notably, conditionally compiled ones)
>> 3. CTFE function
>> 4. mixin template
>> 5. syntactic alias
>> 6. syntactic mixin template
>>
>> only the last 2 out of 6 cannot be translated to D.
>> An example of a syntactic alias is this very common piece of C code:
>> #ifdef __VERY_VERY_OLD_C_COMPILER__
>>    #define CONST
>> #else
>>    #define CONST const
>> #endif
>>
>> An example of a syntactic mixin template is this piece of code, which
>> i never actually saw anywhere (possible only in C99 and C++):
>> #define N_TIMES(n) for(int i = 0; i != n; ++i)
>>
>> The last use case is very rare. The only legitimate example i ever saw
>> is in libjpeg, where a macro is used to define function pointers of
>> API functions.
>> The use case before that is mostly used for portability reasons, which
>> is not necessary in D.
>> Some non-standard extension encapsulating macros are almost always
>> used in C libraries, which can be removed altogether.
>>
>> The translation can go on regarding the above use cases and the last two cases can be evaluated in-line, commented out and warned about for manual translation.
>

On 2011-10-21 10:32, Gor Gyolchanyan wrote:
> That's ALL you can do in C. fill structs and call functions
> (fundamental type manipulation doesn't count).
> My personal research shows the following use cases of C macros (sorted
> by popularity in descending order):
> 1. enum
> 2. alias (most notably, conditionally compiled ones)
> 3. CTFE function
> 4. mixin template
> 5. syntactic alias
> 6. syntactic mixin template

I guess it's quite difficult for a compiler to recognize the differences between these use cases.

> only the last 2 out of 6 cannot be translated to D.
> An example of a syntactic alias is this very common piece of C code:
> #ifdef __VERY_VERY_OLD_C_COMPILER__
>      #define CONST
> #else
>      #define CONST const
> #endif
>
> An example of a syntactic mixin template is this piece of code, which
> i never actually saw anywhere (possible only in C99 and C++):
> #define N_TIMES(n) for(int i = 0; i != n; ++i)
>
> The last use case is very rare. The only legitimate example i ever saw
> is in libjpeg, where a macro is used to define function pointers of
> API functions.
> The use case before that is mostly used for portability reasons, which
> is not necessary in D.
> Some non-standard extension encapsulating macros are almost always
> used in C libraries, which can be removed altogether.
>
> The translation can go on regarding the above use cases and the last
> two cases can be evaluated in-line, commented out and warned about for
> manual translation.

Something similar is used in the Boost library for its "foreach" macro.

-- 
/Jacob Carlborg

> I guess it's quite difficult for a compiler to recognize the differences between these use cases.

Well, that's because C macros suck big-time.
I don't see any other solution to the C-to-D translation problem.