On 04/18/2015 07:21 PM, Shammah Chancellor wrote:
> 1) SDC, libd-llvm, and libd together are ~ 30KLOC of idiomatic and very
> intelligible D code.  Compare this with the 300KLOC for the DMD frontend.
>     1.1) The 30KLOC is clean and easy to get into.  It took me less than
> 3 days to get into it and start implementing language features.
>     1.2) This is enabled by the use of a scheduler to easily handle
> complex Dlang features.
>     1.3) This will enable advanced compiler normally be very difficult
> to implement
> 2) SDC supports a majority of the language at this point, the remaining
> work is mostly trivial. (When I say majority, I mean majority in terms
> of LOC needed to support, not in terms of implemented pieces of syntatic
> sugar)
>     2.1) We won't need another 250KLOC to get to 100% feature parity.
> We're already at something like 80% feature parity by my estimation.
> 3) SDC is designed also to be a library that can used for tooling in an
> easy fashion!
>     3.1) I work with Golang on a daily basis professionally.  The
> tooling for golang is a major reason for it's adoption.  This tooling
> looks like gofix, gofmt, govet, etc.  We need this tooling to be able to
> succeed.
> 4) SDC use of fibers and a scheduler allows us to have a very robust
> error handling mechanism that DMD will never be able to implement.   We
> emit beautiful clang-style errors telling you EXACTLY what is wrong with
> your code.
> 5) SDC is fast.  It is actually faster than DMD when you move into
> template and CTFE land.
> 6) SDC leverages all the work done by the HUGE llvm group.
> 7) SDC uses the LLVM JIT for CTFE, this means no double-implementation
> of language features for CTFE, and for normal compilation.
> 8) Because SDC is written in D, is clean, and uses a JIT this opens up
> the door for actually exposing compiler AST Nodes *directly* to the code
> being compiled. (!!!!!!!!!  No more __traits horror when doing
> metaprogramming)
> 9) Because SDC is clean, easy to understand, and easy to implement
> language feature on top of, we have been able to find quite a few bugs
> in DMD.  I have been submitting bug reports back to DMD and actually
> causing the mainline D compiler to do a *better* job!

It's a really impressive list and it's very much how I'd like dmd to be written.

I could offer to work on dub and travis-ci integration, but there doesn't even seem to exists a cmdline interface?

bin/sdc --help
HELP !
core.exception.RangeError@sdc/src/sdc/main.d(51): Range violation

Also some of the TODO items really look very feasible. https://github.com/deadalnix/SDC/issues/125

What I'd like to see though, is a prioritized list of stuff that needs to be done to reach a working D style hello world.

And at some point you need to get rid of stack traces of the compiler on compile errors.

On Wednesday, 22 April 2015 at 22:44:02 UTC, Martin Nowak wrote:
> I could offer to work on dub and travis-ci integration, but there doesn't even seem to exists a cmdline interface?
>

What do you mean by this ?

> bin/sdc --help
> HELP !
> core.exception.RangeError@sdc/src/sdc/main.d(51): Range violation
>

The command line argument handling is, indeed, not the best you can have. I never really focused on that. That is a easy way to contribute some improvement.

> Also some of the TODO items really look very feasible.
> https://github.com/deadalnix/SDC/issues/125
>
> What I'd like to see though, is a prioritized list of stuff that needs
> to be done to reach a working D style hello world.
>

D style hello world is HUGE. writeln need half of the world to work to spit out anything :)

I guess the main non trivial thing SDC can compile at this point is its own runtime. Pain point have been the lack of "return;" and variosu other things in the list.

> And at some point you need to get rid of stack traces of the compiler on
> compile errors.

Yes, It is also needed to stop dumping the LLVM IR on the standard output. But at this stage, it just make the dev much easier.

On 2015-04-23 04:00, deadalnix wrote:

> D style hello world is HUGE. writeln need half of the world to work to
> spit out anything :)

What about "Hello World" with "printf" instead?

> Yes, It is also needed to stop dumping the LLVM IR on the standard
> output. But at this stage, it just make the dev much easier.

Hide it with a --verbose flag or similar.

-- 
/Jacob Carlborg

"John Colvin" <john.loughran.colvin@gmail.com> writes:

