www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SDC needs you -- redux

reply Shammah Chancellor <shammah.chancellor gmail.com> writes:
I'm going to re-iterate what deadalnix said.   I am doing this because 
the thread about SDC got co-opted in this forums usual fashion.

So, let me qualify:

I've been part of this community since late 2001.  We've come a long 
way.  However,  believe having another *good* frontend implementation 
is absolutely key for our success.

Let me qualify this need with some stats.  I don't mean for this list 
to in any way knock Walter or DMD, but rather to just stress the value 
of SDC to the community and also encourage people who do not want to 
spent the time getting over the learning curve for the DMD frontend to 
invest some time implementing simple things in SDC.

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!

I could go on and on about this.  But I would hope that maybe you just 
clone the git repo, and start fiddling around and submit some simple 
PRs.    We recently reorganized our git repos to make it much easier 
for people to get started.

Again,  I don't mean for this to come off as a knock against DMD or the 
work that has been done there over the last 15 years.   I also don't 
mean to steal any engineering resources from the DMD frontend.   
Instead, I am hoping to appeal to those people, who like myself, do not 
have the time to understand the DMD frontend and work on it.   SDC is 
simple, and easy to get started on.

So again, here is our TODO list:  
https://github.com/deadalnix/SDC/wiki/TODO-list

I hope you will join Amaury and myself in working on this awesome 
project.   We have a #slack channel set up to help us work 
asynchronously, and I would love it if you send me am email so I can 
invite you to the teamchat.   Even just having people in the channel to 
have discourse with would be helpful!

Cheers,
-Shammah
Apr 18 2015
next sibling parent =?UTF-8?B?Ik3DoXJjaW8=?= Martins" <marcioapm gmail.com> writes:
Please add me on #slack: marcioapm at google's email
Apr 18 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor 
wrote:

 ...


Are there any plans for the LDC and SDC team to work together 
once SDC matures?
Apr 18 2015
next sibling parent reply "Johan Engelen" <j j.nl> writes:
On Saturday, 18 April 2015 at 20:39:56 UTC, weaselcat wrote:

 On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor 
 wrote:

 ...


 Are there any plans for the LDC and SDC team to work together 
 once SDC matures?


I recently joined the LDC team, and I am a bit at a loss...
Should I join SDC so that I can have fun writing in D?  How big 
is the duplication of effort between SDC and LDC? Could LDC and 
SDC perhaps share druntime? (LDC has many custom changes to 
druntime to either use LLVM intrinsics, or rewriting of assembly 
routines that (I think) really only work for DMD)

-Johan
Apr 20 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 20 April 2015 at 20:01:17 UTC, Johan Engelen wrote:

 On Saturday, 18 April 2015 at 20:39:56 UTC, weaselcat wrote:

 On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor 
 wrote:

 ...


 Are there any plans for the LDC and SDC team to work together 
 once SDC matures?


 I recently joined the LDC team, and I am a bit at a loss...
 Should I join SDC so that I can have fun writing in D?  How big 
 is the duplication of effort between SDC and LDC? Could LDC and 
 SDC perhaps share druntime? (LDC has many custom changes to 
 druntime to either use LLVM intrinsics, or rewriting of 
 assembly routines that (I think) really only work for DMD)

 -Johan


I'm actually looking at how things are done in LDC runtime on a 
regular basis. That is great source of help.

Right now, thing are reimplemented in SDC, but the actual runtime 
is very slim. I reimplemented exceptions as I was not satisfied 
by the way C++ exception are handled by LDC and I want to 
leverage type qualifier to improve the GC, which makes for an 
incompatible GC API at runtime level for SDC (so reimplementation 
is going on here).

I'm not opposed to sharing work with LDC, and vast part of SDC's 
runtime are stupid stubs that fake it (till hopefully we can make 
it) and I'm sure sharing with LDC is an option for some of them.
Apr 21 2015
prev sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2015-04-18 20:39:55 +0000, weaselcat said:


 On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor wrote:

 ...


 
 Are there any plans for the LDC and SDC team to work together once SDC matures?


I have not had an opportunity to speak with them, but LDC is written in 
C++.   But, I'm sure they have the skills to help us if they want to :)

I was am interested to know if their custom runtime code would be 
something both projects could share.

-Shammah
Apr 20 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/15 10:21 AM, Shammah Chancellor wrote:

 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.


