Jump to page: 1 2
Thread overview
Project ideas - looking for more contributors
Jun 06, 2014
Kai Nacke
Jun 06, 2014
David Nadlinger
Jun 10, 2014
Kai Nacke
Jun 08, 2014
Dan Olson
Jun 08, 2014
Dicebot
Jun 09, 2014
David Nadlinger
Jun 11, 2014
Kai Nacke
Jun 12, 2014
Daniel Murphy
Jun 12, 2014
Temtaime
Jun 13, 2014
Kai Nacke
Jun 14, 2014
Frank Like
Jun 16, 2014
Kai Nacke
June 06, 2014
Hi all!

LDC is a community effort. All kinds of contributions are welcome!!! This is a great way to speed up development and increase quality of LDC!

But how to start? Well, Ian (from GDC project) told everybody that compiler construction is no rocket science. Yes, that's true! Here are some ideas to start with:

* First, report all bugs you find. Just make sure that it is a genuine LDC bug (e.g. not a frontend problem which is solved in an upcoming DMD version) and provide a nice test case.

* Build LDC from source. Improve the build instructions if you find inaccuracies or tell us about build problems.

* In general improve the wiki pages at http://wiki.dlang.org/LDC

* Maybe you want to get some dirty hands? Just look at the reported issues (https://github.com/ldc-developers/ldc/issues/) and fire up your debugger. It is quite easy to understand LDC source just be single stepping through some functions.

* Implement some missing feature, e.g. support for @ldc.attribute.

If you really dislike C++ then there are still areas which need help:

* Implement shared library support on Linux. The basic infrastructure is in place but still needs some cleanup.

* Port LDC to a new environment. E.g. LDC itself compiles on Solaris 11 but misses some files in druntime and phobos. Or try LDC on OpenBSD, NetBSD, Plan 9, ....

* Translate ldmd2 to D. This would be a great start to eat our own dog food.

* Provide a D module replacing libconfig. This would help in transition of LDC to D.

* The CMake scripts can be improved in various way. Just look up the related issues.

If you provide a pull request then you should have a look at the CI servers https://travis-ci.org/ldc-developers/ldc/ and http://ci.lycus.org/job/LDC/
to identify possible problems.

And don't hesitate to ask your questions here in the newsgroup!

Regards,
Kai
June 06, 2014
On 6 Jun 2014, at 18:54, Kai Nacke via digitalmars-d-ldc wrote:
> Well, Ian (from GDC project) told everybody that compiler construction is no rocket science.

Actually, that was me, and I'm very much not from the GDC project. ;)

Best,
David
June 08, 2014
"Kai Nacke" <kai@redstar.de> writes:

> * Port LDC to a new environment. E.g. LDC itself compiles on Solaris 11 but misses some files in druntime and phobos. Or try LDC on OpenBSD, NetBSD, Plan 9, ....

I bet any of the BSD family might be fairly easy for any who wants to try, especially if clang/LLVM already is well supported.  DragonFly BSD is another one.  Could be instant gratification for someone.

> * Translate ldmd2 to D. This would be a great start to eat our own dog food.

ldmd2 is a dmd like small wrapper that translates commandline and executes real compiler ldc2, right?  It looks like it consists of three C++/C files: ldmd.cpp response.cpp man.c

This one doesn't require compiler knowledge and is mostly string processing.  I think anyone with a good C background moving into D would have fun with it.

Question: is ldmd.d short lived though?  What happens when dmd itself switches to D?
-- 
Dan
June 08, 2014
On Sunday, 8 June 2014 at 17:32:24 UTC, Dan Olson wrote:
> Question: is ldmd.d short lived though?  What happens when dmd itself
> switches to D?

AFAIK it will always be relevant as natural ldc CLI provides lot of additional flags that expose LLVM capabilities. And goal of ldmd is to provide exact drop-in replacement for any script or utility that uses dmd CLI.
June 09, 2014
On 8 Jun 2014, at 23:52, Dicebot via digitalmars-d-ldc wrote:
> AFAIK it will always be relevant as natural ldc CLI provides lot of additional flags that expose LLVM capabilities. And goal of ldmd is to provide exact drop-in replacement for any script or utility that uses dmd CLI.

That is indeed true. LDC use the LLVM command-line parsing code to also expose all the LLVM-internal flags, which are very helpful for debugging, testing and fine-tuning the optimization options. The names of some of them conflict with DMD options, e.g. -debug. For this reason, the D flag has been renamed to -d-debug in the ldc binary.

This is unlikely to change unless somebody comes up with a very compelling usability argument.

Best,
David
June 10, 2014
On Friday, 6 June 2014 at 17:31:23 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> On 6 Jun 2014, at 18:54, Kai Nacke via digitalmars-d-ldc wrote:
>> Well, Ian (from GDC project) told everybody that compiler construction is no rocket science.
>
> Actually, that was me, and I'm very much not from the GDC project. ;)

Ohh.... I read too much comments from Ian that day... I'am sorry.

Regards,
Kai
June 11, 2014
On Sunday, 8 June 2014 at 17:32:24 UTC, Dan Olson wrote:
> "Kai Nacke" <kai@redstar.de> writes:
>
>> * Port LDC to a new environment. E.g. LDC itself compiles on Solaris
>> 11 but misses some files in druntime and phobos. Or try LDC on
>> OpenBSD, NetBSD, Plan 9, ....
>
> I bet any of the BSD family might be fairly easy for any who wants to
> try, especially if clang/LLVM already is well supported.  DragonFly BSD
> is another one.  Could be instant gratification for someone.

FreeBSD is well supported except that there is no FreeBSD port (anyone?).

>> * Translate ldmd2 to D. This would be a great start to eat our own dog
>> food.
>
> ldmd2 is a dmd like small wrapper that translates commandline and
> executes real compiler ldc2, right?  It looks like it consists of three
> C++/C files: ldmd.cpp response.cpp man.c
>
> This one doesn't require compiler knowledge and is mostly string
> processing.  I think anyone with a good C background moving into D would
> have fun with it.
>
> Question: is ldmd.d short lived though?  What happens when dmd itself
> switches to D?

As Dicebot and David already said: ldmd2 is a frontend driver required for DMD compability. This will not change even if DDMD arrives.

Regards,
Kai
June 12, 2014
"Kai Nacke"  wrote in message news:xegnwtwoubzseegyjqxi@forum.dlang.org...

> As Dicebot and David already said: ldmd2 is a frontend driver required for DMD compability. This will not change even if DDMD arrives.

_when_ DDMD arrives.  And with Walter changing the frontend license it would be possible to use the converted code as a base for ldmd2. 

June 12, 2014
Hi Kai !
I'm interesting at ldc in support of 2.065 or even better git head frontend.

I'll try on those days build ldc itself and try to merge with 2.065.
Also i think link to gcc should be updated to :

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/dwarf/i686-4.9.0-release-posix-dwarf-rt_v3-rev2.7z/download

It's newer gcc and ldc works fine with it.
June 13, 2014
Hi Temtaine!

On Thursday, 12 June 2014 at 20:45:32 UTC, Temtaime wrote:
> Hi Kai !
> I'm interesting at ldc in support of 2.065 or even better git head frontend.

That's great! 2.065 is already merged (in branch merege-2.065) but there is yet not work done on upcoming 2.066.

> I'll try on those days build ldc itself and try to merge with 2.065.
> Also i think link to gcc should be updated to :
>
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.0/threads-posix/dwarf/i686-4.9.0-release-posix-dwarf-rt_v3-rev2.7z/download
>
> It's newer gcc and ldc works fine with it.

I'll check and update. Thanks for the link.

Regards,
Kai
« First   ‹ Prev
1 2