> On Wednesday, 22 April 2015 at 16:27:59 UTC, Wyatt wrote:
>> On Wednesday, 22 April 2015 at 15:44:03 UTC, Dan Olson wrote:
>>>
>>> Super and Hyper keys
>>>
>> A veteran of the Lisp machines!  I've been hoping for someone to manufacture a modern keyboard with these for about a decade now. (Well, I'm pretty sure the "Windows" key you see frequently on terrible mushy keyboards is Super in a bad costume, but none of my keyboards have it.)
>>
>> -Wyatt
>
> Most keyboards have some kind of "Windows" key, on macs it's called "cmd". You can use that key for whatever you want, surely?

Yes, I do bind the mac command key in emacs for some stuff. Actually mac rows of keys: [fn] [ctrl] [opt] [cmd] is like the Symbolics so it is fine.  Ordering is different though.  Every new keyboard is like playing a piano with the keys rearranged.  But I adapt.  Slowly.

BTW, I found this [1].  I know, really off topic, but interesting for Lisp Machine veterans.  Remember how you could recompile a function in the operating system while it is running?

[1] http://deskthority.net/keyboards-f2/recreating-the-lisp-keyboard-t497.html

Wikipedia article and why default emacs key bindings are painful today.

http://en.wikipedia.org/wiki/Space-cadet_keyboard http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html

On Thursday, 23 April 2015 at 06:32:39 UTC, Jacob Carlborg wrote:
> On 2015-04-23 04:00, deadalnix wrote:
>
>> D style hello world is HUGE. writeln need half of the world to work to
>> spit out anything :)
>
> What about "Hello World" with "printf" instead?
>

We can do this already :)

>> Yes, It is also needed to stop dumping the LLVM IR on the standard
>> output. But at this stage, it just make the dev much easier.
>
> Hide it with a --verbose flag or similar.

There are plenty of low hanging fruit. Short version is: there is more to do than I have time to do. So I'm focusing on difficult problems (Right now, GC and getting a serie of patch into LLVM to handle aggregate handling). The end result is that these kind of small changes do not get implemented.

This kind of thing is probably easy to implement and a good pick for a newcomer.

I'd like to contribute to SDC too, but... the current build system (Makefile) keeps me from working on it: I mostly work on Windows, and I do not want to use MinGW/MSYS/Cygwin for this. CMake would be a much nicer buildsystem for me.
Are you interested in switching to CMakeFile ?
(I am hoping someone else will do this, but I may give it a try to see if I can get it to work...)

On Sunday, 26 April 2015 at 20:44:00 UTC, Johan Engelen wrote:
> I'd like to contribute to SDC too, but... the current build system (Makefile) keeps me from working on it: I mostly work on Windows, and I do not want to use MinGW/MSYS/Cygwin for this. CMake would be a much nicer buildsystem for me.
> Are you interested in switching to CMakeFile ?
> (I am hoping someone else will do this, but I may give it a try to see if I can get it to work...)

I do think there is more valuable contribution than changing the build system.

On Monday, 27 April 2015 at 06:06:22 UTC, deadalnix wrote:
> On Sunday, 26 April 2015 at 20:44:00 UTC, Johan Engelen wrote:
>> I'd like to contribute to SDC too, but... the current build system (Makefile) keeps me from working on it: I mostly work on Windows, and I do not want to use MinGW/MSYS/Cygwin for this. CMake would be a much nicer buildsystem for me.
>> Are you interested in switching to CMakeFile ?
>> (I am hoping someone else will do this, but I may give it a try to see if I can get it to work...)
>
> I do think there is more valuable contribution than changing the build system.

What's stop use native D build system like DUB or DCO[1]?

[1] https://github.com/FrankLIKE/dco

P.S. Thanks for project.

On Monday, 27 April 2015 at 06:06:22 UTC, deadalnix wrote:
> On Sunday, 26 April 2015 at 20:44:00 UTC, Johan Engelen wrote:
>> I'd like to contribute to SDC too, but... the current build system (Makefile) keeps me from working on it: I mostly work on Windows, and I do not want to use MinGW/MSYS/Cygwin for this. CMake would be a much nicer buildsystem for me.
>> Are you interested in switching to CMakeFile ?
>> (I am hoping someone else will do this, but I may give it a try to see if I can get it to work...)
>
> I do think there is more valuable contribution than changing the build system.

Well... I first should be able to build it, I think! ;-)