Agreed (as with your entire call to arms - nicely done). Where's a 
complete description of Go's out-of-the-box tooling? That's definitely 
an example we can draw inspiration from. -- Andrei
Apr 18 2015
parent reply "Mengu" <mengukagan gmail.com> writes:
On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu 
wrote:

 On 4/18/15 10:21 AM, Shammah Chancellor wrote:

 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.


 Agreed (as with your entire call to arms - nicely done). 
 Where's a complete description of Go's out-of-the-box tooling? 
 That's definitely an example we can draw inspiration from. -- 
 Andrei


here it is: https://golang.org/cmd/

many of them are also passed to go cmd as an argument. like go 
fmt, go vet, go test, etc.
Apr 18 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/15 3:08 PM, Mengu wrote:

 On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu wrote:

 On 4/18/15 10:21 AM, Shammah Chancellor wrote:

 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.


 Agreed (as with your entire call to arms - nicely done). Where's a
 complete description of Go's out-of-the-box tooling? That's definitely
 an example we can draw inspiration from. -- Andrei


 here it is: https://golang.org/cmd/

 many of them are also passed to go cmd as an argument. like go fmt, go
 vet, go test, etc.


Cool, thanks! Looking forward to tips from Go users about which tools 
are most appreciated and appropriate for a D incarnation. -- Andrei
Apr 18 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu 
wrote:

 On 4/18/15 3:08 PM, Mengu wrote:

 On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei 
 Alexandrescu wrote:

 On 4/18/15 10:21 AM, Shammah Chancellor wrote:

 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.


 Agreed (as with your entire call to arms - nicely done). 
 Where's a
 complete description of Go's out-of-the-box tooling? That's 
 definitely
 an example we can draw inspiration from. -- Andrei


 here it is: https://golang.org/cmd/

 many of them are also passed to go cmd as an argument. like go 
 fmt, go
 vet, go test, etc.


 Cool, thanks! Looking forward to tips from Go users about which 
 tools are most appreciated and appropriate for a D incarnation. 
 -- Andrei


gofmt, much like python's standardized formatting, made 
contributing to go projects much easier IMO. While the same can't 
be done for D, hopefully dfmt becomes a standard tool and each 
dub project can just include a dfmt.conf or something to make 
contributing easier.

I agree with the OP on the tooling point, just look at C++. C++ 
had historically zero(okay, some - but it sucked! ctags were 
awful, etc.) tooling before clang hit the scene. IMO clang/LLVM 
was a complete game changer for C++ tooling, and I hope D can do 
the same.

Clang has a static analyzer, a formatter, a modernizer...
Hell, clang(and obv. libclang) can dump the AST right from its 
driver, and even has autocompletion built into 
it(-code-completion-at)

Also, it offers many sanitizers now(undefined behavior, thread, 
memory, address, leak, dataflow, probably others I forgot). AFAIK 
a few of these are usable with LDC?
Apr 18 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 19 April 2015 at 06:01:14 UTC, weaselcat wrote:

 gofmt, much like python's standardized formatting, made 
 contributing to go projects much easier IMO. While the same 
 can't be done for D, hopefully dfmt becomes a standard tool and 
 each dub project can just include a dfmt.conf or something to 
 make contributing easier.


dfmt options go in .editorconfig with the rest of your project's 
style decisions like tabs/spaces and line length.


 I agree with the OP on the tooling point, just look at C++. C++ 
 had historically zero(okay, some - but it sucked! ctags were 
 awful, etc.) tooling before clang hit the scene. IMO clang/LLVM 
 was a complete game changer for C++ tooling, and I hope D can 
 do the same.


For what it's worth, D-Scanner can output ctags information for D 
files.


 Clang has a static analyzer, a formatter, a modernizer...
 Hell, clang(and obv. libclang) can dump the AST right from its 
 driver, and even has autocompletion built into 
 it(-code-completion-at)


We now have a formatter. D-Scanner can perform some static 
analysis and dump an AST from its parser, DCD provides 
autocompletion. dfix can perform syntax upgrades.
Apr 20 2015
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2015-04-20 22:40:10 +0000, Brian Schott said:


 On Sunday, 19 April 2015 at 06:01:14 UTC, weaselcat wrote:

 gofmt, much like python's standardized formatting, made contributing to 
 go projects much easier IMO. While the same can't be done for D, 
 hopefully dfmt becomes a standard tool and each dub project can just 
 include a dfmt.conf or something to make contributing easier.


 
 dfmt options go in .editorconfig with the rest of your project's style 
 decisions like tabs/spaces and line length.
 

 I agree with the OP on the tooling point, just look at C++. C++ had 
 historically zero(okay, some - but it sucked! ctags were awful, etc.) 
 tooling before clang hit the scene. IMO clang/LLVM was a complete game 
 changer for C++ tooling, and I hope D can do the same.


 
 For what it's worth, D-Scanner can output ctags information for D files.
 

 Clang has a static analyzer, a formatter, a modernizer...
 Hell, clang(and obv. libclang) can dump the AST right from its driver, 
 and even has autocompletion built into it(-code-completion-at)


 
 We now have a formatter. D-Scanner can perform some static analysis and 
 dump an AST from its parser, DCD provides autocompletion. dfix can 
 perform syntax upgrades.


