Re: dmd support for IDEs
Denis Koroskin 2kor...@gmail.com сообщил/сообщила в новостях следующее: news:op.u1m30ituo7c...@korden-pc... On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright newshou...@digitalmars.com wrote: I believe it won't work. It will always be slow and incomplete. Instead, I would make it easier to embed DMD into an IDE: separate DMDFE from DMDBE, fix memory leaks, remove all the static data (so that code would be re-intrable and it could work in different threads in parallel), move most of DMD code into a DLL so that an IDE could dynamically link with it and whatever it pleases with the source code. In fact, that's what I do right now. I'm writing my own D IDE in my spare time (in D, of course). I already made a lot of progress and now it's time to start implementing source code analysis. First thing I did is I made complete D bindings for C++ code. It worked out quite well but it was leaking so badly that I dropped it. Instead, I started porting DMD entirely to D (except the backend, of course), and I already got some great results. A few simple programs compile and produce byte-perfect binaries. It's still in its early stages and there is a lot of work to do, but it will be finished soon (hopefully). It could probably become a part of an official distribution, eventually. :) If anyone is interested and is willing to test and/or help, I will gladly share my code. Hi, Denis! I am beginner in D, but this theme is interesting for me - I very much would like to take part in creation IDE. I am interesting. I'd like to help. I hope I'll be able to help you? Contact me please at sablete...@gmail.com Sincerelly, Sergey __ Information from ESET NOD32 Antivirus, version of virus signature database 4862 (20100212) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: dmd support for IDEs + network GUI
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.208.1255923114.20261.digitalmar...@puremagic.com... On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Great! Thanks for your interest and to the rest of the group for letting me go off topic like this! The offtopics are some of the most interesting bits!
Re: dmd support for IDEs + network GUI
Nick Sabalausky wrote: Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.208.1255923114.20261.digitalmar...@puremagic.com... On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Adam. What you written at your web site is a very interesting read. Re your use of a binary protocol. Perhaps instead of re-inventing the wheel, you may want to look at what Google has done with the design of their Google Protocol Buffers, which also implements a very fast binary protocol. See here for a overview: http://code.google.com/apis/protocolbuffers/docs/overview.html It is also worthwhile reading the section called A bit of history. Note that there is also D implementation. http://256.makerslocal.org/wiki/index.php/ProtocolBuffer I don't know how current this is, though. One more point. What, if any, library to you plan to use ? cheers Nick B
Re: dmd support for IDEs + network GUI
On 10/20/09, Nick B ni...@gmail.com wrote: Re your use of a binary protocol. Perhaps instead of re-inventing the wheel, Eh, my code is already written and works. One of the advantages to my code generator reading a C like syntax is that I might be able to fully automate porting some existing APIs down the wire - I'm particularly looking at OpenGL, or at least a subset of it, to work with ease. Another one is porting my generator to a new language is easy - I already know the code and it is fairly simple anyway. Anyway, quickly skimming through the google page, their system isn't bad (Coincidentally, it and I encode unsigned ints and strings in exactly the same way! Cool.), but I don't think there's much to gain by me switching to it. Though, their signed varint algorithm is pretty elegant; I might have to use that. And it reminds me that I didn't even consider optional arguments on functions. Trivial to implement though, even compatible with my current protocol: if message length is shorter than what you expect, use default values for the rest of the arguments. This means they'd have to be at the end, but you expect that from C like functions anyway. It is also worthwhile reading the section called A bit of history. I thought about future compatibility, which is why my protocol has a length field on every message. If you read the length and the function number and find it isn't something you know, you can simply skip past the whole message and carry on. The ugliness might be that future functions deprecate old functions... if this took off and was widely used, it might end up looking like Win32 in 10 years (CreateWindow() nope, CreateWindowEx()!), but I'm ok with that. One more point. What, if any, library to you plan to use ? The D side is all custom code (I've written various libraries and helper tools over the years for myself - the big one used here is a network manager thing that handles incoming connections and output buffering) and Phobos - nothing third party there. I'm using D2, but there's nothing preventing it from being backported to D1 at some point. I actually want to do a DMDScript port that speaks it too, but that's way down the line. For the viewer, my current implementation is C++ with Qt. I'd like to actually do various viewers, including ones with less fat dependencies (asking users to download Qt just to run it is a bit heavy), but for now, I just wanted something I could start using immediately without too much trouble for me. Qt on C++ works pretty well across platforms, and I already know how to use it, so it was an easy choice for early stages. cheers Nick B Thanks! -Adam
Re: dmd support for IDEs and the D tool chain
BCS n...@anon.com wrote in message news:a6268ffb8018cc1e47bb9fc...@news.digitalmars.com... Hello Nick, BCS n...@anon.com wrote in message If mine did that I'd shoot him (a scorching e-mail :) You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* professor for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to. And I'm not even at a well know CS school. I'd have asked for my money back. Oh man, I've fought and lost many battles with schools that were enormously smaller then actually getting any money back. I've known *banks* that were more sensible about money (and hell, I'm even about ready to swear *those* off (I'm not referring to their investment practices)). As far as well-known schools, yea, I've noticed too that quality and level-of-notoriety have basically no correlation. Around Cleveland here (for whatever that's worth, maybe not much I suppose), John Carroll University is widely considered one of the best schools in the area, has one of the highest sets of entrance criteria, and is overall regarded very highly. Any time I've ever mentioned the school's name to anyone around Cleveland, not a single time has the reaction ever been anything less than glowingly positive. Well...they let me in as a transfer (*far* easier to get in pretty much anywhere that way), and while I have a ton of WTF experiences about this place, there's one that always sticks out in my head: One of the CS profs I had there was a PHd (well, they pretty much all were). But with this particular one, he openly pointed out that C was the only language he knew. Which might not normally be so bad (although I'd at least consider it questionable), but...On one of the two or three programming assignments in the class (they were all in C and no more than about a hundred lines max), I had to fill a statically-allocated buffer with some string input from a network connection, echo it to stdout, repeat until the input was exhausted, and exit (yea, not exactly a taxing assignment - and keep in mind, this wasn't an intro or even a lower-division class, this was upper-division). Ok, so I figured, Obviously, the input length isn't guaranteed to be a multiple of my buffer size, so when I get the final chunk I'd better toss a \0 at the end so my output doesn't include any garbage data from the previous iteration. Turned it in. Few days layer when I got it back, I got a bad grade, and he had marked that \0 I added as This won't work. (I had tested it, of course.) I just assumed he had simply graded too fast and goofed, so I pointed it out to him and explained the problem. He looked again, studied it, and went Nope, that won't work. I questioned some more, figuring there must be some *other* bug he was referring to that I just hadn't noticed and that just happened to have worked out by pure luck (it's certainly been known to happen in C). But the more we discussed it, the more I realized: This joker didn't have the slightest clue how null-terminated strings worked! Obviously that would be fine for a Java programmer, or C#, Python, D, etc., but here was this guy who didn't understand one of the most basic concepts in what he himself admits is the only language he knows...and not only does some group of idiots actually give him a PHd in CS, but some other idiots actually hire him to teach it at an allegedly very good school. Of course, I *am* well aware there's a big distinction between programming and computer science...but this was was just plain ridiculous. You can't call someone a handyman if they've studied a million books on the subject but don't know how to work a screwdriver. And that was just one of many contradictions to John Carroll's alleged quality. Don't get me started on their Sociology dept. And the students...oh, man...I swear I am not exaggerating even the slightest bit when I say that most of them were, without a doubt, among the absolute stupidest people I've ever met in my life (and to top it off, they had the personalities of dry sponges). And yet, this school was known to have fairly strict entrance criteria. The whole place was so pathetic I pretty much just checked-out most of my third semester there and then left for a different place (which had a whole other set of...dysfunctions, to put it *very* mildly...). The school I had gone to before that was well-known as a party school (BGSU), and as awful as it was, it was actually *better* than the well-respected JCU in almost every way.
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer wrote: ANTLR has pretty good support for backtracking, so writing a D grammar for it wasn't too difficult, but then the resultant performance isn't anything near what I'd like. My recommendation is to forget about parser generators and just build one by hand. They're easy to write, and you won't have speed problems with them. There are other advantages, too, like better error messages and error recovery.
Re: dmd support for IDEs and the D tool chain
BCS wrote: (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) That's one of my gripes about compiler classes, they expend enormous effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky wrote: (Cue Walter reminiscing about how great Caltech was... ;) ) The only software course I took at Caltech was a Fortran one. I can't remember anything about it g.
Re: dmd support for IDEs and the D tool chain
Walter Bright Wrote: Ellery Newcomer wrote: ANTLR has pretty good support for backtracking, so writing a D grammar for it wasn't too difficult, but then the resultant performance isn't anything near what I'd like. My recommendation is to forget about parser generators and just build one by hand. They're easy to write, and you won't have speed problems with them. There are other advantages, too, like better error messages and error recovery. Walter is 110% correct. Over the years I've expended enormous amounts of energy with parser generators esp. with trying to get good error messages and error recovery (exactly as Walter suggests). Nearly every time I went back to a hand-written lexer and recursive descent parser. To see the KISS principle in action, take a look at Walter's DMDScript internals: lexer.d and parser.d. Cheers Justin Johansson
Re: dmd support for IDEs and the D tool chain
Walter Bright wrote: BCS wrote: (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) That's one of my gripes about compiler classes, they expend enormous effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug Had the last one been in the summer and not during classes while I'm 2500 miles away, I would have.
Re: dmd support for IDEs and the D tool chain
Hello Walter, BCS wrote: (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) That's one of my gripes about compiler classes, they expend enormous effort on the simplest part of a compiler - the lexer/parser. In working on the D compiler, I easily spend less than 1% of the effort on the lexer/parser. Plug: you should sign up for my compiler construction seminar! We don't waste much time on the simple stuff, and do the hard bits instead. /Plug I'd love to, but I'm broke. OTOH I might get lucky and have a job by the next one. When/where/how much/link?
Re: dmd support for IDEs and the D tool chain
Eric Suen wrote: Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, Doing this would make it more difficult than necessary to move D to new platforms, and would make it more difficult than necessary to adapt it to other back ends which are usually implemented in C or C++. Does Walter Bright use D for any projects himself? dmdscript, Empire, Microemacs, and any new utilities I write, such as the D archives generator.
Re: dmd support for IDEs and the D tool chain
Hello Nick, BCS n...@anon.com wrote in message If mine did that I'd shoot him (a scorching e-mail :) You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* professor for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to. And I'm not even at a well know CS school. I'd have asked for my money back.
Re: dmd support for IDEs and the D tool chain
Hello Ellery, BCS wrote: Hello Ellery, For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :) It's probably because he can't make us write a LALR parser by hand. For a small language he could. My prof has done several 2-4 production grammars, by hand, on the board, in class!
Re: dmd support for IDEs + network GUI
On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Thanks for your interest and to the rest of the group for letting me go off topic like this! -- Adam D. Ruppe http://arsdnet.net
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbap0k$141...@digitalmars.com...
Nick Sabalausky wrote:
That mentioned, in the section about LL(k), If both AB and AB are
legal
expressions, where B can be of arbitrary length, then no finite amount of
look-ahead will allow this to be parsed.
I did a quick test in gold (LALR), and this handles the above just fine:
--
Name= 'Test'
Author = 'Test'
Version = 'Test'
About = 'Test'
Start Symbol = Type1Or2
Type1Or2 ::= Type1 | Type2
Type1 ::= 'A' '' Bs
Type2 ::= 'A' '' Bs ''
Bs ::= 'B' | Bs 'B'
--
However, that one example alone doesn't necessarily prove that it's
always
doable.
Bad example. Bs is regular. Try making it nested parens or something
like that. (It isn't LL(k), but it is pretty trivial anyways. ANTLR3 can
handle it without fuss)
If you mean it's doing it using the dfa/regex lexing engine instead of the
parser, it isn't. GOLD has a different syntax for terminals that are to be
lexed. Anything with the Foo ::= whatever syntax is a nonterminal that's
handled by LALR parsing. For terminals that are to be handled by the
dfa/regex lexer, it's Foo = whatever.
In any case, here's one that can successfully handle nested parens instead
of Bs:
---
Start Symbol = Type1Or2
Type1Or2 ::= Type1 | Type2
Type1 ::= 'A' '' Parens
Type2 ::= 'A' '' Parens ''
Parens ::= '(' ')' | '(' Parens ')'
---
Or nested sequences of parens:
---
Start Symbol = Type1Or2
Type1Or2 ::= Type1 | Type2
Type1 ::= 'A' '' ParensList
Type2 ::= 'A' '' ParensList ''
ParensList ::= Parens | ParensList Parens
Parens ::= '(' ')' | '(' ParensList ')'
---
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky a...@a.a wrote in message
news:hbblfe$2k4...@digitalmars.com...
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbaom1$138...@digitalmars.com...
Well, let's see here...
PrimExp - structLiteral
PrimExp - functionLiteral
and suppose
structLiteral = { /* really, really looong expression*/ }
functionLiteral = { statement }
functionLiteral = { /* really, really looong expression*/ ; }
In an LL(k) parser, when you get to PrimExp, you have to know which
choice to make based on the first k lookahead characters (probably
translates to '{' and one token past that). Obviously, that won't work
for this piece, so it isn't LL(k). You have to try parsing the one, and
back up and parse the other if the first one fails (dmd should do this,
but currently it just looks ahead for the first semicolon. come to think
of it, I should try patching that..)
ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.
But what I'm wondering about LALR is will it have to back up if it
chooses wrong, or can it sail on through in one parse attempt. I bet it
can.
I'll write up a test in a minute,
No sweat :)
---
Start Symbol = Program
! -- Terminals
Identifier = {Letter}{AlphaNumeric}*
Statement = 'foo'
! -- Rules
Program ::= Prim Exp | Program Prim Exp
Prim Exp ::= StructLit | Func Lit
StructLit ::= '{' Expression '}'
Func Lit ::= '{' Statement '}'
| '{' Expression ';' '}'
Expression ::= Expression '+' Mult Exp
| Expression '-' Mult Exp
| Mult Exp
Mult Exp::= Mult Exp '*' Negate Exp
| Mult Exp '/' Negate Exp
| Negate Exp
Negate Exp ::= '-' Value
| Value
Value ::= Identifier
| '(' Expression ')'
---
Re: dmd support for IDEs and the D tool chain
Christopher Wright wrote Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. SWT wrap native controls, and Eclipse is build on SWT, but for an application like Eclipse, use system provide native controls is no enough, you have to write some custom control. Here is the problem, Java developers just unable to write good looking GUI components or applications using any library, neither Swing nor SWT. for examples, Swing is really powerful GUI frameworks, Java2D is quite powerful, and Swing is very flexible, but most Swing applications are really ugly. Eclipse doesn't look very native because they using ugly tab for layout, you can change that by provide your owner theme. more than 99% controls in Eclipse are native controls... There is the link of custom theme for Eclipse: http://www.agpad.com/images/ide_m.png Eric
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbaom1$138...@digitalmars.com... But what I'm wondering about LALR is will it have to back up if it chooses wrong, or can it sail on through in one parse attempt. I bet it can. And how about actual ambiguity? How well does GOLD handle that? I already answered regarding the parsing stage, but I should point out that the lexing can still backtrack (I don't know if that's obvious or not). For instance, if you have the terminals: FooKeyword = 'foo' StuffKeyword = 'fooAAAB' and input string: fooAAAC Then the lexer will get to the A's, try to match StuffKeyword, then get to the C, realize StuffKeyword doesn't match after all, so it'll then accept the FooKeyword, and continue on again from the first A. That's probably obvious to language and regex experts, but I actually learned that by accident. Someone found a bug in my Goldie GOLD engine when using their grammar, and I tracked it down to that kind of scenario and realized I was supposed to backtrack, if possible, upon a lex error instead of just noting the error and moving on. A better foundation in the theory probably would have helped me with that :) Anyway, I find this stuff neat :)
Re: dmd support for IDEs and the D tool chain
On 10/16/09 19:18, Lutger wrote: Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. As I said later in the message, that it would be the optimal and everything doesn't have to be built in D. Like D Clang is quite new and it doesn't need to be built like Clang just to attract the enterprise but I think it would be easier to build an IDE if the compiler was built more like Clang. BTW Clang is shipped with the Developer Tools on Mac. Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) We got this, dsss just has to be revived by someone. GUI library: * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) Not sure it needs to be written in D. Many languages use bindings and wrappers just fine. We already have QtD, DWT, wxWindows, DFL and GtkD. One of those is a port (DWT) and one is native D (DFL). The GUI situation has been so rapidly improved, it's not an impediment anymore imho. GtkD doesn't use native controls, DFL is only for windows (last I checked). IDE: * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT Descent is probably the closest, in some aspects it even destroys C++ IDE's (compile time stuff) already. However one or two more IDE's or very good editors would likely help. This would be my shortlist: - a polished descent which supports D2 - dmd switch to ELF on windows and support for 64-bit there - dsss redux - gdc for embedded, also some more support from phobos for systems programming?
Re: dmd support for IDEs and the D tool chain
On 10/17/09 00:23, Christopher Wright wrote: Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse.
Re: dmd support for IDEs and the D tool chain
On 10/17/09 04:22, Eric Suen wrote: Lutger wrote Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, A large proportion of programming languages are bootstrapped. It is nosense to write D compiler in C, that means the D language author does not want to use D language. Does Walter Bright use D for any projects himself? Regards, Eric I think it says somewhere on the digitalmars site that there is not much gain in porting an existing project to D but all new projects will be in D. DMDScript (ECMA 262 also know as JavaScript) is written in D.
Re: dmd support for IDEs and the D tool chain
On 10/17/09 07:06, Nick Sabalausky wrote: Christopher Wrightdhase...@gmail.com wrote in message news:hbarno$188...@digitalmars.com... Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. Probably not as minor as it might seem. I find eclipse ugly. And although I'd never really thought about it before, I have to admit, I think it *is* one of the many factors as to why it's always felt too bloated for my tastes. Yes eclipse looks ugly. It's quite hard to create a GUI that looks good and native on all platforms (if you don't use separate GUIs). Besides, I can think of things (lots of things, in fact) that are pure steaming piles of (well, one can guess), but even despite that have still managed to gain widespread acceptance.
Re: dmd support for IDEs and the D tool chain
Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote: Does Walter Bright use D for any projects himself? He makes nice html presentations of the language, demonstrating small code snippets. They are sometimes available online :S
Re: dmd support for IDEs and the D tool chain
On 10/17/09 10:31, Eric Suen wrote: Christopher Wright wrote Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. SWT wrap native controls, and Eclipse is build on SWT, but for an application like Eclipse, use system provide native controls is no enough, you have to write some custom control. Here is the problem, Java developers just unable to write good looking GUI components or applications using any library, neither Swing nor SWT. for examples, Swing is really powerful GUI frameworks, Java2D is quite powerful, and Swing is very flexible, but most Swing applications are really ugly. I think Azureus looks quite native and if they haven't changed anything they're using SWT. Eclipse doesn't look very native because they using ugly tab for layout, you can change that by provide your owner theme. more than 99% controls in Eclipse are native controls... There is the link of custom theme for Eclipse: http://www.agpad.com/images/ide_m.png Eric
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg wrote: ... GtkD doesn't use native controls, DFL is only for windows (last I checked). Sure. But think of it this way: GtkD *is* the native controls (for Gnome), only they are also usable on other platforms. Same way QT *is* native for the KDE platform. (except QT does use native controls on other platforms nowadays).
Re: dmd support for IDEs and the D tool chain
language_fan wrote: Sat, 17 Oct 2009 10:22:55 +0800, Eric Suen thusly wrote: Does Walter Bright use D for any projects himself? He makes nice html presentations of the language, demonstrating small code snippets. They are sometimes available online :S DMDscript, the garbage collector, the runtime and phobos are written in D, though DMDScript is a port of C++. I wonder if Walter even has any projects besides D and DMD? I also wonder if it isn't frustrating for Walter spending so many years on D and still writing mostly C++ code.
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg wrote: On 10/17/09 00:23, Christopher Wright wrote: Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse. And the tabs are everywhere, and no attempt was made to make them look native to any platform.
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbaom1$138...@digitalmars.com...
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbak0n$q5...@digitalmars.com...
I could count the number of places that are ambiguous syntactically or
semantically on one hand, and maybe the number of places that require
arbitrary lookahead also. Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could
you give me a simple example?
Well, let's see here...
PrimExp - structLiteral
PrimExp - functionLiteral
and suppose
structLiteral = { /* really, really looong expression*/ }
functionLiteral = { statement }
functionLiteral = { /* really, really looong expression*/ ; }
In an LL(k) parser, when you get to PrimExp, you have to know which
choice to make based on the first k lookahead characters (probably
translates to '{' and one token past that). Obviously, that won't work
for this piece, so it isn't LL(k). You have to try parsing the one, and
back up and parse the other if the first one fails (dmd should do this,
but currently it just looks ahead for the first semicolon. come to think
of it, I should try patching that..)
ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.
But what I'm wondering about LALR is will it have to back up if it
chooses wrong, or can it sail on through in one parse attempt. I bet it
can.
I'll write up a test in a minute, but for the specific type of lookahead
you're talking about, that shouldn't be a problem for LR's in general
(including LALR). An LR doesn't start with 'PrimExp', it starts by looking
at that first '{'. At this point it doesn't give a rat's tiny hiney what
nonterminal the '{' is part of - it'll just consume more tokens until it
narrows down the list of possible matches to just one (or none, in the
case of a syntax error). And once that happens, it already knows all it
needs to know, and it moves on. So there's no looking ahead or backtracking
needed (except maybe for a one-token lookahead to see if the next token is
allowed and what possible matches it might rule out)
And how about actual ambiguity? How well does GOLD handle that?
When you use GOLD to compile a grammar into a compiled grammar table
(which will be used by the parsing engine), it'll identify and report any
ambiguities, which, in LR parsing, fall in to one of two categories:
Reduce-Reduce conflicts: GOLD flags these as errors.
Shift-Reduce conflicts: GOLD flags these as warnings and attempts to resolve
them by always assuming shift. Sometimes that works out fine, sometimes it
doesn't. But it's best to minimize them in any case.
With either type of ambiguity, it'll tell you all about the offending
rule(s), and allow you to jump to a view of the related state in the LALR
state table. (It handles lex problems similarly.)
Does GOLD let you manually specify how to resolve the ambiguities? Cuz
you're going to have them with D, and murphy says they're going to be
reduce-reduce :)
All in all, she sounds pretty sweet. Maybe I'll try porting my D grammar
to GOLD when I'm past exams.
By the way, do you know if there be any way to put conditional
productions in GOLD grammars? Like if you wanted to have a grammar that
recognizes D1 or D2 dependent on a settable flag?
Wait wait wait wait, just looked on wikipedia, GOLD uses DFAs for
lexing??!!! Please tell me she can do context sensitive lexers,
otherwise how are you going to get perl-style strings let alone nesting
comments?
Re: dmd support for IDEs and the D tool chain
Hello Ellery, Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are in process where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something)
Re: dmd support for IDEs and the D tool chain
Hello Ellery,
But what I'm wondering about LALR is will it have to back up if it
chooses wrong,
LALR can't backup
or can it sail on through in one parse attempt. I bet
it can.
What it will do is parse the {, parse an expression and /then/ use what
comes next to decide what the stuff it already parsed is part of.
Re: dmd support for IDEs and the D tool chain
BCS wrote: Hello Ellery, Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are in process where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) Small world :) For some reason, my professor seems to be skipping LR parsing.
Re: dmd support for IDEs and the D tool chain
Christopher Wright dhase...@gmail.com wrote in message news:hbcg2t$20i...@digitalmars.com... Jacob Carlborg wrote: On 10/17/09 00:23, Christopher Wright wrote: Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse. And the tabs are everywhere, and no attempt was made to make them look native to any platform. And they take up an *enormous* amount of space. I can't actually use them and see their labels at the same time.
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbcq8b$av...@digitalmars.com... Does GOLD let you manually specify how to resolve the ambiguities? Cuz you're going to have them with D, and murphy says they're going to be reduce-reduce :) No. Reduce-reduce are errors and require adjusting the grammar accordingly, and shift-reduce require either accepting the resolve by assuming shift or adjusting the grammar. All in all, she sounds pretty sweet. Maybe I'll try porting my D grammar to GOLD when I'm past exams. By the way, do you know if there be any way to put conditional productions in GOLD grammars? Like if you wanted to have a grammar that recognizes D1 or D2 dependent on a settable flag? Not possible at this time, unfortunately. Wait wait wait wait, just looked on wikipedia, GOLD uses DFAs for lexing??!!! Please tell me she can do context sensitive lexers, otherwise how are you going to get perl-style strings let alone nesting comments? For anything that GOLD doesn't normally support (such as nested comments, more than one pair of block-comments, or indentation increase/decrease), it has a kludge called Virtual Terminals ( http://www.devincook.com/goldparser/doc/meta-language/virtual-terminals.htm ). These let you declare a terminal, but then leave it up to the lex/parse engine (ex, Goldie) to identify it however it sees fit. I plan to add a number of very useful ones to Goldie (such as nested comments). I also plan to make an alternate implementation of GOLD that will fill in some of the missing features.
Re: dmd support for IDEs and the D tool chain
Hello Ellery, BCS wrote: Hello Ellery, Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are in process where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) Small world :) For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :)
Re: dmd support for IDEs and the D tool chain
BCS n...@anon.com wrote in message news:a6268ffb7838cc1d4346bad...@news.digitalmars.com... Hello Ellery, BCS wrote: (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) Small world :) For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :) You should both feel lucky. The best I had was a class where we filled in the bodies of a handful of small functions in a trivial assembler (trivial meaning completely bare-minimum, and no actual lex/parse theory was used) that was written by the *cough* professor for a trivially simple fictitious CPU. And that was the *best* of the three colleges I've been to. (Cue Walter reminiscing about how great Caltech was... ;) )
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky a...@a.a wrote in message news:hbdana$27s...@digitalmars.com... Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbd6q8$1o5...@digitalmars.com... For some reason, my professor seems to be skipping LR parsing. Gold's documentation has a lot of good starting point information: http://www.devincook.com/goldparser/articles/lalr.htm http://www.devincook.com/goldparser/doc/meta-language/index.htm http://www.devincook.com/goldparser/doc/engine-pseudo/index.htm LR's are typically considered a little more powerful than LL (although ANTLR has pushed LLs impressively far), and they work in basically the opposite way. If you have: A -- B1 | B2 B1 -- foo1 | foo2 B2 -- foo3 | foo4 An LL, as you know, starts at the A and works it way down. But an LR starts by matching one of those foos and then works it's way up by reducing to one of the Bs and then to A. Also, you can use GOLD to actually step through the parsing process, so that's a very good way to get the hang of what's going on in an LR.
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbd6q8$1o5...@digitalmars.com... For some reason, my professor seems to be skipping LR parsing. Gold's documentation has a lot of good starting point information: http://www.devincook.com/goldparser/articles/lalr.htm http://www.devincook.com/goldparser/doc/meta-language/index.htm http://www.devincook.com/goldparser/doc/engine-pseudo/index.htm LR's are typically considered a little more powerful than LL (although ANTLR has pushed LLs impressively far), and they work in basically the opposite way. If you have: A -- B1 | B2 B1 -- foo1 | foo2 B2 -- foo3 | foo4 An LL, as you know, starts at the A and works it way down. But an LR starts by matching one of those foos and then works it's way up by reducing to one of the Bs and then to A.
Re: dmd support for IDEs and the D tool chain
BCS wrote: Hello Ellery, BCS wrote: Hello Ellery, Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. LALR needs to be able to unambiguously determine all the /completed/ productions to the left of each point by looking at nothing beyond the next token to the right. This might not be conservative enough, but I seem to remember that most parser corner cases don't crop up in practice. In general LL needs to known exactly what productions are in process where are LR needs to, at each level, have a finite set of options and only needs things to become unambiguous before it finishes a production. (BTW I'm taking (but haven't yet finished) a compilers class so I might be missing something) Small world :) For some reason, my professor seems to be skipping LR parsing. If mine did that I'd shoot him (a scorching e-mail :) It's probably because he can't make us write a LALR parser by hand.
Re: dmd support for IDEs
Andrei Alexandrescu wrote: One cool thing is combining sshfs with autofs. A cool thing I'd seriously never thought of. Time to autofs half my /mnt... -- Chris Nicholson-Sauls
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg Wrote: IDE: Descent Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's.
Re: dmd support for IDEs and the D tool chain
On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborg d...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. What we have now and what I think is the closest match: Compiler: LDC * Missing most of the mentioned things * Needs better platform support * At least the back-end is built like this We have DSSS and xfbuilder (or what it's called) GUI library: DWT * There are some bugs in the mac version * Doesn't support (de)serializing controls * Not built in a D-way * Maybe too heavy IDE: Descent * Missing some features like refactoring * Only supports building using an external tool * Needs to improve the syntax and semantic errors * Needs to improve the performance if possible GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses * To my knowledge none of the above supports a GUI library like the one mentioned Any comments, thoughts? /Jacob Carlborg GtkD supports Glade.
Re: dmd support for IDEs and the D tool chain
Denis Koroskin wrote: On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg d...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource. Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea.
Re: dmd support for IDEs and the D tool chain
On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig a...@esperanto.org.ar wrote: Denis Koroskin wrote: On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg d...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource. Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea. Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow.
Re: dmd support for IDEs and the D tool chain
On 10/16/09 12:58, Tomas Lindquist Olsen wrote: On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborgd...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. What we have now and what I think is the closest match: Compiler: LDC * Missing most of the mentioned things * Needs better platform support * At least the back-end is built like this We have DSSS and xfbuilder (or what it's called) GUI library: DWT * There are some bugs in the mac version * Doesn't support (de)serializing controls * Not built in a D-way * Maybe too heavy IDE: Descent * Missing some features like refactoring * Only supports building using an external tool * Needs to improve the syntax and semantic errors * Needs to improve the performance if possible GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses * To my knowledge none of the above supports a GUI library like the one mentioned Any comments, thoughts? /Jacob Carlborg GtkD supports Glade. Yes, but GtkD doesn't use native controls.
Re: dmd support for IDEs and the D tool chain
On 10/16/09 13:03, digited wrote: Jacob Carlborg Wrote: IDE: Descent Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's. I totally forgot about Poseidon. It has already been ported to the new DWT library, I don't know if it's complete and if it's running.
Re: dmd support for IDEs and the D tool chain
On 10/16/09 14:27, Denis Koroskin wrote: On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig a...@esperanto.org.ar wrote: Denis Koroskin wrote: On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg d...@me.com wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource. Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea. Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. Let us know when it's available
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg schrieb: On 10/16/09 13:03, digited wrote: Jacob Carlborg Wrote: IDE: Descent Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's. I totally forgot about Poseidon. It has already been ported to the new DWT library, I don't know if it's complete and if it's running. Needs debugging, but can run. I wanted to port it to the jface.text editor component, but lost motivation :)
Re: dmd support for IDEs and the D tool chain
Ary Borenszweig, el 16 de octubre a las 14:20 me escribiste: I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource. Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea. And the back-end is not free! You can't distributed and I don't think it can be ported. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- El techo de mi cuarto lleno de cometas
Re: dmd support for IDEs and the D tool chain
On Fri, 16 Oct 2009 20:11:25 +0400, Leandro Lucarella llu...@gmail.com
wrote:
Ary Borenszweig, el 16 de octubre a las 14:20 me escribiste:
I can't agree more. Everything you wrote is in my TODO list,
starting with a compiler, which already compiles most of the
druntime (and hopefully will compile it fully by the end of this
week). I'll release it to public as soon as Brad creates a project
page at dsource.
Is it a port of DMD? Because I think the main problem with above is
that the front-end is not very good... I think it has a lot of
evolved code and starting from scratch might be a good idea.
And the back-end is not free! You can't distributed and I don't think it
can be ported.
I see no point in porting backend. It's still in C++ and easily accessed
from D:
extern (C++) {
void obj_initfile(const(char)* filename, const(char)* csegname,
const(char)* modname);
Symbol* symbol_calloc(const(char)* id);
type* type_fake(tym_t);
dt_t** dtnzeros(dt_t** pdtend, targ_size_t size);
void outdata(Symbol* s);
dt_t ** dtnbytes(dt_t** pdtend, targ_size_t size, const(char)* ptr);
type* type_alloc(tym_t ty);
elem* el_ptr(Symbol*);
elem* el_bin(uint, tym_t, elem*, elem*);
// etc
}
(These functions could be then moved to a separate backend.dll so that
they would be shared between DMD and D-DMD and then only backend.dll would
need to be distributed)
Besides, Walter gave and explicit permission to Tango devs to distribute
dmd (alongside with a backend), so I believe this issue can be sorted out.
Walter?
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) We got this, dsss just has to be revived by someone. GUI library: * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) Not sure it needs to be written in D. Many languages use bindings and wrappers just fine. We already have QtD, DWT, wxWindows, DFL and GtkD. One of those is a port (DWT) and one is native D (DFL). The GUI situation has been so rapidly improved, it's not an impediment anymore imho. IDE: * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT Descent is probably the closest, in some aspects it even destroys C++ IDE's (compile time stuff) already. However one or two more IDE's or very good editors would likely help. This would be my shortlist: - a polished descent which supports D2 - dmd switch to ELF on windows and support for 64-bit there - dsss redux - gdc for embedded, also some more support from phobos for systems programming?
Re: dmd support for IDEs and the D tool chain
Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in).
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in). All but the hard parts :) I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do.
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbak0n$q5...@digitalmars.com... Nick Sabalausky wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in). All but the hard parts :) Yea, like I said, FWIW ;) I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example?
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky Wrote: Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbak0n$q5...@digitalmars.com... Nick Sabalausky wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in). All but the hard parts :) Yea, like I said, FWIW ;) I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example? There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing Cheers Justin Johansson
Re: dmd support for IDEs and the D tool chain
Justin Johansson n...@spam.com wrote in message news:hbamfa$v3...@digitalmars.com... Nick Sabalausky Wrote: Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbak0n$q5...@digitalmars.com... Nick Sabalausky wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in). All but the hard parts :) Yea, like I said, FWIW ;) I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example? There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing That mentioned, in the section about LL(k), If both AB and AB are legal expressions, where B can be of arbitrary length, then no finite amount of look-ahead will allow this to be parsed. I did a quick test in gold (LALR), and this handles the above just fine: -- Name= 'Test' Author = 'Test' Version = 'Test' About = 'Test' Start Symbol = Type1Or2 Type1Or2 ::= Type1 | Type2 Type1 ::= 'A' '' Bs Type2 ::= 'A' '' Bs '' Bs ::= 'B' | Bs 'B' -- However, that one example alone doesn't necessarily prove that it's always doable.
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbak0n$q5...@digitalmars.com...
Nick Sabalausky wrote:
Denis Koroskin 2kor...@gmail.com wrote in message
news:op.u1v7jdgco7c...@korden-pc...
Yes, it's a DMD port. Unfortunately, there is no other mature D
front-end
at present. Other folks are working on D compilers (dil, dang, ...) but
the progress is very slow.
FWIW, I've been meaning to try to write a D grammar for GOLD when I get a
chance (the Haxe grammar I wrote only took a few days). If that pans out
(depends just how simple and unambiguous the grammar is), then that could
be
used with Goldie as a starting point (ie, lex/parse would be taken care
of.
Semantic analysis, optimization and back-end would need to be added in).
All but the hard parts :)
Yea, like I said, FWIW ;)
I could count the number of places that are ambiguous syntactically or
semantically on one hand, and maybe the number of places that require
arbitrary lookahead also. Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could
you give me a simple example?
Well, let's see here...
PrimExp - structLiteral
PrimExp - functionLiteral
and suppose
structLiteral = { /* really, really looong expression*/ }
functionLiteral = { statement }
functionLiteral = { /* really, really looong expression*/ ; }
In an LL(k) parser, when you get to PrimExp, you have to know which
choice to make based on the first k lookahead characters (probably
translates to '{' and one token past that). Obviously, that won't work
for this piece, so it isn't LL(k). You have to try parsing the one, and
back up and parse the other if the first one fails (dmd should do this,
but currently it just looks ahead for the first semicolon. come to think
of it, I should try patching that..)
ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.
But what I'm wondering about LALR is will it have to back up if it
chooses wrong, or can it sail on through in one parse attempt. I bet it
can.
And how about actual ambiguity? How well does GOLD handle that?
Re: dmd support for IDEs and the D tool chain
Nick Sabalausky wrote: Justin Johansson n...@spam.com wrote in message news:hbamfa$v3...@digitalmars.com... Nick Sabalausky Wrote: Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:hbak0n$q5...@digitalmars.com... Nick Sabalausky wrote: Denis Koroskin 2kor...@gmail.com wrote in message news:op.u1v7jdgco7c...@korden-pc... Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. FWIW, I've been meaning to try to write a D grammar for GOLD when I get a chance (the Haxe grammar I wrote only took a few days). If that pans out (depends just how simple and unambiguous the grammar is), then that could be used with Goldie as a starting point (ie, lex/parse would be taken care of. Semantic analysis, optimization and back-end would need to be added in). All but the hard parts :) Yea, like I said, FWIW ;) I could count the number of places that are ambiguous syntactically or semantically on one hand, and maybe the number of places that require arbitrary lookahead also. Do LALR parsers care about arbitrary lookahead? LL(k) parsers do. Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could you give me a simple example? There are a zillion tutorials relating to parsing on the web. Try googling: parsing theory tutorial 2nd hit: An introduction to parsing That mentioned, in the section about LL(k), If both AB and AB are legal expressions, where B can be of arbitrary length, then no finite amount of look-ahead will allow this to be parsed. I did a quick test in gold (LALR), and this handles the above just fine: -- Name= 'Test' Author = 'Test' Version = 'Test' About = 'Test' Start Symbol = Type1Or2 Type1Or2 ::= Type1 | Type2 Type1 ::= 'A' '' Bs Type2 ::= 'A' '' Bs '' Bs ::= 'B' | Bs 'B' -- However, that one example alone doesn't necessarily prove that it's always doable. Bad example. Bs is regular. Try making it nested parens or something like that. (It isn't LL(k), but it is pretty trivial anyways. ANTLR3 can handle it without fuss)
Re: dmd support for IDEs and the D tool chain
Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance.
Re: dmd support for IDEs and the D tool chain
Lutger wrote Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, A large proportion of programming languages are bootstrapped. It is nosense to write D compiler in C, that means the D language author does not want to use D language. Does Walter Bright use D for any projects himself? Regards, Eric
Re: dmd support for IDEs and the D tool chain
Christopher Wright dhase...@gmail.com wrote in message news:hbarno$188...@digitalmars.com... Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. Probably not as minor as it might seem. I find eclipse ugly. And although I'd never really thought about it before, I have to admit, I think it *is* one of the many factors as to why it's always felt too bloated for my tastes. Besides, I can think of things (lots of things, in fact) that are pure steaming piles of (well, one can guess), but even despite that have still managed to gain widespread acceptance.
Re: dmd support for IDEs and the D tool chain
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbaom1$138...@digitalmars.com...
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hbak0n$q5...@digitalmars.com...
I could count the number of places that are ambiguous syntactically or
semantically on one hand, and maybe the number of places that require
arbitrary lookahead also. Do LALR parsers care about arbitrary
lookahead? LL(k) parsers do.
Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could
you give me a simple example?
Well, let's see here...
PrimExp - structLiteral
PrimExp - functionLiteral
and suppose
structLiteral = { /* really, really looong expression*/ }
functionLiteral = { statement }
functionLiteral = { /* really, really looong expression*/ ; }
In an LL(k) parser, when you get to PrimExp, you have to know which
choice to make based on the first k lookahead characters (probably
translates to '{' and one token past that). Obviously, that won't work
for this piece, so it isn't LL(k). You have to try parsing the one, and
back up and parse the other if the first one fails (dmd should do this,
but currently it just looks ahead for the first semicolon. come to think
of it, I should try patching that..)
ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.
But what I'm wondering about LALR is will it have to back up if it
chooses wrong, or can it sail on through in one parse attempt. I bet it
can.
I'll write up a test in a minute, but for the specific type of lookahead
you're talking about, that shouldn't be a problem for LR's in general
(including LALR). An LR doesn't start with 'PrimExp', it starts by looking
at that first '{'. At this point it doesn't give a rat's tiny hiney what
nonterminal the '{' is part of - it'll just consume more tokens until it
narrows down the list of possible matches to just one (or none, in the
case of a syntax error). And once that happens, it already knows all it
needs to know, and it moves on. So there's no looking ahead or backtracking
needed (except maybe for a one-token lookahead to see if the next token is
allowed and what possible matches it might rule out)
And how about actual ambiguity? How well does GOLD handle that?
When you use GOLD to compile a grammar into a compiled grammar table
(which will be used by the parsing engine), it'll identify and report any
ambiguities, which, in LR parsing, fall in to one of two categories:
Reduce-Reduce conflicts: GOLD flags these as errors.
Shift-Reduce conflicts: GOLD flags these as warnings and attempts to resolve
them by always assuming shift. Sometimes that works out fine, sometimes it
doesn't. But it's best to minimize them in any case.
With either type of ambiguity, it'll tell you all about the offending
rule(s), and allow you to jump to a view of the related state in the LALR
state table. (It handles lex problems similarly.)
Re: dmd support for IDEs
Sorry for the slow reply here; I keep getting sidetracked. On Mon, Oct 12, 2009 at 08:05:06PM -0500, Andrei Alexandrescu wrote: One cool thing is combining sshfs with autofs. That way the connection is automatically made when you first open a dir. For example, if I write: That looks cool. I'll have to look into it. What are the issues that you encountered? My big problem is just one of speed. I've been able to work around some of it by changing my editor config (moving vim's swap file to a local dir made the biggest difference), but there is still an annoying noticeable lag when reading and writing the file. I often edit files in a rapid way: make a small change, save, recompile+run or refresh the page if a web app - I want to see the changes as instantly as possible. The sshfs lag isn't much, but it adds up quickly when doing several small changes. I find that if any given task takes hours, I can be very patient, but if it takes milliseconds, I get annoyed easily! My problems invariably involve suspending the laptop to RAM or changing wireless connections, to then find sshfs blocked. I haven't encountered that, but I also work from my desktop. (Even when on my laptop, I tend to run most programs remotely from the desktop - this is one of the driving forces behind my D Windowing System project described in the other thread. (That, and I just want an easy, simple API for my common tasks in D - kill two birds with one stone, I figure.) Andrei -- Adam D. Ruppe http://arsdnet.net
Re: dmd support for IDEs
Sun, 11 Oct 2009 10:48:30 +, language_fan thusly wrote: Well since there is already a project working on an Eclipse plugin, I see little use for other IDEs at the moment. The D community is rather small and only a small amount of people are capable of developing and willing to donate their free time on free IDE development (commercial IDEs have small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market). BTW totally off-topic, but I just found out that IntelliJ IDEA has been jumped on the open source wagon. This probably makes it a bit more challenging to make money on the commercial IDE market.
Re: dmd support for IDEs
On 13/10/2009 07:07, Walter Bright wrote: Yigal Chripun wrote: regarding working on a remote machine: you can mount a remote file system through ssh and work localy on that remoted filesystem. I do that sometimes, but it's a problem when trying to run the compiler/debugger, as they need to run on the remote machine, not just locally g. Eclipse has integration for that. it can execute remote commands and has remote debugging - the local eclipse debugger UI speaks with a remote gdb session. and if you really prefer command-line, you can always use the terminal view. Also, mounting a remote filesystem fails on Windows. I know, that really sux. At least putty works. this requires a 3rd party tool on windows. iirc, WebDrive is free, and for 30$ you can get sftpDrive. (10 years ago, I wired up every room in the house with two RG6 cables and two Cat5 cables while it was under construction. Did it myself because the electrical contractor had no idea how to handle high frequency wires, I had to rip all his stuff out and do it over. I had no use for it at the time. I'm sure glad now it was done, everything I have seems to want to plug in to it! Anyhow, I have several machines with different OSs on them on the lan, and ssh to run them from a central location.)
Re: dmd support for IDEs
Walter Bright wrote: Bill Baxter wrote: That could be true, but you said the thing that prompted this idea was enterprise-y customers looking for an enterprise-y IDE. Vim ain't on that roster. This thread makes it fairly clear that this idea won't fill the bill for a full featured IDE. But I think supporting a lightweight one is still getting us closer. I completely agree, nobody will code a monster IDE like Eclipse or Visual Studio dedicated to D anytime soon. I have only respect for Descent, I use it on linux and it is really great. But Eclipse is killing me, there is no reason for an IDE to be that heavy, slow and unresponsive. How come a database server can pull off any data query from a multi-gigabyte database on disk in half a millisecond yet Eclipse can't seem to feel responsive when working with less than a hundred megabytes in system memory. (On that note, D needs a b-tree module among others :x) I really feel we need a dedicated D IDE to promote the language, and such an IDE needs to start somewhere, most only do syntax highlighting so far, which is trivial to implement. A compiler interface to at least get semantics information from the source files is therefore a *big* plus in that direction. XML output can also be used in so many different ways, for documentation, bindings, analysis and more. And JSON output can be used directly from any language with a very lightweight parser. Besides, this doesn't mean Walter is going to put everything on hold to implement this feature, I think he only wanted to get feedback on an idea he had so when he gets time to implement it, he knows what the community wants. Jeremie
Re: dmd support for IDEs
Hello Ary, Don wrote: Ary Borenszweig wrote: Michal Minich wrote somewhere else: --- You can try to download just bare Eclipse platform (which is just text editor) and install descent into it using Eclipse software updates. It starts up faster than C or Java version Eclipse and there is only D related stuff in the UI. http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-20090917 0800/index.php Under Platform runtime binary --- I tried it and it's true, it feels much lighter this way and you don't a lot of bloat in menus and other things. It would be great to put this on the Descent front page. I put it on the Installing the plugin page as soon as I saw it here. Thanks Michal Minich! You are welcome :) I use it this way from the beginning on both Windows and Ubuntu. I first installed Descent into Java Eclipse, but it was also first time I saw Java and Eclipse :) so I was quite overwhelmed by the lot functionality available and could not find which is for D and which for Java. This way it is more beginner friendly. Thank you for your hard work on Descent.
Re: dmd support for IDEs
language_fan wrote: Practical languages have lots of boiler-plate, and I can easily generate hundreds of lines of code with a couple of key combinations or mouse clicks. Can you give some examples? I can only think of some that generate some lines of code, not hundreds.
Re: dmd support for IDEs
Walter Bright Wrote: What do you think? moving ddoc to xml will also fix bug 2060
Re: dmd support for IDEs
Ary Borenszweig wrote: language_fan wrote: Practical languages have lots of boiler-plate, and I can easily generate hundreds of lines of code with a couple of key combinations or mouse clicks. Can you give some examples? I can only think of some that generate some lines of code, not hundreds. linq-to-sql
Re: dmd support for IDEs + network GUI (OT)
Nick Sabalausky wrote: Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? This is generally true, although see OnLive (http://www.onlive.com/). I hear it works better than you'd expect, but don't have much interest in actually trying it.
Re: dmd support for IDEs
Mon, 12 Oct 2009 22:07:34 -0700, Walter Bright thusly wrote: Yigal Chripun wrote: regarding working on a remote machine: you can mount a remote file system through ssh and work localy on that remoted filesystem. I do that sometimes, but it's a problem when trying to run the compiler/debugger, as they need to run on the remote machine, not just locally g. Also, mounting a remote filesystem fails on Windows. I know, that really sux. At least putty works. (10 years ago, I wired up every room in the house with two RG6 cables and two Cat5 cables while it was under construction. Did it myself because the electrical contractor had no idea how to handle high frequency wires, I had to rip all his stuff out and do it over. I had no use for it at the time. I'm sure glad now it was done, everything I have seems to want to plug in to it! Anyhow, I have several machines with different OSs on them on the lan, and ssh to run them from a central location.) Lucky you. Couple of friends of mine chose the 'data cabling' option from the electrical contractor for their new homes (maybe 2-3 years ago) when they were under construction. The rails on the wall were equipped with RJ11 connectors! Totally useless for LAN, but ok for phone cables and thus xDSL. Another note -- I would use virtualization these days when several OSs are needed.
Re: dmd support for IDEs + network GUI
Mon, 12 Oct 2009 19:53:32 -0400, Adam D. Ruppe thusly wrote: In addition to GUI components, I also want to support local file and sound access, along with a few other things. It sucks when you are using an X program and it decides to blare sound out of your home computer when you are using the app from your work computer! Or it is a real pain in the ass to have to save the file in X, then scp it over to open it in a local program. These things should Just Work, and it isn't hard to implement, so I'll be setting that up too. Nomachine NX does pretty much what you are describing here. It is not equivalent technically but very similar and backwards compatible.
Re: dmd support for IDEs + network GUI (OT)
David Gileadi f...@bar.com wrote in message news:hb24km$pm...@digitalmars.com... Nick Sabalausky wrote: Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? This is generally true, although see OnLive (http://www.onlive.com/). I hear it works better than you'd expect, but don't have much interest in actually trying it. Yea, I've heard of that. I'm extremely skeptical though. Even at *absolute* best, I still can't imagine it having less lag than one of those laggy HDTVs, which I already consider entirely inadequate for gaming. Plus they'd essentially have to have a whole high-end gaming rig (plus all the higher-end-than-usual video-capture/compression and network needs) for each simultaneous user, which I'd imagine would either make the subscription fee absurdly high, lead to 90's-AOL-style too-many-connection issues, or send them right into bankruptcy. It's just unnecessary bandwidth/latency bloat.
Re: dmd support for IDEs + network GUI
Mon, 12 Oct 2009 19:09:11 -0400, Nick Sabalausky thusly wrote: A different branch of the this topic started taking about (or rather, bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that was ass-backwards and that the focus should be the other way around: making desktop apps work on the web. [snip] And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? You have probably lived under a rock these days. This is the way the world is moving. If something can be made Web 2.0 compatible, it is also what will happen. A new platform might come up in 201x or 202x, but nowadays the best we have got is Web 2.0. Ever used twitter, facebook, google wave (or any google's services) etc. ? Large part of the online enterprises have already jumped on the wagon, not only early adopters. Modern browsers such as opera 10, firefox 3.5, safari, and chrome already support the latest standards.
Re: dmd support for IDEs
Tue, 13 Oct 2009 10:33:54 +0200, Ary Borenszweig thusly wrote: language_fan wrote: Practical languages have lots of boiler-plate, and I can easily generate hundreds of lines of code with a couple of key combinations or mouse clicks. Can you give some examples? I can only think of some that generate some lines of code, not hundreds. For instance simple things like setters and getters for an aggregate class easily generate tens of lines of code (well, not only code lines, but also other kinds of editable lines). Like lutger said, all kinds of transformations also come in mind in this context. There could be even ORM mapping utilities which generate all the code for accessing the database structures.
Re: dmd support for IDEs + network GUI
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.179.1255391198.20261.digitalmar...@puremagic.com... My DWS project aims to work up on a widget level. It isn't quite as visually fancy as what you are describing (though it could grow into it later), but works on a high enough level of abstraction to be fast - and cross platform. Here's another thought I've had that I forgot to mention before. Just tossing it out there, don't know if you've looked into it or not: Instead of (or, better yet, in addition to) a special network-GUI toolkit, what about a server (kind of like a modified version of remote desktop) that actually queries the OS to find out about all the GUIs running on the system, and details about all their controls, relays that info to the client to reproduce, and accepts input back from the client like a softwareKVM would? It probably wouldn't work quite as well as a special network-GUI toolkit (it would probably have to detect and handle Win32/GTK/Delphi apps seperately, it probably wouldn't be able to do everything 100%, and it wouldn't be able to do any of the smart client tricks you have up your sleeve), but it would allow for at least some basic compatibility with apps that weren't specifically coded for a special network-GUI toolkit. Regarding the technical feasability of gaining information on all the controls of the running processes, I could swear I've seen some Windows program (some dev tool IIRC) that was able to detect that stuff from Win32 and Delphi apps, although I have no recoloction what what in the world that program was... I have no idea as to the feasability on Mac or Unix.
Re: dmd support for IDEs
language_fan wrote: Lucky you. Couple of friends of mine chose the 'data cabling' option from the electrical contractor for their new homes (maybe 2-3 years ago) when they were under construction. The rails on the wall were equipped with RJ11 connectors! Totally useless for LAN, but ok for phone cables and thus xDSL. What my electrical contractor did was install Cat 3, daisy chain them together, run them through the same holes as the AC wiring, have them touching the heating ducts, sharp bends, cable so cheap the insulation was already cracking on it, etc. He did everything wrong. But that probably wouldn't be a problem today. Another note -- I would use virtualization these days when several OSs are needed. I tried that and gave up on it: 1. virtual box wouldn't work, until I downloaded the sun version 2. upgrading Ubuntu cause them to all cease functioning
Re: dmd support for IDEs
Hello Yigal, On 13/10/2009 07:07, Walter Bright wrote: Yigal Chripun wrote: regarding working on a remote machine: you can mount a remote file system through ssh and work localy on that remoted filesystem. I do that sometimes, but it's a problem when trying to run the compiler/debugger, as they need to run on the remote machine, not just locally g. Eclipse has integration for that. it can execute remote commands and has remote debugging - the local eclipse debugger UI speaks with a remote gdb session. and if you really prefer command-line, you can always use the terminal view. Darn I so want this. Do you have links? Does the GDB thing work from from a Win client and a running GDB on Linux?
Re: dmd support for IDEs
On 14/10/2009 03:54, BCS wrote: Hello Yigal, On 13/10/2009 07:07, Walter Bright wrote: Yigal Chripun wrote: regarding working on a remote machine: you can mount a remote file system through ssh and work localy on that remoted filesystem. I do that sometimes, but it's a problem when trying to run the compiler/debugger, as they need to run on the remote machine, not just locally g. Eclipse has integration for that. it can execute remote commands and has remote debugging - the local eclipse debugger UI speaks with a remote gdb session. and if you really prefer command-line, you can always use the terminal view. Darn I so want this. Do you have links? Does the GDB thing work from from a Win client and a running GDB on Linux? http://www.eclipse.org/dsdp/tm/
Re: dmd support for IDEs
On 11/10/2009 23:13, Walter Bright wrote: Leandro Lucarella wrote: Walter Bright, el 11 de octubre a las 02:38 me escribiste: Lutger wrote: What about file/line/column of the symbol? Is this much work / hard work to add? file/line of course, but I don't see a point to column. See Clang error messages: http://clang.llvm.org/diagnostics.html That's *nice* =) I agree, it looks good on paper. In fact, I implemented it in the C and C++ compiler from the beginning (1982 or so). It's still in dmc, try it - it'll print out the error message, followed by the source text of the offending line, followed by a ^ under where things went wrong. Nobody cared. Nobody has ever commented on it - and there have been hundreds of thousands of users of it. No magazine review ever mentioned it. When I mention it to people as cool, look at this they never respond. When the conversation is about the quality of error messages, that feature never comes up. So I dropped it for dmd. Nobody noticed. Nobody asked why it was done for dmc, and not for dmd. Nobody asked for it. Nothing. (Until now.) So I am hard pressed to believe this is a worthwhile feature. There is a cost to it in memory consumption and compiler execution time, so it's not quite free. You assume everyone who uses DMD also uses DMC which is not necessarily the case. More importantly, while this is a good feature, it is far better to have squiggly red lines in the IDE. I for one rely on those lines a lot.
Re: dmd support for IDEs
On 12/10/2009 07:33, Jeremie Pelletier wrote: Jérôme M. Berger wrote: Jeremie Pelletier wrote: I agree however that GTK being in C is rather annoying, C is a great language but GUIs is one area where OOP really shines. Note that Gtk *is* object oriented despite being in C... Jerome It's a sorry hack, you have to use casts everywhere you'd rely on polymorphism in D or C+ and its harder to remember, read, code, maintain, and doesn't have any performance gains over C++, the explicit struct pointer in C is the implicit 'this' in C++ and non-virtual methods can be optimized as direct calls with no vtbl indirections. I tried gtkD and I don't like using an OOP layer on top of a C interface because that adds overhead for the exact same features, most good GUI libraries should abstract the platform anyways so GTK is usually only seen there and not in user code. It's still more fun to use than the Windows' windowing API, which doesn't even support layout objects such as boxes and grids, now that's total pain! what about MS' WPF? It has all the bells and whistles of modern UI, doesn't it?
Re: dmd support for IDEs
Nick Sabalausky wrote: Jeremie Pelletier jerem...@gmail.com wrote in message news:hats2b$as...@digitalmars.com... Lutger wrote: Jacob Carlborg wrote: ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. Qt used to try and look like native controls, but now it uses them directly. It has pros and cons, Firefox too has the native look and feel without using the native controls, so it saves on the overhead of tons of GDI handles and can render the entire GUI in cairo. I use FF a lot and umm...no it doesn't. Not remotely. It's always stood out as every bit of a blatant GTK app as GAIM, GIMP, or Thunderbird. As soon as I can find a browser with equivilents too all my essential hacks (*cough* extensions) and *real* controls (which rules out IE and Opera. And Chrome/Safari... AH HA HA HA!), then I'm ditching this garbage. Are you talking about FF 3.5? It's a really poor product. Crashes all the time, has some terrible UI misfeatures. I'm really amazed they shipped it in that condition.
Re: dmd support for IDEs
Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote: Denis Koroskin wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright newshou...@digitalmars.com wrote: If anyone is interested and is willing to test and/or help, I will gladly share my code. Oooo.. You should put that on dsource or somewhere. Hacking D sounds like a lot more fun than hacking C++. I wouldn't mind helping out on this one. Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was there a good reason to start yet another port of it?
Re: dmd support for IDEs
Sun, 11 Oct 2009 12:44:08 -0400, Jeremie Pelletier thusly wrote: language_fan wrote: Well since there is already a project working on an Eclipse plugin, I see little use for other IDEs at the moment. The D community is rather small and only a small amount of people are capable of developing and willing to donate their free time on free IDE development (commercial IDEs have small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market). So why not concentrate on fixing the spec and fixing compiler bugs instead of building a modest IDE support no one will use? Eclipse is heavy, slow and often unresponsive. I use poseidon myself because it is light and fast and I don't require much more from an IDE at the moment. If you turn off all the advanced features of Eclipse (spell checking, interactive parsing type checking etc), it will become a lot more responsive. You can even uninstall many of the plugins if you really do not need them. I recommend firing up the latest development build with the latest 1.6 jvm. It will take couple of seconds for the JIT to spot the hot spots after starting up. Of course Poseidon is faster *now* that it lacks all the advanced features, but once you start adding more, it will eventually grind to a halt.
Re: dmd support for IDEs
Eclipse is heavy, slow and often unresponsive. I use poseidon myself because it is light and fast and I don't require much more from an IDE at the moment. You can try to download just bare Eclipse platform (which is just text editor) and install descent into it using Eclipse software updates. It starts up faster than C or Java version Eclipse and there is only D related stuff in the UI. http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php Under Platform runtime binary
Re: dmd support for IDEs
Ary Borenszweig Wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out an
xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo. -- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field Bar
property. How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say Bah, just show all the declarations inside the
template in the autocomplete, but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of auto foo. Again, maybe the IDE can be dummy and see auto foo = new
Foo!(Bar) and say ok, foo's type is Foo!(Bar), but then you have:
auto b = foo.property;
b. -- and here?
// remember property is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
A lot of people like me have been waiting for a good IDE for D for a long time.
In the field of IDE of D, Descent has already have a good baseline. So I think
the community should put more effort in make Descent better, other than create
another IDE.
For this reason, I think Ary Borenszweig's opinion on in which way can dmd help
in building a better IDE may be more valuable than Water's, for he is the
author of the currently most advanced IDE of D.
Sorry for my poor English.
Re: dmd support for IDEs
Sun, 11 Oct 2009 16:07:44 -0300, Leandro Lucarella thusly wrote: Walter Bright, el 10 de octubre a las 18:19 me escribiste: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). I think you've got that answer because they are not using D alread. When they start using D, they will start complaining about Phobos vs. Tango, debugger support, librararies, bugs, etc. ;) (maybe not DMD being GPL though, even when I think it's important). What can I say, the larger the enterprise, the larger the expectations and need for stability. You can try it yourself, any Java 1.4 code from 2003 can be compiled, debugged, profiled etc. nicely with the most recent version of jdk and 3rd party tools. It's also nicely compatible with new code. OTOH take some D 1.0 code from 2003 (e.g. the free dool/dui or aba games code available online) and try to do *something* with it. Basically nothing works. You even have problems with new code as some project depends on a specific svn version of tango trunk. There is a lot to be done before D is ready for large scale enterprise use.
Re: dmd support for IDEs
Sun, 11 Oct 2009 17:01:03 -0400, Nick Sabalausky thusly wrote: language_fan f...@bar.com.invalid wrote in message news:hasd5u$1fg...@digitalmars.com... Well since there is already a project working on an Eclipse plugin, I see little use for other IDEs at the moment. The D community is rather small and only a small amount of people are capable of developing and willing to donate their free time on free IDE development (commercial IDEs have small potential now that Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market). So why not concentrate on fixing the spec and fixing compiler bugs instead of building a modest IDE support no one will use? Any editor that is less responsive than notepad is useless to me, and I'm far from alone on that. Thus, we don't go anywhere near Eclipse, VS.NET, or anything along those lines (bunch of bloated garbage...and probably designed to get developers to buy fancier hardware and thus end up develop apps that require their users to buy fancier hardware). Fine, if you are happy with your productivity. For me it was a natural choice. I started with notepad like editors, then moved to programmer's editors like crimson editor and jedit, soon discovered vim and emacs, and finally have settled down on Eclipse, Netbeans, Visual Studio, and IntelliJ IDEA. The productivity boost is enormous. Practical languages have lots of boiler-plate, and I can easily generate hundreds of lines of code with a couple of key combinations or mouse clicks. Another killer feature is the intellisense stuff. Having the ability to see a) inferred type b) integrated html rendered javadoc c) type correct class members etc. saves me hours of work time per day. YMMV
Re: dmd support for IDEs
On 10/12/09 02:08, Jeremie Pelletier wrote: Lutger wrote: Jacob Carlborg wrote: ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. Qt used to try and look like native controls, but now it uses them directly. It has pros and cons, Firefox too has the native look and feel without using the native controls, so it saves on the overhead of tons of GDI handles and can render the entire GUI in cairo. In the Mac version for a long time they used the older tabs from Mac OS X 10.4 or even older. That's the problem not using native controls, if the operating system change them it's a lot of more work to update your application.
Re: dmd support for IDEs
On 10/12/09 04:14, Chad J wrote: Jeremie Pelletier wrote: Lutger wrote: Jacob Carlborg wrote: ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. Qt used to try and look like native controls, but now it uses them directly. It has pros and cons, Firefox too has the native look and feel without using the native controls, so it saves on the overhead of tons of GDI handles and can render the entire GUI in cairo. I actually rather dislike GTK from a user standpoint. It doesn't mesh well at all on my KDE linux setup. The file dialog is also a frequent source of annoyance, as it is different then everything else and seems to want to fight with me. Qt is much better at these things. Too bad we can't just make programs switch between GUI backends at will ;) Why not have a GUI toolkit available on almost all platforms that uses native controls just like DWT?
Re: dmd support for IDEs
Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote: On 10/12/09 04:14, Chad J wrote: Too bad we can't just make programs switch between GUI backends at will ;) Why not have a GUI toolkit available on almost all platforms that uses native controls just like DWT? The list of native platforms SWT supports is this: Win32 WPF (under development) AIX, FreeBSD, Linux, HP-UX, Solaris: Motif GTK+ Mac OS X: Carbon Cocoa QNX Photon Pocket PC As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to see how SWT is more native than the ones I develop for. All SWT applications look weird, unthemed, and have horrible usability issues in the file open/save dialogs. DWT brings another level of cruft above the lightweight SWT and performs badly.
Re: dmd support for IDEs
Sat, 10 Oct 2009 18:19:56 -0700, Walter Bright thusly wrote: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file. The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax. What do you think? Another point not mentioned here is that modern IDEs use incremental and interactive compilation model. The compiler should be run as a persistent background process and parsing should happen perhaps on the level of the current scope. Re-compiling a million line project after each key stroke simply makes no sense. Even compiling the current module once per key stroke is too slow. Specifying an intermediate json/xml file format is a huge task considering the amount of language constructs, types etc. available in D. I'm all for good tool support but as many have already mentioned, the support would only bring marginal improvements to small scale tools like vim and emacs. Usually small scale D projects ( 1 lines of code) are written with those tools (feel free to prove me wrong). These are not the kinds of projects large enterprises would use D for, they use scripting languages for smaller tasks. Thus the overall improvement is minimal. Spending the time on critical compiler bugs on the other hand would help everyone in the community.
Re: dmd support for IDEs
On 12/10/2009 11:41, breezes wrote:
Ary Borenszweig Wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out an
xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo.-- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field Bar
property. How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say Bah, just show all the declarations inside the
template in the autocomplete, but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of auto foo. Again, maybe the IDE can be dummy and see auto foo = new
Foo!(Bar) and say ok, foo's type is Foo!(Bar), but then you have:
auto b = foo.property;
b.-- and here?
// remember property is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
A lot of people like me have been waiting for a good IDE for D for a long time.
In the field of IDE of D, Descent has already have a good baseline. So I think
the community should put more effort in make Descent better, other than create
another IDE.
For this reason, I think Ary Borenszweig's opinion on in which way can dmd help
in building a better IDE may be more valuable than Water's, for he is the
author of the currently most advanced IDE of D.
Sorry for my poor English.
What I definitely don't like is that Decent is just a Eclipse plugin. I
don't want a Java IDE plus D.
I would prefer a pure D IDE.
Being a Netbeans guy but I am pretty sure that it is possible to remove
all the Java related things. side effects : less bloat more speed.
my 2 euro cents
Re: dmd support for IDEs
On Sun, 11 Oct 2009 09:32:32 -0500, Denis Koroskin 2kor...@gmail.com wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright newshou...@digitalmars.com wrote: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file. The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax. What do you think? I believe it won't work. It will always be slow and incomplete. Instead, I would make it easier to embed DMD into an IDE: separate DMDFE from DMDBE, fix memory leaks, remove all the static data (so that code would be re-intrable and it could work in different threads in parallel), move most of DMD code into a DLL so that an IDE could dynamically link with it and whatever it pleases with the source code. In fact, that's what I do right now. I'm writing my own D IDE in my spare time (in D, of course). I already made a lot of progress and now it's time to start implementing source code analysis. First thing I did is I made complete D bindings for C++ code. It worked out quite well but it was leaking so badly that I dropped it. Instead, I started porting DMD entirely to D (except the backend, of course), and I already got some great results. A few simple programs compile and produce byte-perfect binaries. It's still in its early stages and there is a lot of work to do, but it will be finished soon (hopefully). It could probably become a part of an official distribution, eventually. :) If anyone is interested and is willing to test and/or help, I will gladly share my code. I would like it if this went open so I could examine it and possibly contribute to it. I have wanted to do something like this, but all I have started so far is a GUI toolkit. I am new to D so I have not spent much time on it yet. It would be nice to be able to work on something more developed. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: dmd support for IDEs
BLS wrote:
On 12/10/2009 11:41, breezes wrote:
Ary Borenszweig Wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out an
xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo.-- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field Bar
property. How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say Bah, just show all the declarations inside the
template in the autocomplete, but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of auto foo. Again, maybe the IDE can be dummy and see auto foo = new
Foo!(Bar) and say ok, foo's type is Foo!(Bar), but then you have:
auto b = foo.property;
b.-- and here?
// remember property is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
A lot of people like me have been waiting for a good IDE for D for a
long time. In the field of IDE of D, Descent has already have a good
baseline. So I think the community should put more effort in make
Descent better, other than create another IDE.
For this reason, I think Ary Borenszweig's opinion on in which way can
dmd help in building a better IDE may be more valuable than Water's,
for he is the author of the currently most advanced IDE of D.
Sorry for my poor English.
What I definitely don't like is that Decent is just a Eclipse plugin. I
don't want a Java IDE plus D.
I would prefer a pure D IDE.
Being a Netbeans guy but I am pretty sure that it is possible to remove
all the Java related things. side effects : less bloat more speed.
my 2 euro cents
No, but that's the good thing about it: it's just a
Re: dmd support for IDEs
Ary Borenszweig wrote: Michal Minich wrote somewhere else: --- You can try to download just bare Eclipse platform (which is just text editor) and install descent into it using Eclipse software updates. It starts up faster than C or Java version Eclipse and there is only D related stuff in the UI. http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php Under Platform runtime binary --- I tried it and it's true, it feels much lighter this way and you don't a lot of bloat in menus and other things. It would be great to put this on the Descent front page.
Re: dmd support for IDEs
language_fan wrote: Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote: Denis Koroskin wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright newshou...@digitalmars.com wrote: If anyone is interested and is willing to test and/or help, I will gladly share my code. Oooo.. You should put that on dsource or somewhere. Hacking D sounds like a lot more fun than hacking C++. I wouldn't mind helping out on this one. Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was there a good reason to start yet another port of it? Maybe learning, porting a library or application from a language to another is a great way to learn about it inside out. I used to do that a lot too.
Re: dmd support for IDEs
Yigal Chripun wrote: On 12/10/2009 07:33, Jeremie Pelletier wrote: Jérôme M. Berger wrote: Jeremie Pelletier wrote: I agree however that GTK being in C is rather annoying, C is a great language but GUIs is one area where OOP really shines. Note that Gtk *is* object oriented despite being in C... Jerome It's a sorry hack, you have to use casts everywhere you'd rely on polymorphism in D or C+ and its harder to remember, read, code, maintain, and doesn't have any performance gains over C++, the explicit struct pointer in C is the implicit 'this' in C++ and non-virtual methods can be optimized as direct calls with no vtbl indirections. I tried gtkD and I don't like using an OOP layer on top of a C interface because that adds overhead for the exact same features, most good GUI libraries should abstract the platform anyways so GTK is usually only seen there and not in user code. It's still more fun to use than the Windows' windowing API, which doesn't even support layout objects such as boxes and grids, now that's total pain! what about MS' WPF? It has all the bells and whistles of modern UI, doesn't it? Isn't that just a pretty layer on top of win32/com? I now only use native toolkits as backends for my gui abstraction layer, using this would only add a level of indirection and make no sense.
Re: dmd support for IDEs
On Mon, 12 Oct 2009 12:58:56 +0400, language_fan f...@bar.com.invalid wrote: Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote: Denis Koroskin wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright newshou...@digitalmars.com wrote: If anyone is interested and is willing to test and/or help, I will gladly share my code. Oooo.. You should put that on dsource or somewhere. Hacking D sounds like a lot more fun than hacking C++. I wouldn't mind helping out on this one. Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was there a good reason to start yet another port of it? I know about DParser, but it's somewhat outdated, incomplete and doesn't support code generation. It also diverged from DMD quite a lot so fixing it would be quite hard (I, too, plan to make it more D-ish - get rid of casts, replace void* Arrays with type-safe equivalents etc - but not until it is 100% ready). I just believe rewriting it from scratch will be plain faster. I can also test the code much easier - if it produces exact same binary then it works correct.
