free full ecm2001 titanium crack torrent rapidshare download free LU,touTkc
We can crack or emulate any protection type: Dongle, Hardlock, Hasp, Serial, Password, Hasp4, Flexlm, Sentinel, Wibu, Eutron Smartkey, Hasphl, Proteq, All the Protections!! email = yshows...@??? email = yshowsoft at gmail.com ecm2001 titanium download ecm2001 titanium rapidshare titanium ecm2001 torrent ecm2001 titanium crack ecm2001 titanium v 5.3 titanium ecm2001 v 5.4 titanium ecm2001 v 5.5 titanium ecm2001 v 6.0 titanium ecm2001 v 6.1 ecm2001 v 6.2 ecm2001 v 6.3 ecm2001 v5.3 ecm2001 v5.4 ecm2001 v5.5 ecm2001 v6.0 ecm2001 v6.1 ecm2001 v6.2 ecm2001 v6.3 If you have some protected program, and want to crack it, we can help you! Ecm2001 v6.3 professional, all checksums enabled download SHOEMASTER v3.04 all modules download Victor EAT Designscope 2.05 all modules Ricardo Wave Software 5.1 r Elcometer EDCS Plus + Optitex 9.03 and 9.2 all modules DVP 5.3 Complete W/S, Aero Triangulation, Vectorization, AT, Orthomosaic SDS Steel Detailing System v 6.34 Full Aspen Oneliner/Power Flow version 9 crack SES CDEGS 10.1.6 Full - All modules crack ecmfull Scanvec Amiable Flexi Family 7.6 Scanvec Amiable FlexiSIGN PRO 7.5 Scanvec Amiable Flexi EXPERT Scanvec Amiable FlexiSIGN Scanvec Amiable FlexiLETTER Scanvec Amiable FlexiDESIGNER Scanvec Amiable PhotoPRINT Family 4 Scanvec Amiable PhotoPRINT SERVER PRO Scanvec Amiable PhotoPRINT SERVER Scanvec Amiable PhotoPRINT DX Scanvec Amiable PhotoPRINT SE Scanvec Amiable EnRoute Family 3 Scanvec Amiable EnRoute Pro Scanvec Amiable EnRoute Plus Scanvec Amiable EnRoute Basic Scanvec Amiable EnRoute Wood Bentley Advanced Routing and Permitting System (ARPS) Bentley AutoPLANT Equipment Bentley AutoPLANT Isometrics Bentley AutoPLANT PID Bentley AutoPLANT Structural Detailer Bentley AutoPLANT Structural Engineering Bentley AutoPLANT Structural Modeler Bentley Architecture 8 Bentley Arenium Bentley AutoPIPE Bentley AXSYS Engine Bentley AXSYS Integrity Bentley AXSYS Process Bentley CloudWorx 03 Bentley Coax Bentley Connectors Bentley Copper Bentley Data Manager Bentley Datasheets Bentley Descartes 8 Bentley Driver Packs Bentley eWarehouse Bentley Explorer 2004 Bentley Explorer Interference Detection Bentley Explorer NWD Export Bentley Explorer Photorealism Bentley Facilities Inquirer Bentley Facilities Manager Bentley Facilities Planner Bentley Facilities Reports Bentley Fiber Bentley Geo Web Publisher Bentley Geospatial Management Bentley Hookups Bentley HVAC 8 Bentley I/RAS B Bentley Inside Plant Bentley Instrumentation Wiring Bentley Interference Manager Bentley Knowledge Manager Bentley MXRAIL Bentley MXRENEW Bentley MXROAD Bentley MXSITE Bentley MXURBAN Bentley Navigator Bentley Piping Bentley PlantFLOW Bentley PlantSpace IsoExtractor Bentley PowerCivil Bentley PowerDraft Bentley PowerMap Bentley PowerMap Field Bentley PowerSurvey Bentley ProjectWise Connector for ArcGIS Software Bentley ProjectWise Connector for Oracle Bentley Publisher Bentley PULS Bentley Redline Bentley Structural Bentley Transportation Data Manager (TDM) Bentley View Bentley Vision Bentley Wastewater Bentley Water Bentley CivilStorm Bentley CulvertMaster Bentley Darwin Calibrator Bentley Darwin Designer Bentley Digital InterPlot Bentley Elementary Electrical Diagrams (EED) Bentley FlowMaster Bentley GeoMacao Bentley GEOPAK Bridge Bentley GEOPAK Civil Engineering Suite Bentley GEOPAK Rebar Bentley GEOPAK Site Bentley GEOPAK Survey Bentley HAMMER Bentley InRail Bentley InRoads 2004 Bentley InRoads Bridge Bentley InRoads Site Bentley InRoads Site Suite Bentley InRoads Storm Sanitary Bentley InRoads Suite Bentley InRoads Survey Bentley Location Data Manager (LDM) Bentley Location Data Manager Express (LDMx) Bentley MicroStation Bentley MicroStation GeoGraphics Bentley PlantSpace Equipment Bentley PlantSpace Isometrics Bentley PlantSpace Orthographics Bentley PlantSpace PID Bentley PlantSpace Raceways Bentley PlantSpace SupportModeler Bentley PondPack Bentley ProjectWise Bentley ProjectWise Extensions Bentley Right of Way Office Bentley SewerCAD Bentley SewerGEMS Bentley Skelebrator Bentley StormCAD Bentley WaterCAD Bentley WaterGEMS Bentley WaterSAFE Bentley WinNOZL email = yshows...@??? email = yshowsoft at gmail.com @Zknsx$HFZ
another d demoscene entry
Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip
Re: another d demoscene entry
Why is my post duplicated ? I use Web-News.
another d demoscene entry
Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip
Re: another d demoscene entry
#ponce wrote... Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip Fragment Shader not supported by HW :(
Re: another d demoscene entry
#ponce wrote: Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip Congrats! You're on a roll! I've just watched the demo (works beautifully of my GTX260 on Win7) and damn... this is some trippy s**t :D The final touch with quickly going backwards was particularly jaw-dropping. Great job, guys. Keep it up! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: another d demoscene entry
在 Mon, 12 Oct 2009 09:07:49 +0800，#ponce alil...@gmail.com 写道: Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip Awesome work！The vid rocks! -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Re: another d demoscene entry
#ponce wrote: Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip Loved it, ran smoothly in 1920x1200 on my laptop! That was some trippy graphics, very nice shader effects too, and the animations were so fluid. It made me remember my college days.. :D I'm definitely gonna dig into the source, the code doesn't look too complex from the few files I read so far and I might learn a few things. How about a Beatles medley demo next time? In any ways, great job! Jeremie
Re: another d demoscene entry
On 12.10.2009 03:07, #ponce wrote: Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip I only get a black screen, but with music. Can't see any errors in the log. I've got a Radeon mobility hd 3650. Is my gfx card no up to it?
Re: another d demoscene entry
*droo* Good trip man. Thanks for that. Neat to see D getting use in the demoscene.
Re: another d demoscene entry
#ponce alil...@gmail.com wrote in message news:hatvh5$gq...@digitalmars.com... Hi, We won another demo compo with a D entry (at MAIN demoparty) http://www.pouet.net/prod.php?which=53942 We tried to make a bigger and more impressive entry this time. Note that it's a french party so it's not Breakpoint. D clearly allowed us to be more productive without a demotool. Still, mature demotools are one order of magnitude more productive (and awfully long to make). To be honest i don't expect demosceners to switch so easily from C++ but it could encourage some newcomers (like us) with a small code base. I just released the source (again under WTFPL). http://adinpsz.org/data/az-02_-_Extatique_src.zip az02.exe crashed upon starting with no error/warning in the log.
dmd 1.049 and 2.034 release
Folding in patches to compiler faults from bugzilla. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.049.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.034.zip Many thanks to the numerous people who contributed to this update.
Re: dmd 1.049 and 2.034 release
Jeremie Pelletier wrote: What already? Seems like 2.033 was only a week ago.. oh wait. It was only a week ago!
Re: another d demoscene entry
torhu wrote: I only get a black screen, but with music. Can't see any errors in the log. I've got a Radeon mobility hd 3650. Is my gfx card no up to it? That's what happens when you cross AMD/ATI with OpenGL. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: another d demoscene entry
Tom S wrote: torhu wrote: I only get a black screen, but with music. Can't see any errors in the log. I've got a Radeon mobility hd 3650. Is my gfx card no up to it? That's what happens when you cross AMD/ATI with OpenGL. Strange, my first steps in OpenGL years ago were on my 'old' 1950xtx, I never had any issues with ATI and GL. It's most likely an issue in the code than the card, like trying to use an extension not present in the driver (the function pointers to that extension are then null).
Re: dmd support for IDEs
Jeremie Pelletier wrote: The IDE usually keeps the files in memory and could therefore just call something like getSemantics(char** fileBuffers, int* fileSizes, int nFiles, ParseNode* parseTree) and have its parse nodes already allocated in process memory ready for use. Considering a lot of IDEs like to re-parse the current file every time the keyboard is idle for a few seconds, this could really help performance, nothing is more annoying than an IDE that feels unresponsive. I understand and agree, but we are operating under severe manpower constraints. I don't have a 100 million dollar budget! (I'm sure MS spends more than that on VS.) You're certainly welcome to take the compiler front end and try and make a dll out of it or integrate it directly into an IDE. But what I suggested would probably get a lot of results for a minimal investment in the front end and a minimal investment in existing IDEs. My experience with making responsive interactive apps on slow machines suggests that using a multithreaded approach would make the IDE responsive even if the underlying parsing process is slow. What you do is, every time the source file changes, fire off a background thread at a low priority to reparse. If the source changes before it finishes, restart that thread. When the IDE actually needs the results, it uses the results of the most recently finished parse. With this approach, there won't be any hangs where the keyboard is unresponsive. Experience also suggests that using fork/exec rather than a shared dll approach is much more robust and easier to develop. The reason is that the former uses separate processes, which cannot step on each other. The latter puts everything in one process space, where you've got all the lovely, time-consuming, hair-pulling concurrency problems. The utter failure of the parse process also cannot bring down the IDE.
Re: dmd support for IDEs
Walter Bright wrote: Experience also suggests that using fork/exec rather than a shared dll approach is much more robust and easier to develop. The reason is that the former uses separate processes, which cannot step on each other. The latter puts everything in one process space, where you've got all the lovely, time-consuming, hair-pulling concurrency problems. The utter failure of the parse process also cannot bring down the IDE. In particular, if the compiler seg faults (does it ever do that? g) it won't stop the IDE.
Re: dmd support for IDEs
Jeremie Pelletier wrote: The official JSON website has tons of bindings, here's the C one: http://fara.cs.uni-potsdam.de/~jsg/json_parser/ I'm gonna try and get it converted to D over the weekend. It has a test suite with it!
Re: dmd support for IDEs
Walter Bright: but we are operating under severe manpower constraints. I don't have a 100 million dollar budget! And sometimes this is even an advantage, because it forces to keep things simple and not over-engineered :-) Bye, bearophile
Re: dmd support for IDEs
Walter Bright дµ½: 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? See here http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=93086
Re: Phobos.testing
On Sun, 11 Oct 2009 07:06:30 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei It's great for Boost, because Boost has an extremely large user base. Besides, Boost is large enough already and there are a lot of people who is willing to contribute, so a very strict policy is needed. Phobos is not like Boost. I believe a more open policy is required to make people contribute to it. For example, Tango is open to everyone, that's why it evolves so fast. Although small, contributions are made in a daily basis by a lot of people. They are not contributing entire libraries, of course, some small bug-fixes, performance improvements, typos, name change (for consistency), etc. Step-by-step it is getting better and better. On the contrary, Phobos has stalled. I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks.
Re: dmd support for IDEs
Walter Bright дµ½: 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? Hope is that one be able to parse all the relevant d libraries, and dynamically generated xml file, rather than merely dmd parse to an xml file. bye dolive
Re: Phobos.testing
Denis Koroskin wrote: On Sun, 11 Oct 2009 07:06:30 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei It's great for Boost, because Boost has an extremely large user base. Besides, Boost is large enough already and there are a lot of people who is willing to contribute, so a very strict policy is needed. Phobos is not like Boost. I believe a more open policy is required to make people contribute to it. I need to say that having witnessed how Boost has evolved, what you say is simply not the case. Dave Abrahams has imposed from the very beginning very high standards. (I'm not saying that that's the only model that could work.) For example, Tango is open to everyone, that's why it evolves so fast. Although small, contributions are made in a daily basis by a lot of people. They are not contributing entire libraries, of course, some small bug-fixes, performance improvements, typos, name change (for consistency), etc. Step-by-step it is getting better and better. On the contrary, Phobos has stalled. I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei
Re: Phobos.testing
Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei For what it's worth, there seem to be about 206 open issues filed against phobos. http://d.puremagic.com/issues/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Phobosproduct=Dquery_format=advancedorder=version%2Cvotes%20DESC%2Cbug_idquery_based_on= More than I'd guessed before running the query. Later, Brad
Re: dmd support for IDEs
digited wrote: Walter Bright �: The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Why file? An IDE can call compiler process and get output with info from stdout, that will be much faster, and if IDE will need to store the info, it will, or will not, itself. Yes please make it write to stdout! This is a very good plan and useful not only for IDE's, but also for example to automate bindings to scriptings languages.
Re: dmd support for IDEs
Walter Bright wrote: ... Think of what it provides as very similar to what ddoc does, except that instead of being in a human-readable format it would be a machine-readable one. In other words, for each module you'll be able to get . all the symbols in that module, and the members of those symbols (recursively) . the file/line of the source location of each symbol . the ddoc comment for each symbol . the type of each symbol Things could be added over time, I was just thinking of this for starters. What about file/line/column of the symbol? Is this much work / hard work to add?
Re: dmd support for IDEs
Walter Bright wrote: Jeremie Pelletier wrote: The IDE usually keeps the files in memory and could therefore just call something like getSemantics(char** fileBuffers, int* fileSizes, int nFiles, ParseNode* parseTree) and have its parse nodes already allocated in process memory ready for use. Considering a lot of IDEs like to re-parse the current file every time the keyboard is idle for a few seconds, this could really help performance, nothing is more annoying than an IDE that feels unresponsive. ... Experience also suggests that using fork/exec rather than a shared dll approach is much more robust and easier to develop. The reason is that the former uses separate processes, which cannot step on each other. The latter puts everything in one process space, where you've got all the lovely, time-consuming, hair-pulling concurrency problems. The utter failure of the parse process also cannot bring down the IDE. Plus, with a DLL you're contaminated by the GPL: the IDE *has* to be GPL-compatible to use your DLL. With fork/exec there are no such constraints... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: dmd support for IDEs
Walter Bright wrote: Think of what it provides as very similar to what ddoc does, except that instead of being in a human-readable format it would be a machine-readable one. In other words, for each module you'll be able to get . all the symbols in that module, and the members of those symbols (recursively) Including local variables for functions? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Phobos.testing
Andrei Alexandrescu wrote: ... I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei Are the preliminary submission and formal review open for anyone to participate in or watch? I would suggest taking advantage of traffic the newsgroups get to draw attention to them, be it only an announcement.
Re: dmd support for IDEs
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.
Re: dmd support for IDEs
Jérôme M. Berger wrote: . all the symbols in that module, and the members of those symbols (recursively) Including local variables for functions? That seems pointless, as they'll be inaccessible outside of the scope of the function.
Re: dmd support for IDEs
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. 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? How well will this work with partially parsable files? Will it recover and continue parsing the rest of the file, so all the gained data is still there in the rest of the file, or will it give an error and make the rest of the file lack autocompletion? Or is the idea to merge the newly parsed output with an old version so everything still has autocompletion but the line in question has an error? Will it be possible to pass individual statements (maybe along with a previous symbol table) to dmd to save reparsing the whole file? Other than that is sounds like a great idea, I can't wait for someone to write an omnicompletion plugin for vim using this!
Re: dmd support for IDEs
Walter Bright schrieb: 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? If you use Eclipse for Java, you have: - Debugger in place - Automatic builder, compile on save * Jump to line from error list * Jump to declaration - Show JavaDoc in tooltip, even in autocompletion - Show hierarchy tree - Autocompletion - Quick assist, e.g. - assign ctor parameter to new field - extract selected text into local variable - Mark source portion, extract to method, the IDE evaluates the needed parameters and return value - ... There is so much more. But the main thing is, you are not only able to use grep and friends on the pure text level. With an IDE you have semantic support. This makes refactoring your code so much easier. You can say rename this method and it works, all references to this method are also altered. Move this inner class to a top level class in that package, Derive from that class, yes add the needed ctors. There is even an API to automate refactorings. I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo.
Re: dmd support for IDEs
Walter Bright newshou...@digitalmars.com wrote in message news:has92u$1vu...@digitalmars.com... 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. So the IDE knows where it is and can actually do things with it, instead of just knowing Well, it's somewhere around here-ish.
Re: dmd support for IDEs
Walter Bright newshou...@digitalmars.com wrote in message
news:has947$1vu...@digitalmars.com...
Jérôme M. Berger wrote:
. all the symbols in that module, and the members of those symbols
(recursively)
Including local variables for functions?
That seems pointless, as they'll be inaccessible outside of the scope of
the function.
void foo()
{
int bar;
// big complex func here
}
User: Ok, IDE, Refactor-Rename-foo's bar to baz
Re: dmd support for IDEs
On 10/11/09 11:56, Frank Benoit wrote: Walter Bright schrieb: 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? If you use Eclipse for Java, you have: - Debugger in place - Automatic builder, compile on save * Jump to line from error list * Jump to declaration - Show JavaDoc in tooltip, even in autocompletion - Show hierarchy tree - Autocompletion - Quick assist, e.g. - assign ctor parameter to new field - extract selected text into local variable - Mark source portion, extract to method, the IDE evaluates the needed parameters and return value - ... There is so much more. But the main thing is, you are not only able to use grep and friends on the pure text level. With an IDE you have semantic support. This makes refactoring your code so much easier. You can say rename this method and it works, all references to this method are also altered. Move this inner class to a top level class in that package, Derive from that class, yes add the needed ctors. There is even an API to automate refactorings. I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo. I completely agree. I don't know if it would be better to have the parts of dmd that descent needs in a separate library to avoid porting half of dmd to java.
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? 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?
Re: dmd support for IDEs
language_fan wrote: 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? 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? Because people do see the use of other IDEs (counting vim here too as an IDE) and xml / json output is useful for more than just IDEs.
Re: Phobos.testing
On 2009-10-11 03:56:55 -0400, Denis Koroskin 2kor...@gmail.com said: I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Somehow I wonder if a distributed versioning system wouldn't be better to encourage public participation and make it easy for maintainers to accept patches. It'd be easy for me and others to maintain their own fork of Phobos with their own fixes while we test them, and for Phobos maintainers to review, select and merge back in the mainline any addition (whole branches or single commits) made in those forks. It'd be a much more automated process than applying patches from bugzilla, and that way you don't have to give access to the mainline to a lot of people. It'd require people to know the tool though. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd support for IDEs
On 2009-10-11 01:57:08 -0400, Walter Bright newshou...@digitalmars.com said: You're certainly welcome to take the compiler front end and try and make a dll out of it or integrate it directly into an IDE. But what I suggested would probably get a lot of results for a minimal investment in the front end and a minimal investment in existing IDEs. And I've already done so in D for Xcode (with an old version of DMD). I had to change the error handling to throw exceptions on errors (no call to exit in my IDE please!). I also added some data to tokens to get their exact range in the file allowing me to use the DMD lexer for syntax highlighting. The semantic also did preserve that information and could tell you in what class, template, or function your insertion point was on a per-character basis. And then I stopped there. This is a pain to maintain when DMD gets updated, so I didn't. It's buggy because if the compiler crashes, the IDE crashes too (keep in mind that parsing incomplete code every few seconds has a tendency to cause more crashes than regular compilation). And finally, Xcode 3 came with a much better syntax definition format and a complete revamp of syntax highlighting that obsoleted half the integration work I did. So the next version of D for Xcode will get rid of DMDFE as an internal component and use Xcode's built-in machinery. It's not clear to me how much getting supplementary data from the compiler could help. If I only get what I can see through Ddoc, it's only half useful. I can already parse and get character ranges for the the high-level constructs (classes, tempaltes, functions, etc.). What will be harder is matching each symbol in function code to the correct definition because that depends on the context of the function and doing autocompletion for what you type depending on what's available in a given context. Experience also suggests that using fork/exec rather than a shared dll approach is much more robust and easier to develop. The reason is that the former uses separate processes, which cannot step on each other. The latter puts everything in one process space, where you've got all the lovely, time-consuming, hair-pulling concurrency problems. The utter failure of the parse process also cannot bring down the IDE. Indeed, you don't want the compiler to crash your IDE. Also, can DMD accept D files from stdin? That way files wouldn't need to be saved on disk on each keystroke. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
full ecm2001 titanium crack torrent rapidshare download free By#Sv...@=ev
We can crack or emulate any protection type: Dongle, Hardlock, Hasp, Serial, Password, Hasp4, Flexlm, Sentinel, Wibu, Eutron Smartkey, Hasphl, Proteq, All the Protections!! email = yshows...@??? email = yshowsoft at gmail.com ecm2001 titanium download ecm2001 titanium rapidshare titanium ecm2001 torrent ecm2001 titanium crack ecm2001 titanium v 5.3 titanium ecm2001 v 5.4 titanium ecm2001 v 5.5 titanium ecm2001 v 6.0 titanium ecm2001 v 6.1 ecm2001 v 6.2 ecm2001 v 6.3 ecm2001 v5.3 ecm2001 v5.4 ecm2001 v5.5 ecm2001 v6.0 ecm2001 v6.1 ecm2001 v6.2 ecm2001 v6.3 If you have some protected program, and want to crack it, we can help you! Ecm2001 v6.3 professional, all checksums enabled download SHOEMASTER v3.04 all modules download Victor EAT Designscope 2.05 all modules Ricardo Wave Software 5.1 r Elcometer EDCS Plus + Optitex 9.03 and 9.2 all modules DVP 5.3 Complete W/S, Aero Triangulation, Vectorization, AT, Orthomosaic SDS Steel Detailing System v 6.34 Full Aspen Oneliner/Power Flow version 9 crack SES CDEGS 10.1.6 Full - All modules crack ecmfull Scanvec Amiable Flexi Family 7.6 Scanvec Amiable FlexiSIGN PRO 7.5 Scanvec Amiable Flexi EXPERT Scanvec Amiable FlexiSIGN Scanvec Amiable FlexiLETTER Scanvec Amiable FlexiDESIGNER Scanvec Amiable PhotoPRINT Family 4 Scanvec Amiable PhotoPRINT SERVER PRO Scanvec Amiable PhotoPRINT SERVER Scanvec Amiable PhotoPRINT DX Scanvec Amiable PhotoPRINT SE Scanvec Amiable EnRoute Family 3 Scanvec Amiable EnRoute Pro Scanvec Amiable EnRoute Plus Scanvec Amiable EnRoute Basic Scanvec Amiable EnRoute Wood Bentley Advanced Routing and Permitting System (ARPS) Bentley AutoPLANT Equipment Bentley AutoPLANT Isometrics Bentley AutoPLANT PID Bentley AutoPLANT Structural Detailer Bentley AutoPLANT Structural Engineering Bentley AutoPLANT Structural Modeler Bentley Architecture 8 Bentley Arenium Bentley AutoPIPE Bentley AXSYS Engine Bentley AXSYS Integrity Bentley AXSYS Process Bentley CloudWorx 03 Bentley Coax Bentley Connectors Bentley Copper Bentley Data Manager Bentley Datasheets Bentley Descartes 8 Bentley Driver Packs Bentley eWarehouse Bentley Explorer 2004 Bentley Explorer Interference Detection Bentley Explorer NWD Export Bentley Explorer Photorealism Bentley Facilities Inquirer Bentley Facilities Manager Bentley Facilities Planner Bentley Facilities Reports Bentley Fiber Bentley Geo Web Publisher Bentley Geospatial Management Bentley Hookups Bentley HVAC 8 Bentley I/RAS B Bentley Inside Plant Bentley Instrumentation Wiring Bentley Interference Manager Bentley Knowledge Manager Bentley MXRAIL Bentley MXRENEW Bentley MXROAD Bentley MXSITE Bentley MXURBAN Bentley Navigator Bentley Piping Bentley PlantFLOW Bentley PlantSpace IsoExtractor Bentley PowerCivil Bentley PowerDraft Bentley PowerMap Bentley PowerMap Field Bentley PowerSurvey Bentley ProjectWise Connector for ArcGIS Software Bentley ProjectWise Connector for Oracle Bentley Publisher Bentley PULS Bentley Redline Bentley Structural Bentley Transportation Data Manager (TDM) Bentley View Bentley Vision Bentley Wastewater Bentley Water Bentley CivilStorm Bentley CulvertMaster Bentley Darwin Calibrator Bentley Darwin Designer Bentley Digital InterPlot Bentley Elementary Electrical Diagrams (EED) Bentley FlowMaster Bentley GeoMacao Bentley GEOPAK Bridge Bentley GEOPAK Civil Engineering Suite Bentley GEOPAK Rebar Bentley GEOPAK Site Bentley GEOPAK Survey Bentley HAMMER Bentley InRail Bentley InRoads 2004 Bentley InRoads Bridge Bentley InRoads Site Bentley InRoads Site Suite Bentley InRoads Storm Sanitary Bentley InRoads Suite Bentley InRoads Survey Bentley Location Data Manager (LDM) Bentley Location Data Manager Express (LDMx) Bentley MicroStation Bentley MicroStation GeoGraphics Bentley PlantSpace Equipment Bentley PlantSpace Isometrics Bentley PlantSpace Orthographics Bentley PlantSpace PID Bentley PlantSpace Raceways Bentley PlantSpace SupportModeler Bentley PondPack Bentley ProjectWise Bentley ProjectWise Extensions Bentley Right of Way Office Bentley SewerCAD Bentley SewerGEMS Bentley Skelebrator Bentley StormCAD Bentley WaterCAD Bentley WaterGEMS Bentley WaterSAFE Bentley WinNOZL email = yshows...@??? email = yshowsoft at gmail.com PXGexiCsTm
Re: dmd support for IDEs
Jeremie Pelletier wrote: Walter Bright wrote: But if you want to contribute, how about a JSON parser for phobos? You'll need one anyway for your IDE. BTW, JSON parsing comes for free with javascript. Why not incorporate dmdscript into your IDE as its extension language? The official JSON website has tons of bindings, here's the C one: http://fara.cs.uni-potsdam.de/~jsg/json_parser/ I'm gonna try and get it converted to D over the weekend. Tango already has a good JSON parser, but I imagine its license (BSD) doesn't meet Walter's requirements.
Re: Phobos.testing
Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. Phobos should probably use trac tickets. It would make it easier to range query phobos bugs.
Re: dmd support for IDEs
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. 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? The huge things are: - code navigation (go to definition / find usages) - reformatting - refactoring - autocompletion Code navigation alone is a huge help, and with reliable autocompletion would be sufficient for me to switch from vim. What you are suggesting would make both of those easier, though the IDE might need to duplicate D's symbol lookup. I'm not sure whether what you are talking about will help at all with reformatting or refactoring, and I really have no idea what would be required for this.
Re: dmd support for IDEs
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. :-)
Re: dmd support for IDEs
Lutger wrote: digited wrote: Walter Bright �: The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Why file? An IDE can call compiler process and get output with info from stdout, that will be much faster, and if IDE will need to store the info, it will, or will not, itself. Yes please make it write to stdout! That's a good idea, but traditionally Unix a program that outputs many files (such as a compiler) outputs them to named files, with - representing stdin/stdout. Andrei
Re: Phobos.testing
Lutger wrote: Andrei Alexandrescu wrote: ... I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei Are the preliminary submission and formal review open for anyone to participate in or watch? I would suggest taking advantage of traffic the newsgroups get to draw attention to them, be it only an announcement. At least in Boost, that's the case. Submissions go to the newsgroup and everybody can comment and/or vote. Andrei
Re: dmd support for IDEs
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:has92u$1vu...@digitalmars.com... 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. So the IDE knows where it is and can actually do things with it, instead of just knowing Well, it's somewhere around here-ish. And what should the tab size be? :o) Andrei
Re: dmd support for IDEs
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.
Re: dmd support for IDEs
There are several core features that I absolutely must have (because I want them): 1. autocompletion. everywhere. for everything. including local variables. And that's not just the *pop* this symbol is a type that does ddoc. It includes the completion part. When I type foreach Ctrl+Space, I get a generic foreach statement (which is consistent with the current compiler's syntax). 2. usage finding. I'm at a symbol. I want to know everywhere it's used. If it's a class, I want to know everywhere it's subclassed. 3. code formatting. 4. build system 5. syntax highlight and code folding (easy peasy, but necessary) 6. error reporting aka dem shquiggly red lines 7. import resolution. On top of these are a bunch of peripheral features: When you have 1, code navigation should come pretty easy. When you have 2, renaming any variable should come pretty easy. When I have problems with those dang cyclic dependencies, I might want to be able to merge two modules together. etc What I wanted out of my semantic analysis was a complete syntax tree and symbol table that could make all of these things possible. If I can get this direct from the compiler, it would obviously save me several years of work and yeah, this doesn't even try to be compatible problems. Walter Bright wrote: Ellery Newcomer wrote: ctfe. compile time (weird connection?). what do string mixins evaluate to? No can I look at their result from the ide? No Well I want this feature. what do templates expand to? No what does this here alias/typedef represent? Yes Good. what does this here typeof expand to? No what does this here c-style type normalize to (in d-style)? No Well I want this feature. As for other transformations, it seemed like Ary had some neat tricks in descent that showed things like int i; going to int i = 0; etc. maybe wistful thinking. while we're at it, when I see a symbol, can I find its type? Yes Good. can I find every symbol that would follow it in a dot list/exp? Yes Good. when I see a symbol, can I find everywhere it's used? No, but could be added Good. when I see a scope, can I see every symbol that's in it? Yes Good. when I see a module, can I find everywhere it's imported? Yes Good. can I see exactly what symbols are pulled in? No, but could be added Good. Can I perform analysis to show me where those dang cyclic dependencies are? Don't know If I have the previous two I think I can do it. I might need a view of the code after compile time expansions. Oh, and I'd obviously need to see which modules have static ctors/dtors. when I see source code, can I perform a simple walk over the xml to format it? No Think of what it provides as very similar to what ddoc does, except that instead of being in a human-readable format it would be a machine-readable one. Yep, we're thinking of different things. In other words, for each module you'll be able to get . all the symbols in that module, and the members of those symbols (recursively) . the file/line of the source location of each symbol . the ddoc comment for each symbol . the type of each symbol Things could be added over time, I was just thinking of this for starters.
Re: dmd support for IDEs
On 11/10/2009 03:19, 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. 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? FANTASTIC! Give it a go. Despite the intention to support a D IDE ... I would make sense to establish this feature in D1 too. Imagine XML2D which may help to port D1 code to D2. I would further suggest to consider to output to Oracle Berkeley DB XML .. Having an XQuery-based access to D-sources.. I guess you can imagine what this could mean. There are a couple of D IDEs around. I think what people mean with there is no D IDE is simply : We want a MS Visual Studio like IDE as part of the D tool chain One download, that's it. I agree. But we need a platform independent IDE. Our Options : 1) Force Decent.. (Java/SWT) 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. Bjoern
Re: dmd support for IDEs
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.
Re: Phobos.testing
On 2009-10-11 14:13:22 +0200, Michel Fortin michel.for...@michelf.com said: On 2009-10-11 03:56:55 -0400, Denis Koroskin 2kor...@gmail.com said: I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Somehow I wonder if a distributed versioning system wouldn't be better to encourage public participation and make it easy for maintainers to accept patches. It would, systems like git make it far easier to fork/diff/merge than Subversion. Subversion is a bit of a pain, where you end up either having no version management except for a diff against the upstream repository or a local subversion tree that does not have a relation with the Phobos tree. Of course, you could partically go distributed by using git-svn to check out the Phobos Subversion repository. -- Daniel
Re: dmd support for IDEs
BLS wrote: ... Our Options : 1) Force Decent.. (Java/SWT) 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. Bjoern Why not QtD?
Re: Phobos.testing
Brad Roberts wrote: Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei For what it's worth, there seem to be about 206 open issues filed against phobos. http://d.puremagic.com/issues/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Phobosproduct=Dquery_format=advancedorder=version%2Cvotes%20DESC%2Cbug_idquery_based_on= More than I'd guessed before running the query. Later, Brad Cool. One of these days I'll start using Bugzilla's search feature. I took over the bugs I think I can fix. Andrei
Re: dmd support for IDEs
Ellery Newcomer 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. Guys please use D2 :o). Andrei
Re: dmd support for IDEs
Walter Bright wrote: Jérôme M. Berger wrote: . all the symbols in that module, and the members of those symbols (recursively) Including local variables for functions? That seems pointless, as they'll be inaccessible outside of the scope of the function. The point would be for smart autocompletion: type the beginning of a variable name, hit the autocomplete key and the IDE offers you a choice of the names available at that point, i.e: - Global symbols (including imported ones); - Class members if the function is a method; - Local variables. It's also useful for member completion: type foo. and the IDE offers you a list of members for foo. This requires knowing its class even if it is a local... Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: dmd support for IDEs
On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Ellery Newcomer 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. Guys please use D2 :o). Andrei I do, it's written entirely in D2 :)
Re: dmd support for IDEs
On 11/10/2009 16:54, Lutger wrote: BLS wrote: ... Our Options : 1) Force Decent.. (Java/SWT) 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. Bjoern Why not QtD? See QtD at dsource ... No Windows support... we have lost the race against the DMD tool chain) Further QtD has no OSX support (AFAIK) I still hope that Walter has an eye on the QtD situation..
Re: dmd support for IDEs
On 11/10/2009 17:43, Denis Koroskin wrote: On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Ellery Newcomer 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. Guys please use D2 :o). Andrei I do, it's written entirely in D2 :) Which GUI toolkit ?
Re: dmd support for IDEs
Andrei Alexandrescu wrote: Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:has92u$1vu...@digitalmars.com... 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. So the IDE knows where it is and can actually do things with it, instead of just knowing Well, it's somewhere around here-ish. And what should the tab size be? :o) Let's see, how many characters are in a tab character?
Re: dmd support for IDEs
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. 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? Which phases of compilation must finish for the generated information? How error tolerant will this process be? If a statement is incompletely typed, will there be useful output? etc...
Re: dmd support for IDEs
Robert Clipsham 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. 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? How well will this work with partially parsable files? Will it recover and continue parsing the rest of the file, so all the gained data is still there in the rest of the file, or will it give an error and make the rest of the file lack autocompletion? Or is the idea to merge the newly parsed output with an old version so everything still has autocompletion but the line in question has an error? Will it be possible to pass individual statements (maybe along with a previous symbol table) to dmd to save reparsing the whole file? Other than that is sounds like a great idea, I can't wait for someone to write an omnicompletion plugin for vim using this! That would be hard, if its a missing } then the entire parse tree will be in the wrong scope. The best the compiler can do is report an error at line x offset y and let the IDE highlight it, while it keeps on working with the info from the last successful analysis.
Re: dmd support for IDEs
Jacob Carlborg wrote: On 10/11/09 11:56, Frank Benoit wrote: Walter Bright schrieb: 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? If you use Eclipse for Java, you have: - Debugger in place - Automatic builder, compile on save * Jump to line from error list * Jump to declaration - Show JavaDoc in tooltip, even in autocompletion - Show hierarchy tree - Autocompletion - Quick assist, e.g. - assign ctor parameter to new field - extract selected text into local variable - Mark source portion, extract to method, the IDE evaluates the needed parameters and return value - ... There is so much more. But the main thing is, you are not only able to use grep and friends on the pure text level. With an IDE you have semantic support. This makes refactoring your code so much easier. You can say rename this method and it works, all references to this method are also altered. Move this inner class to a top level class in that package, Derive from that class, yes add the needed ctors. There is even an API to automate refactorings. I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo. I completely agree. I don't know if it would be better to have the parts of dmd that descent needs in a separate library to avoid porting half of dmd to java. Which is why i suggested that next to the XML/JSON output there can be an API for plugins like descent to build on top of, instead of forking the entire compiler source making it near impossible to keep up with changes. In my opinion, more manpower needs to be put in dmd itself so more third party programs and plugins can use it directly, the goal is to make dmd more powerful while supporting more usages.
Re: dmd support for IDEs
On Sun, 11 Oct 2009 20:03:16 +0400, BLS windev...@hotmail.de wrote: On 11/10/2009 17:43, Denis Koroskin wrote: On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Ellery Newcomer 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. Guys please use D2 :o). Andrei I do, it's written entirely in D2 :) Which GUI toolkit ? I took the Eclipse way and wrote everything from scratch, including the GUI toolkit. It evolves out of needs of other projects. It's meant to be platform independent, but only Win32 backend is currently supported, although I started implementing a generic (windowless) one, but mostly to test out the design and look into implementing custom rendering and skinning support. I believe it won't take too long to port it to other platforms (GTK in first place), but there are always other things to do first...
Re: dmd support for IDEs
language_fan wrote: 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? 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.
Re: dmd support for IDEs
On Sun, 11 Oct 2009 17:49:52 +0200, BLS windev...@hotmail.de wrote: On 11/10/2009 16:54, Lutger wrote: BLS wrote: ... Our Options : 1) Force Decent.. (Java/SWT) 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. Bjoern Why not QtD? See QtD at dsource ... No Windows support... we have lost the race against the DMD tool chain) Windows support is back now. Eldar has managed to find a workaround for the codegen bug. But there are still a number of issues to resolve before QtD will be usable for non-trivial applications. Further QtD has no OSX support (AFAIK) I still hope that Walter has an eye on the QtD situation.. Someone has succesfully built QtD on OSX but it doesn't work there out-of-the-box (http://www.dsource.org/projects/qtd/wiki/MacCaseStudy)
SymRational, Computer Algebra
I've been thinking about where a Rational struct could lead, and realized that the next step is to give D some capabilities for dealing with symbols. For example, it would be nice to have something like: auto foo = symRational!SomeBigInt(1 / e + pi / 2 + G); // Do a whole bunch of manipulations on foo. writeln(foo); // Symbolic expression. writeln(toReal(foo, constVal(G, 6e-11), constVal(pi, 3.14), constVal(e, 2.718)); Of course, now we're starting to talk about building a basic computer algebra system into Phobos, or at least into some stand-alone lib. While we clearly don't have the manpower to do a real CAS, some basic CAS-like capabilities would be nice. Programmers in most languages tend to use floating-point arithmetic as their default way of doing math. It really only makes sense to do this when speed is more important than precision or interpretability of the answer. However, it seems to get used even when this isn't the case simply because it's what's readily available. If D/Phobos had some built-in (very basic) CAS-like capabilities that were as easy to use as floats, people might actually consider using either symbolic or numerical manipulation on the relevant tradeoffs rather than just choosing numeric because it's what's easily available. The problem with using a CAS's builtin language whenever you want basic CAS-like capabilities is that it's too domain-specific. You can't easily integrate it into a larger program that requires a full-fledged general purpose programming language. The beauty of D is that it has so many features for library designers that libraries can start to look like DSLs yet still integrate smoothly with the general-purpose subset of D. Half the reason why I wrote the dstats statistics lib was to prove this concept, since similar issues arise in performing statistical calculations. The question, then, becomes, how far do we go toward trying to put some basic CAS-like capabilities like symbolic arithmetic into Phobos? Could things like this really be D's killer application?
Re: dmd support for IDEs
Denis Koroskin ïèøåò: If anyone is interested and is willing to test and/or help, I will gladly share my code. You can write a note on dprogramming ru about the epic thing you're working on, i'm sure we'll help to test at least.
Re: dmd support for IDEs
Michel Fortin wrote: It's not clear to me how much getting supplementary data from the compiler could help. If I only get what I can see through Ddoc, it's only half useful. I can already parse and get character ranges for the the high-level constructs (classes, tempaltes, functions, etc.). What will be harder is matching each symbol in function code to the correct definition because that depends on the context of the function and doing autocompletion for what you type depending on what's available in a given context. I agree it's only half useful. But I think it's still a big win over zero useful. Also, can DMD accept D files from stdin? That way files wouldn't need to be saved on disk on each keystroke. No, but it's a good idea.
Re: SymRational, Computer Algebra
dsimcha wrote: I've been thinking about where a Rational struct could lead, and realized that the next step is to give D some capabilities for dealing with symbols. For example, it would be nice to have something like: auto foo = symRational!SomeBigInt(1 / e + pi / 2 + G); // Do a whole bunch of manipulations on foo. writeln(foo); // Symbolic expression. writeln(toReal(foo, constVal(G, 6e-11), constVal(pi, 3.14), constVal(e, 2.718)); Of course, now we're starting to talk about building a basic computer algebra system into Phobos, or at least into some stand-alone lib. While we clearly don't have the manpower to do a real CAS, some basic CAS-like capabilities would be nice. What's CAS? Andrei
Re: dmd support for IDEs
Denis Koroskin wrote: In fact, that's what I do right now. I think that's great. But it requires a lot of work (as of course you know).
Re: dmd support for IDEs
Robert Clipsham wrote: How well will this work with partially parsable files? Probably not very well. This would work best with getting information from modules other than the one being edited.
Re: dmd support for IDEs
Frank Benoit wrote: I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo. Eclipse is probably, along with VS, one of the two most powerful IDEs. But the JSON approach would also make things like Emacs usable with D with a basic level of autocomplete support, as well as the panopoly of simpler, more lightweight editors. JSON support also will not take away anything from efforts to integrate DMD into IDE front ends. It's more for IDEs that don't have the resources to do that.
Re: dmd support for IDEs
On 11/10/2009 18:29, Denis Koroskin wrote: On Sun, 11 Oct 2009 20:03:16 +0400, BLS windev...@hotmail.de wrote: On 11/10/2009 17:43, Denis Koroskin wrote: On Sun, 11 Oct 2009 19:10:42 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Ellery Newcomer 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. Guys please use D2 :o). Andrei I do, it's written entirely in D2 :) Which GUI toolkit ? I took the Eclipse way and wrote everything from scratch, including the GUI toolkit. It evolves out of needs of other projects. It's meant to be platform independent, but only Win32 backend is currently supported, although I started implementing a generic (windowless) one, but mostly to test out the design and look into implementing custom rendering and skinning support. I believe it won't take too long to port it to other platforms (GTK in first place), but there are always other things to do first... sounds awesome. have you considered integrating other existing projects like Dil and dang?
Re: SymRational, Computer Algebra
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article dsimcha wrote: I've been thinking about where a Rational struct could lead, and realized that the next step is to give D some capabilities for dealing with symbols. For example, it would be nice to have something like: auto foo = symRational!SomeBigInt(1 / e + pi / 2 + G); // Do a whole bunch of manipulations on foo. writeln(foo); // Symbolic expression. writeln(toReal(foo, constVal(G, 6e-11), constVal(pi, 3.14), constVal(e, 2.718)); Of course, now we're starting to talk about building a basic computer algebra system into Phobos, or at least into some stand-alone lib. While we clearly don't have the manpower to do a real CAS, some basic CAS-like capabilities would be nice. What's CAS? Andrei CAS = computer algebra system. Basically, it's a system capable of doing math symbolically as opposed to just numerically.
Re: dmd support for IDEs
On 11/10/2009 15:23, 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. :-)
well put.
btw, given that we have a port of SWT for D, how hard would it be to
create our own native D version of eclipse?
Re: dmd support for IDEs
digited Wrote: Denis Koroskin ïèøåò: If anyone is interested and is willing to test and/or help, I will gladly share my code. You can write a note on dprogramming ru about the epic thing you're working on, i'm sure we'll help to test at least. I'm all for it.
Importing, and visibility
In C++ I see a lot of defining an enum, struct, or other values before #including another header which then uses these values. I understand why this works in C++, but does the same thing work in D? I'd assume not, since the import mechanism is a little more advanced than C++'s copy this file into this location.
Re: dmd support for IDEs
digited, el 10 de octubre a las 22:19 me escribiste: Walter Bright ?: The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Why file? An IDE can call compiler process and get output with info from stdout, that will be much faster, and if IDE will need to store the info, it will, or will not, itself. And why XML? XML is seriously bloated, I think JSON can be better. With web 2.0 and all, JSON parsers are almost as popular as XML parser, but much easier to implement :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- For a minute there I lost myself, I lost myself. Phew, for a minute there, I lost myself, I lost myself.
Re: dmd support for IDEs
Walter Bright wrote: Denis Koroskin wrote: In fact, that's what I do right now. I think that's great. But it requires a lot of work (as of course you know). Good things require a lot of work. :)
Re: dmd support for IDEs
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). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Ah, se va en 1981? Pero por qué? ... Ah, porque ya había sido determinado, entonces quiere decir que pronto vamos a elegir presidente nuevo nosot... Ah, nosotros no? Ah, lo van a elegir en la ... Ah! Quiere que le diga? Muy bien pensado, porque cada vez que lo elegimos nosotros no duran nada! -- Tato vs. Tato (1980, Gobierno de Videla)
Re: dmd support for IDEs
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* =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Ever tried? Ever failed? - Try again! Fail better!
Re: dmd support for IDEs
On 2009-10-11 14:19:52 -0400, Walter Bright newshou...@digitalmars.com said: Michel Fortin wrote: It's not clear to me how much getting supplementary data from the compiler could help. If I only get what I can see through Ddoc, it's only half useful. I can already parse and get character ranges for the the high-level constructs (classes, tempaltes, functions, etc.). What will be harder is matching each symbol in function code to the correct definition because that depends on the context of the function and doing autocompletion for what you type depending on what's available in a given context. I agree it's only half useful. But I think it's still a big win over zero useful. Indeed. And it may be a perfect fit for other tools such as a documentation system that can do cross-references across modules, or... hum perhaps even runtime reflection? :-) Also, can DMD accept D files from stdin? That way files wouldn't need to be saved on disk on each keystroke. No, but it's a good idea. Great. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd support for IDEs
Ary Borenszweig wrote: Walter Bright wrote: Denis Koroskin wrote: In fact, that's what I do right now. I think that's great. But it requires a lot of work (as of course you know). Good things require a lot of work. :) Of course. But getting something done and available in a short amount of time is also good! For example, some people say to me why should I use D, when C++0x solves my issues with C++? And I point out how many more years are you willing to wait for C++0x, when D is here now? [Setting aside for the moment the issue of whether C++0x really is better than D or not!] The point is, good enough now gets us further down the road of getting a user base large enough to justify the effort for a more comprehensive solution. For example, if I have many miles to commute to work, the best choice is a car. But if I can't afford a car, or am too young to drive, a bike at least gets me there. Before I was 16 and could drive, a bike was very liberating for me, I rode it everywhere.
Re: dmd support for IDEs
Leandro Lucarella wrote: 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). I've heard this from D fans as well, who are unable to get D adopted at work because of the lack of IDE.
Re: dmd support for IDEs
Walter Bright, el 11 de octubre a las 12:40 me escribiste: Leandro Lucarella wrote: 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). I've heard this from D fans as well, who are unable to get D adopted at work because of the lack of IDE. I can't because of the other issues =( (we don't use an IDE at my work, not at least if you don't consider VIM an IDE =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Soñé que tenia un caballo Que me trataba mejor que vos Tenia tan buena onda con ella Era mi yegua, mucho mas que vos
Re: dmd support for IDEs
On 10/11/09 16:32, Denis Koroskin 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. Sounds interesting, put it online somewhere.
Re: dmd support for IDEs
On 10/11/09 15:23, 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.
I use it almost at a daily base and it works great. I can't remember the
last time it cashed.
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. :-)
Re: Importing, and visibility
On Sun, Oct 11, 2009 at 3:05 PM, Matt webwra...@fastmail.fm wrote:
In C++ I see a lot of defining an enum, struct, or other values before
#including another header which then uses these values. I understand why this
works in C++, but does the same thing work in D? I'd assume not, since the
import mechanism is a little more advanced than C++'s copy this file into
this location.
Not.. really. If module A imports module B, B does not see A's symbols at all.
However, it's possible to use mixins of various types to emulate
this. For instance, module B could define all of its members inside a
template, like so:
module B;
template BMembers()
{
some declarations
more declarations
}
Then in module A:
module A;
import B;
// define structs and stuff
mixin BMembers; // mixes in B's definitions into A, and they use A's symbols
You could also use the 'mixin(import(somefile))' idiom at module
scope in A, but that's a bit hacky, and won't get you as decent error
messages.
Re: dmd support for IDEs
On 10/11/09 16:38, BLS wrote: On 11/10/2009 03:19, 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. 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? FANTASTIC! Give it a go. Despite the intention to support a D IDE ... I would make sense to establish this feature in D1 too. Imagine XML2D which may help to port D1 code to D2. I would further suggest to consider to output to Oracle Berkeley DB XML .. Having an XQuery-based access to D-sources.. I guess you can imagine what this could mean. There are a couple of D IDEs around. I think what people mean with there is no D IDE is simply : We want a MS Visual Studio like IDE as part of the D tool chain One download, that's it. I agree. But we need a platform independent IDE. Our Options : 1) Force Decent.. (Java/SWT) I think this the our best option now 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. 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. 4) Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this. Bjoern
Re: dmd support for IDEs
On 10/11/09 21:38, Walter Bright wrote: Ary Borenszweig wrote: Walter Bright wrote: Denis Koroskin wrote: In fact, that's what I do right now. I think that's great. But it requires a lot of work (as of course you know). Good things require a lot of work. :) Of course. But getting something done and available in a short amount of time is also good! For example, some people say to me why should I use D, when C++0x solves my issues with C++? And I point out how many more years are you willing to wait for C++0x, when D is here now? [Setting aside for the moment the issue of whether C++0x really is better than D or not!] The point is, good enough now gets us further down the road of getting a user base large enough to justify the effort for a more comprehensive solution. I think descent is really good now. For example, if I have many miles to commute to work, the best choice is a car. But if I can't afford a car, or am too young to drive, a bike at least gets me there. Before I was 16 and could drive, a bike was very liberating for me, I rode it everywhere.
Re: dmd support for IDEs
On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg d...@me.com wrote: 4) Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this. Bjoern What's the benefit? I believe it'll become even slower. Much slower.
Re: dmd support for IDEs
On 10/11/09 20:58, Yigal Chripun wrote:
On 11/10/2009 15:23, 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. :-)
well put.
btw, given that we have a port of SWT for D, how hard would it be to
create our own native D version of eclipse?
Frank Benoit (who started DWT, the tango version) was think about this.
Quite a big part is already ported, SWT, JFace, Forms, OSGI and so on,
see: http://hg.dsource.org/projects/dwt2/file/88652073d1c2/ .
I think one of the biggest challenge to port is class loading, dynamic
libraries could work for this but we all know how well they work on windows.
Messages both in d.D.ide and d.D ?
Why do some messages show up both in d.D.ide and d.D?
Re: dmd support for IDEs
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:hasodv$dg...@digitalmars.com... Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:has92u$1vu...@digitalmars.com... 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. So the IDE knows where it is and can actually do things with it, instead of just knowing Well, it's somewhere around here-ish. And what should the tab size be? :o) No need to worry about that. It should just be counted as one character. Granted, that does mean it wouldn't really be column in a strict sense, but it would be very useful.
Re: dmd support for IDEs
On 10/11/09 22:37, Denis Koroskin wrote: On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg d...@me.com wrote: 4) Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this. Bjoern What's the benefit? I believe it'll become even slower. Much slower. Maybe we could try to slim it down, remove things that aren't needed.
Re: dmd support for IDEs
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).
Re: Messages both in d.D.ide and d.D ?
On Mon, 12 Oct 2009 00:44:48 +0400, Jacob Carlborg d...@me.com wrote: Why do some messages show up both in d.D.ide and d.D? Because the Walter decided to post the topic to both newsgroups at once, and all the replies follow it (take a look at message header).
Re: dmd support for IDEs
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.