Can D-Scanner really provide you with autocompletion for code that is 
from a mixin generated by CTFE?

-Shammah
Apr 20 2015
prev sibling next sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Brian Schott" <briancschott gmail.com> writes:

 For what it's worth, D-Scanner can output ctags information for D
 files.


Brian, how about etags for emacs?
Apr 21 2015
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 21 April 2015 at 15:01:59 UTC, Dan Olson wrote:

 "Brian Schott" <briancschott gmail.com> writes:

 For what it's worth, D-Scanner can output ctags information 
 for D
 files.


 Brian, how about etags for emacs?


Better:

https://github.com/atilaneves/ac-dcd

Atila
Apr 21 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Atila Neves" <atila.neves gmail.com> writes:

 Better:

 https://github.com/atilaneves/ac-dcd

 Atila


Yes, I grabbed that last fall. It's in my .emacs but disabled. I'll have
to go back a try it again. It looked really good but I was having some
sort of problem, I don't remember what. Probably something to do with
needed extra elisp libraries.
Apr 21 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 22 April 2015 at 06:59:42 UTC, Dan Olson wrote:

 "Atila Neves" <atila.neves gmail.com> writes:

 Better:

 https://github.com/atilaneves/ac-dcd

 Atila


 Yes, I grabbed that last fall. It's in my .emacs but disabled. 
 I'll have
 to go back a try it again. It looked really good but I was 
 having some
 sort of problem, I don't remember what. Probably something to 
 do with
 needed extra elisp libraries.


Extra lisp libraries? How did you install it?

As for the your brain using etags keybindings: it's Emacs, you 
can bind those to anything ;)

Atila
Apr 22 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Atila Neves" <atila.neves gmail.com> writes:

 Extra lisp libraries? How did you install it?


I found my notes.  I think it had to do with using flycheck, which I
disabled.  I am really ancient and set in my ways so distracted when
code suggestions popup while I am typing.  I just need to try again,
customize a little, and learn.


 As for the your brain using etags keybindings: it's Emacs, you can
 bind those to anything ;)


Yes, it is so bad I have several Symbolics Zmacs [1] key and mouse
bindings (from 80's) setup for GNU Emacs and I have never gotten over
the loss of the Super and Hyper keys that accompanied Control and Meta.

[1] http://en.wikipedia.org/wiki/Zmacs
Apr 22 2015
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
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
Apr 22 2015
next sibling parent "Brian Schott" <briancschott 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


Companies that make customized keyboards exist:

http://www.wasdkeyboards.com/
Apr 22 2015
prev sibling parent reply "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?
Apr 22 2015
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 22 April 2015 at 17:31:47 UTC, John Colvin wrote:

 Most keyboards have some kind of "Windows" key, on macs it's 
 called "cmd". You can use that key for whatever you want, 
 surely?


No, I'm very sure neither my Model M nor my Omnikey Ultra have 
that.

-Wyatt
Apr 22 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 22 April 2015 at 17:52:25 UTC, Wyatt wrote:

 On Wednesday, 22 April 2015 at 17:31:47 UTC, John Colvin wrote:

 Most keyboards have some kind of "Windows" key, on macs it's 
 called "cmd". You can use that key for whatever you want, 
 surely?


 No, I'm very sure neither my Model M nor my Omnikey Ultra have 
 that.

 -Wyatt


When I said "most" I meant "the majority of keyboards available 
for purchase at any given price, from no-brand membrane eBay 
purchase from china to high-end mechanical". Well, I guess even 
the classics have downsides :)
Apr 22 2015
prev sibling parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"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
Apr 23 2015
parent Dan Olson <zans.is.for.cans yahoo.com> writes:
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
Apr 23 2015
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 21 April 2015 at 15:01:59 UTC, Dan Olson wrote:

 "Brian Schott" <briancschott gmail.com> writes:

 For what it's worth, D-Scanner can output ctags information 
 for D
 files.


 Brian, how about etags for emacs?


Because the documentation for etags consists of a Wikipedia 
article and a Stack Overflow post. I'm far too lazy to 
reverse-engineer Emacs' source code.

https://github.com/Hackerpilot/Dscanner/issues/223
Apr 21 2015
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
"Brian Schott" <briancschott gmail.com> writes:


 On Tuesday, 21 April 2015 at 15:01:59 UTC, Dan Olson wrote:

 "Brian Schott" <briancschott gmail.com> writes:

 For what it's worth, D-Scanner can output ctags information for D
 files.


 Brian, how about etags for emacs?


 Because the documentation for etags consists of a Wikipedia article
 and a Stack Overflow post. I'm far too lazy to reverse-engineer Emacs'
 source code.

 https://github.com/Hackerpilot/Dscanner/issues/223


Mind if I add it then?  I've lived with etags for so long that my
fingers automatically reach for " M-." for D names too.
Apr 21 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/22/2015 08:49 AM, Dan Olson wrote:

 Mind if I add it then?  I've lived with etags for so long that my
 fingers automatically reach for " M-." for D names too.


Please do, it would be really helpful, at least to me.
Apr 22 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 20 April 2015 at 22:40:11 UTC, Brian Schott wrote:

 On Sunday, 19 April 2015 at 06:01:14 UTC, weaselcat wrote:

 gofmt, much like python's standardized formatting, made 
 contributing to go projects much easier IMO. While the same 
 can't be done for D, hopefully dfmt becomes a standard tool 
 and each dub project can just include a dfmt.conf or something 
 to make contributing easier.


 dfmt options go in .editorconfig with the rest of your 
 project's style decisions like tabs/spaces and line length.


 I agree with the OP on the tooling point, just look at C++. 
 C++ had historically zero(okay, some - but it sucked! ctags 
 were awful, etc.) tooling before clang hit the scene. IMO 
 clang/LLVM was a complete game changer for C++ tooling, and I 
 hope D can do the same.


 For what it's worth, D-Scanner can output ctags information for 
 D files.


 Clang has a static analyzer, a formatter, a modernizer...
 Hell, clang(and obv. libclang) can dump the AST right from its 
 driver, and even has autocompletion built into 
 it(-code-completion-at)


 We now have a formatter. D-Scanner can perform some static 
 analysis and dump an AST from its parser, DCD provides 
 autocompletion. dfix can perform syntax upgrades.


I think your work is very valuable, but SDC is still necessary. D 
a very meta programming language, which makes having a fully 
featured front end necessary for various tooling.

Your approach certainly yield result faster, and is sufficient 
for some tooling. I see your work and SDC as complementary rather 
than stepping on each other. This is why I put tools like REPL or 
test runner in the list rather than tools like formatting, which 
you approach can already provide.
Apr 21 2015
prev sibling parent "logicchains" <jonathan.t.barnard gmail.com> writes:
On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu 
wrote:

 Cool, thanks! Looking forward to tips from Go users about which 
 tools are most appreciated and appropriate for a D incarnation. 
 -- Andrei


gofmt -r 'foo -> bar' - accurate, context-sensitive renaming 
without need for any external tool.
Apr 19 2015
prev sibling next sibling parent reply "jkpl" <jkpl nowhere.fr> writes:
On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor 
wrote:

 ...Even just having people in the channel to have discourse 
 with would be helpful!

 Cheers,
 -Shammah


Hey. Is the win32 build fixed now (libd) ?
Since, i don't know, maybe 2 monthes, it looks like there is a 
mess with the 32/64 bit types.
Apr 22 2015
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2015-04-22 11:28:21 +0000, jkpl said:


 Hey. Is the win32 build fixed now (libd) ?
 Since, i don't know, maybe 2 monthes, it looks like there is a mess 
 with the 32/64 bit types.


I'm not sure.  I don't use Windows unfortunately.   It would be awesome 
if you could take a look and make it work if it doesn't!

-Shammah
Apr 22 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 22 April 2015 at 11:28:22 UTC, jkpl wrote:

 On Saturday, 18 April 2015 at 17:21:28 UTC, Shammah Chancellor 
 wrote:

 ...Even just having people in the channel to have discourse 
 with would be helpful!

 Cheers,
 -Shammah


 Hey. Is the win32 build fixed now (libd) ?
 Since, i don't know, maybe 2 monthes, it looks like there is a 
 mess with the 32/64 bit types.


32 bits support is not there quite yet. You can fix this :)
Apr 22 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Apr 22 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 22 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 22 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 23 2015
parent reply "Johan Engelen" <j j.nl> writes:
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...)
Apr 26 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 26 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
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.
Apr 27 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 27 April 2015 at 07:01:23 UTC, Suliman wrote:

 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.


dub worked at some point, but I'm not sure it still does. I'm not 
using it, so I can't really help you with it.
Apr 27 2015
prev sibling parent "Johan Engelen" <j j.nl> writes:
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! ;-)
Apr 27 2015