Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On 24/05/2016 07:34, Rainer Schuetze wrote: On 17.05.2016 10:06, Vadim Lopatin wrote: Hello, I'm working on GDB/MI compatible interface for Mago debugger on Windows. GDB/MI is line based machine interface for debugger. IDEs are using GDB via this interface. GDB/MI docs: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html Project page (mago fork) https://github.com/buggins/mago Currently mago-mi supports subset of GDB commands enough for current DlangIDE functionality. Tested on DMD generated 32bit executables. See readme details list of implemented commands: https://github.com/buggins/mago/tree/master/MagoMI/mago-mi Difference from baseline https://github.com/rainers/mago files are minimal: - Static linking for MagoNatDE and MagoNatEE - Disabled some Mago debug logging Building mago-mi from source is easy. I've tried MS Visual Studio 2013 and 2015. Don't forget to edit properties in mago/PropSheets. Buld mago-mi project. Since DlangIDE v0.6.1, it includes prebuilt mago-mi.exe (it will be copied into bin directory by dub build) and default Debugger settings are changed from gdb to mago-mi by default on Windows. If you already used DlangIDE on your computer, check Edit/Preferences/Debugger setting - change to "mago-mi" if "gdb" is specified. If you want to try mago-mi and DlangIDE which is using it, you can download binaries from https://sourceforge.net/projects/crengine/files/DlangUI/dlangide-v061-magomi-v010-x86.zip/download (or just sync to latest dlangide and use `dub run`). Bundle includes DlangIDE, mago-mi, dub, and sample workspaces (helloworld and tetris). Download size is 5.4Mb (seems small enough for IDE+debugger). I hope my work will be useful for other IDE developers who is targeting on Windows. (Any IDE which uses gdb/mi interface) I tried gdb and lldb-mi before, but did not managed to find working compiler + debugger configuration. (Best combination was gdb + gdc, but it was showing global variables instead of locals. For lldb-mi, I haven't managed to find compiler which produces compatible debug info). Best regards, Vadim Impressive work! I'm currently working on improving integration in VS. For this, I also needed a static library version of MagoNatDE. I just pushed my changes, I hope it doesn't break anything for you. If you want to stay in sync, please consider a PR with your changes to mago. Can Mago debug programs with debug information in the COFF format? If not, any chance this could be added, or is it a big task? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 1.0.0 released.
On 17/05/2016 15:04, Bruno Medeiros wrote: New DDT release out: dfmt support, performance improvements to semantic operations, more build command customization, fixes. Please see changelog for full list: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0 Since DDT has generally been quite stable, and since the current release is very close to the end-game vision I had for a D IDE - at least as far as my free time would allow to create - I've decided to version this as 1.0. I've been working for nearly 8 years on this project after all (with some intermission periods), so I guess 1.0 was a bit due... O.o' I expect it will mainly be small updates from now on, not any major new features (other than perhaps DCD support). Follow up with a few minor fixes and changes: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On 19/05/2016 08:41, Vadim Lopatin wrote: On Wednesday, 18 May 2016 at 18:02:12 UTC, Bruno Medeiros wrote: While DDT technically work oks with GDB (the GDB from mingw-w64 that is), you are right, there isn't a compiler on Windows that supplies debug info in the way GDB understands. See https://wiki.dlang.org/Debuggers. DMD produces debug info COFF or OMF format, which GDB doesn't know anything about (nor ever will). LDC should in theory work with DWARF info, but this is broken somehow. Not because of LLVM though, since for example Rust on Windows works. As for GDC, it doesn't even supply binaries for Windows (that target Windows) - it is not a supported platform. BTW, Eclipse/DDT should in theory work with mago-mi as well, at least if the protocol is implemented correctly. Have you tried it? I dunno how complete your MI implementation is. So it looks like mago-mi might be helpful for DDT on Windows. mago-mi supports subset of GDB/MI commands enough for DlangIDE, but it can be easy extended. Currenlty supported commands can be shown using help command (use --interpreter=mi2 when running mago-mi, otherwise it will print non-MI commands). Also commands are listed in readme file https://github.com/buggins/mago/blob/master/MagoMI/mago-mi/README.md I didn't try DDT with mago-mi, and so I'm not sure which commands must be supported by debugger to get it working with DDT. To get list of commands DDT tries to use you can either add --log-file=magomi.log --log-level=TRACE to mago-mi command line or use debug build of mago-mi. It will all STDIN data to log file, and report errors for unsupported commands. I also don't know which MI commands need to be supported to have it work with DDT. The thing is I didn't write the GDB debugger integration for DDT, I just reused the one from CDT. So I'm not that familiar with those internals. BTW, the MI integration is fairly language agnostic, so in theory your debugger could be used by CDT to debug C/C++ programs too, no? At least those generated by DMC. Maybe Visual Studio ones too? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On 17/05/2016 17:56, Vadim Lopatin wrote: On Tuesday, 17 May 2016 at 13:04:23 UTC, Bruno Medeiros wrote: Interesting. I was about to ask what was the main advantage over GDB? I reckon it is that Mago can debug executables with the COFF and/or OMF formats, right? (as opposed to GDB's DWARF format) Mago currently has the best D language support on Windows. Can debug DMD generated executables. Do you know any GDB version + compiler version which works ok on Windows? Even w/o D demangling. At least able to create breakpoints, step, continue, examining threads, stack frames, local variables. In gdb+gdc combination I tried, gdb shows global variables instead of stack variables. Does DDT work ok with GDB on Windows? What compiler can be used to get GDB debugging working? While DDT technically work oks with GDB (the GDB from mingw-w64 that is), you are right, there isn't a compiler on Windows that supplies debug info in the way GDB understands. See https://wiki.dlang.org/Debuggers. DMD produces debug info COFF or OMF format, which GDB doesn't know anything about (nor ever will). LDC should in theory work with DWARF info, but this is broken somehow. Not because of LLVM though, since for example Rust on Windows works. As for GDC, it doesn't even supply binaries for Windows (that target Windows) - it is not a supported platform. BTW, Eclipse/DDT should in theory work with mago-mi as well, at least if the protocol is implemented correctly. Have you tried it? I dunno how complete your MI implementation is. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 1.0.0 released.
On 18/05/2016 16:54, E.S. Quinn wrote: On Tuesday, 17 May 2016 at 14:04:04 UTC, Bruno Medeiros wrote: New DDT release out: dfmt support, performance improvements to semantic operations, more build command customization, fixes. Please see changelog for full list: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0 Since DDT has generally been quite stable, and since the current release is very close to the end-game vision I had for a D IDE - at least as far as my free time would allow to create - I've decided to version this as 1.0. I've been working for nearly 8 years on this project after all (with some intermission periods), so I guess 1.0 was a bit due... O.o' I expect it will mainly be small updates from now on, not any major new features (other than perhaps DCD support). Is there any chance we'll be able to get an outline view in the project explorer a la CDT? Actually yes. (I haven't forgotten about https://github.com/DDT-IDE/DDT/issues/106 ) To be more clear what I meant is that I don't expect any major new *D-specific* features (other than perhaps DCD support). But DDT uses the same framework as the RustDT (https://github.com/RustDT/RustDT) and GoClipse (https://github.com/GoClipse/goclipse) IDEs, so I'm still planning to work on new features that work across all IDEs. -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 1.0.0 released.
New DDT release out: dfmt support, performance improvements to semantic operations, more build command customization, fixes. Please see changelog for full list: https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0 Since DDT has generally been quite stable, and since the current release is very close to the end-game vision I had for a D IDE - at least as far as my free time would allow to create - I've decided to version this as 1.0. I've been working for nearly 8 years on this project after all (with some intermission periods), so I guess 1.0 was a bit due... O.o' I expect it will mainly be small updates from now on, not any major new features (other than perhaps DCD support). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: mago-mi: GDB/MI compatible frontend for Mago debugger
On 17/05/2016 09:06, Vadim Lopatin wrote: Hello, I'm working on GDB/MI compatible interface for Mago debugger on Windows. GDB/MI is line based machine interface for debugger. IDEs are using GDB via this interface. GDB/MI docs: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html Project page (mago fork) https://github.com/buggins/mago Currently mago-mi supports subset of GDB commands enough for current DlangIDE functionality. Tested on DMD generated 32bit executables. See readme details list of implemented commands: https://github.com/buggins/mago/tree/master/MagoMI/mago-mi Difference from baseline https://github.com/rainers/mago files are minimal: - Static linking for MagoNatDE and MagoNatEE - Disabled some Mago debug logging Building mago-mi from source is easy. I've tried MS Visual Studio 2013 and 2015. Don't forget to edit properties in mago/PropSheets. Buld mago-mi project. Since DlangIDE v0.6.1, it includes prebuilt mago-mi.exe (it will be copied into bin directory by dub build) and default Debugger settings are changed from gdb to mago-mi by default on Windows. If you already used DlangIDE on your computer, check Edit/Preferences/Debugger setting - change to "mago-mi" if "gdb" is specified. If you want to try mago-mi and DlangIDE which is using it, you can download binaries from https://sourceforge.net/projects/crengine/files/DlangUI/dlangide-v061-magomi-v010-x86.zip/download (or just sync to latest dlangide and use `dub run`). Bundle includes DlangIDE, mago-mi, dub, and sample workspaces (helloworld and tetris). Download size is 5.4Mb (seems small enough for IDE+debugger). I hope my work will be useful for other IDE developers who is targeting on Windows. (Any IDE which uses gdb/mi interface) I tried gdb and lldb-mi before, but did not managed to find working compiler + debugger configuration. (Best combination was gdb + gdc, but it was showing global variables instead of locals. For lldb-mi, I haven't managed to find compiler which produces compatible debug info). Best regards, Vadim Interesting. I was about to ask what was the main advantage over GDB? I reckon it is that Mago can debug executables with the COFF and/or OMF formats, right? (as opposed to GDB's DWARF format) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: LDC now supports Windows MSVC x86/x64 as first class targets
On 19/03/2016 13:23, kinke wrote: Hey all, I'm proud to announce that MSVC is fully supported now for LDC trunk. Rainer Schuetze has implemented MSVC-compatible exception handling (available since brand-new LLVM 3.8) for LDC, so that we have fully working exception chaining now on Win64. Along the way, he also added 32-bit MSVC support and a TLS alignment bugfix for Windows < 8.1 (a Windows bug/wontfix!). It requires a bleeding edge LLVM though, as Rainer's work has uncovered a few LLVM bugs which didn't make it into 3.8 final. So a round of applause for Rainer and the LLVM devs, excellent job, thank you very much! Full PDB support for LLVM is also underway... CI testing with AppVeyor has been improved, so that the full test suite is run for both x86 and x64 MSVC targets. All tests pass except for 3 rather negligible issues (see https://github.com/ldc-developers/ldc/pull/1354#issuecomment-198572582 for details). The automatically updated GitHub release (http://wiki.dlang.org/Latest_LDC_binaries_for_Windows) now also includes a downloadable 32-bit LDC build. Wiki pages have been updated accordingly. Check out http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC if you want to start contributing too! Setting up the dev environment isn't that hard, I promise. :) Awesome, keep up the good work! Now, I'm making a note to try again at some point soon to build lldb-mi, and see if it works well with the Eclipse CDT debugger. And more interestingly, if it would work with MSVC executables. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: mondo - a d library for mongodb
On 21/03/2016 16:10, Andrea Fontana wrote: I just released on behalf of the company I work for (http://lab.2night.it) "mondo", a library to work with mongodb. Mondo is a collection of classes (and struct) built over mongo-c-driver. Low-level bindings are generated automatically using dstep + a small script to patch some issues with original source. More info on github page. It obviusly depends on mongo-c-driver library (quite easy to compile). GH: https://github.com/2night/mondo Dub: http://code.dlang.org/packages/mondo Comments are welcome. Andrea Fontana Dunno if you'll care, but note the name clash: https://getmondo.co.uk/ Don't know if Mondo will actually be successful or not, but if it does, you might have a name clash, especially since they also have an API behind it: https://getmondo.co.uk/docs/ -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: GSoC Deadline Friday
On 16/02/2016 13:46, Craig Dillabaugh wrote: The Google Summer of Code deadline is this Friday. I would like confirmation from the following individuals if they can mentor GSOC this summer. Iain Buclaw Bruno Medeiros Martin Nowak (and as backup Admin) Jacob Ovrum And as backup mentors Adam D. Ruppe Dmitry Olshansky I know for some of you (Iain) the offer to mentor was a 'standing offer' of sorts, but it would still be good to get confirmation. Also the poster 'Dragos Carp' volunteered as a possible mentor for the Protocol Buffers/Flatbuffers work ... so could you please add a short bio to the mentor's page (or post something here): http://wiki.dlang.org/GSOC_mentors We have a decent number of ideas, but the page could use some work. http://wiki.dlang.org/GSOC_2016_Ideas In particular if you can add info to the 'Its Good To Know' sections (such as links to DConf videos), or flesh out some existing ideas that help is welcome. I will continue to try and improve that page. Nope, I won't be available to mentor GSoC this year I'm afraid. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DUB 0.9.24 release
On 20/09/2015 20:36, Sönke Ludwig wrote: Getting close to the 1.0.0 milestone, this release implements all of the major missing features except for a reviewed/cleaned up D API. The most important changes in this release are: - Support for SDLang [1] based package recipes. While JSON is and will stay available, this format is a lot more enjoyable, with support for comments and a much cleaner syntax. See the package format specification [2] for an overview. - Greatly enhanced "dub describe" support - includes a "targets" field usable for external build tools, adds a --data=... switch to output in shell-friendly format instead of JSON, supports a bunch of new environment variables for pre/post build/generate commands and more. - An experimental ARM build is now available on the download page. - Builds with DMD frontends 2.064.2 through 2.068.2. Also new is an online documentation page of the command line interface [3], which is generated from the same information as the command line --help pages. Download: http://code.dlang.org/download Change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md [1]: https://github.com/Abscissa/SDLang-D/ [2]: http://code.dlang.org/package-format?lang=sdl [3]: http://code.dlang.org/docs/commandline Nice stuff, keep up the good work! -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: This Week in D summarizes those long threads for you!
On 25/08/2015 23:55, Laeeth Isharc wrote: https://www.patreon.com/esr?ty=h Ha, nice one, didn't know about that. I've signed up as Patreon - ESR is ok in my book, he's a FOSS proponent, but not a FSF zealot. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: D-Day for DMD is today!
On 23/08/2015 06:17, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Cool stuff! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: D-Day for DMD is today!
On 23/08/2015 06:17, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Cool stuff! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Moving forward with work on the D language and foundation
On 24/08/2015 19:42, Andrei Alexandrescu wrote: I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Cool, I'd be up for contributing in this way. Any thoughts on how that would work though? One off Paypal donations, or a recurring system like Patreon or BountySource's Salt? (https://salt.bountysource.com/) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.13.0 released - DUB configurations support.
On 11/08/2015 18:03, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Minor follow up release: https://github.com/DDT-IDE/DDT/releases/tag/Release_0.13.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.13.0 released - DUB configurations support.
On 11/08/2015 19:06, Colin wrote: On Tuesday, 11 August 2015 at 17:03:35 UTC, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Great work! Thanks. Is the next one going to be Ice Kingdom? Ha, I think I'll stick with one fandom at a time :) TBH, with short release iterations, it very rarely feels right to give a nickname to a release, since now they usually have only a few changes. (This has even prompted me to blog about it here: http://www.pureconcepture.blogspot.co.uk/2015/08/for-me-one-disadvantage-of-short.html :p ) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.13.0 released - DUB configurations support. (RC2)
On 11/08/2015 18:03, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Follow-up Release Candidate 2 is out: * Fix missing .exe suffix in Windows, in Program Path field for Build/Launch. * Fixed: null text inserted when cancel pressed in Variables... and other dialogs. * Fixed: project files not being refreshed when Build Target build invoked directly from Project Explorer. -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.13.0 released - DUB configurations support.
A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.12.0 release - many internal changes.
A new version of DDT is out. This release brought forth many internal changes, and may be a bit more buggy than typical. Please read the Important changes section of the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.12.0 -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.12.0 released - many internal changes.
A new version of DDT is out. This release brought forth many internal changes, and may be a bit more buggy than typically. Please read the Important changes section of the changelog: http://ddt-ide.github.io/releases/ -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released (please read!)
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Note that there is a tool recently released, Eclipse Optimizer, that can help optimize Eclipse startup time: Also, to improve Eclipse performance and startup time, it is recommended you tweak the JVM parameters. There is a tool called Eclipse Optimizer that can do that automatically, it is recommended you use it. Read more about it http://www.infoq.com/news/2015/03/eclipse-optimizer . (Installing/enabling the JRebel optimization is not necessary as that only applies to Java developers) I've added the above info to the User Guide. Also, because Google Code is shutting down, I've moved the DDT project homepage to: http://ddt-ide.github.io/ -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 23/03/2015 15:35, Ben Boeckel via Digitalmars-d-announce wrote: Running a Python script to generate D code? Yes, in DUB you can run arbitrary external commands before and after the D sources compilation. But not in between? Basically, can you have a tool written in D built with the project and then used to generate code in the same project? --Ben That should be possible if you split it into two bundles or so, if I understood that case correctly. The external commands run before and after a compilation of a bundle (known in DUB as package). So you could have: 1. bundleA - pre external commands 2. bundleA - D sources compilation 3. bundleA - post external commands 4. bundleB - pre external commands 5. bundleB - D sources compilation and so on.. (if bundleA is set as a dependency of bundleB) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 23/03/2015 23:01, Ben Boeckel via Digitalmars-d-announce wrote: On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via Digitalmars-d-announce wrote: On 2015-03-23 13:54, Bruno Medeiros wrote: There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. I would guess he means using C(++) files and D files in the same project and the build system would just work. From what I understand[1] of Eclipse (which I admit isn't much from a user's PoV), it supports natures to be loaded which provide functionality. Now I have no idea how much work this is, but it would be nice to have a nature for D support (syntax highlighting, completion, etc.). If it includes dub, great, but it might be worth it to have a separate nature for that. CMake (and other theoretical tools) would then just add the D support nature to handle the D files and use the existing build support. Projects created through DDT itself could add the dub nature by default (FWIW, I don't think CDT generates CMake-based projects out of the box either). Basically, make DDT suitable for using it with other projects which don't use dub because it doesn't suit the upstream project whether it be because the project is more than some D code, YAML is preferred to JSON or whatever. Take my gunroar[2] repo for example. It's mainly D code, but there is some C and Java in the src/android directory. If one were working in Eclipse with it, it would be nice to support using CDT features for the C code, the native Java support for the Java code, DDT for the D code, and the build button to put it all together. --Ben [1]This is based on my experience where enabling the Android bits in an Eclipse project generated by CMake is to allow users to add natures to the generated .project file using the ECLIPSE_EXTRA_NATURES global property. [2]https://github.com/mathstuf/abagames-gunroar Yes, there is a D nature for Eclipse's .project: org.dsource.ddt.ide.core.nature Curiously though, a few DDT features will work fine without that nature, namely semantic features (code completion, go to definition, etc.). They even work with external files (files not in an Eclipse project), as long as they are part of a DUB bundle (known in DUB as a package). This is because, for example, when invoking code completion on a D source, DDT will try to find a dub.json file in the tree of parent dirs of the D file. Once it finds it, it will analyze the source structure of that bundle and all its dependency bundles (using `dub describe`, and then code completion will have all module information correctly available. And the caching of the semantic engine will still work just fine. :) As for not using DUB. Hum, I could add feature of a flag to a project options to prevent it from using DUB (the executable). This way the DUB build would be a no-op, and `dub describe` would not be run either. You would still have to use the dub.json file to describe source folders though. (Again there's no sense in making a new format to describe this) As for your gunroar example. I don't know how CMake generates an Eclipse project, but that scenario that sounds like it should have multiple Eclipse projects generated. (One for D code, one for C bits, another for Java bits) Trying to shove everything in one project wont work properly. (The directory structure of gunroar might have to be changed a bit to accommodate that though) An Eclipse project is a build unit, and is not the equivalent of a VisualStudio solution. An Eclipse workspace is much more akin to a VS solution. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 24/03/2015 02:22, Manu via Digitalmars-d-announce wrote: On 23 March 2015 at 22:39, Bruno Medeiros via Digitalmars-d-announce In Visual-D you can even press F12 (go to definition) on an extern(C) symbol in your D code, and it will jump to the .cpp file where it's defined. That's quite nice. And what exactly seamlessly means here, what is offered in Mono-D that couldn't be done in DDT? Automatic linking between sibling libs within a solution, referencing of symbols between the languages/projects, automatic rebuild dependencies between sibling projects. I'm sure it could all be done in DDT. I'm just saying that as an end-user I would expect that level of interoperation with CDT and no less. I haven't tested those things, they may already work. Just FYI: referencing of symbols between the languages/projects definitely doesn't work at all. The rest, Automatic linking between sibling libs within a solution, automatic rebuild dependencies between sibling projects, etc., that won't work out of the box, but can be made to work if you go configure Eclipse options, and build system configuration. Requires some work, it won't be seamless. I'm gonna me straight up with you about DDT: With work, probably a lot could could be achieved in terms of CDT C/C++ integration. But, personally, I became interested in the D world to completely escape the C/C++ one. I don't use C/C++ professionally or on a hobby basis. That means doing CDT integration (other than trivial stuff) is low priority for me - even though I fully agree that better D and C/C++ toolchain integration is very important for D's success, if not vital. And low priority, given all the stuff I have planned in the DDT (siblings) roadmap, effectively means: not gonna get done. Unless someone else wants to work on that (that would be welcome of course). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote: On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 18/03/2015 00:12, Trent Forkert wrote: Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). Why is that 'duh'? I would expect nothing less than for DDT and CDT to interact comprehensively. Fair enough on that last 'duh', it could have been that DDT integrated with CDT. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms. Do they now? I'm inclined to try them out again because I'm a bit skeptical of that comment, as least in how it applies to this discussion. For example, does Mono-D allow to seamlessly create a crossplatform solution with a D project interacting with a C project (and/or the opposite). And what exactly seamlessly means here, what is offered in Mono-D that couldn't be done in DDT? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 19/03/2015 15:55, Trent Forkert wrote:
On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote:
On 19/03/2015 14:45, Trent Forkert wrote:
It seems you are right that it *is* limited, but it shouldn't be. CMake
emits include/import paths into the project structure. I had thought it
emitted into .project, but evidently emits into .cproject. If DDT
supported a .dproject I could also emit, I could get it to work.
DDT does support a .dproject ... it's called dub.json ! ;)
I'm dead serious here though. Why would I invent my own file format to
describe source folders and include/imports paths when dub.json does
that already??
1. I don't consider an XML configuration to be your own file format
Err.., but it is. XML is just syntax, you still have the semantics of
what that data means to be defined. Just as learning XML doesn't mean
you know how to properly read/write HTML5! (Maybe there is a better term
than file format, but regardless I think my comment was clear.
2. For the very reason that started this entire conversation. Not
everybody *wants* to use dub. Not everybody *can* use dub. So it doesn't
make sense for DDT to force dub.
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
It would be silly to use anything else.
VisualD has done pretty well for itself.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 05:30, Manu via Digitalmars-d-announce wrote: On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. I would imagine that if you had complete control over the project description and build process, it would be much easier to integrate with other components in Eclipse? Of course, I have no idea whether that's true or not. But I will hazard a guess that using dub in this way must make it harder for you to interact with CDT/java tools than otherwise? There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. It would also be really nice to have a UI with tick boxes and select boxes for all the relevant build settings like CDT. Yeah, true. Even if using DUB, it would be nice to have UI to control the settings in dub.json, but that's a fair amount of work for little gain, so down in the priority list. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 18:07, Trent Forkert wrote: And I don't understand why it is not acceptable. * Because it is not guaranteed to be there. For instance, I don't have dub on my system That's the lamest reason ever. Why is that an issue? Just install it if it is not installed. To me, that's akin to saying DDT shouldn't have a requirement of the Java VM! * Because anybody not using dub should not be required to use dub. This is dlang, not dublang * Because I just want to tell Eclipse about the project, there is no need to involve dub * Because the user said so These are basically all the same reason: me no want to use dub!. Well, you're free not to use DDT either! Seriously, I don't understand the *gripe* here: DUB offers a service, a functionality, that is not offered elsewhere (for D at least): a package management system, for source packages. And this is an important functionality for language ecosystems, because it is so damn useful!! That's why nearly all modern language have a source-package manager (Rust - Cargo, Ruby - rpm, Go - `go get/install`, Java - Maven/OSGi), all of them integrated with a build tool. I hope your experience/mindset has not been too tainted with archaic C/C++ paradigms that you fail to see this. D actually lags behind these languages in that DUB is not an official part of the language/toolchain. Although from what I recall there are plans to make DUB included as part of the DMD installation, so that would change. * Because it is at odds with C/C++ integration, which is an H1 priority This is the only reason with some credence. However, *not using dub* doesn't makes DDT automatically integrate with C/C++, nor doesn't it even necessarily bring it any closer to that. A fair amount of work would still need to be done to properly support this scenario, I suspect. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 23/03/2015 13:39, Ben Boeckel via Digitalmars-d-announce wrote:
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project?
Yes - use DUB sub-packages.
Different flags to different source files?
What dicebot said.
That looks like an invalid, abstraction-breaking thing to do
Running a Python script to generate D code?
Yes, in DUB you can run arbitrary external commands before and after the
D sources compilation.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
I thought about that - VS2013 Community Edition -, but it looks huge and
I don't want to install a bunch of library and stuff on my computer just
to try VisualD out. I'd do it in a virtual machine though, as its
worthwhile to check it out. But it will just have to wait until I get
around to it, I don't have a spare Windows VM or installation at the moment.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 05:04, Manu via Digitalmars-d-announce wrote: On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I just checked out DDT, and I noticed it seems to use DUB... _ Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one DUB Options box. The comprehensive suite of build options CDT presents would be much nicer. It makes no sense for DDT to use anything else than DUB. At a minimum, DDT needs a way to describe projects: the source files that are part of the project, and which other projects are dependencies of said project. Other aspects of a projects that are good to be able to describe are: which build configurations the project supports, which executables are produced (if any), etc.. Now the reason DUB is used is that it's a bad paradigm for this description mechanism to be Eclipse/DDT specific. It's unequivocally much better to be Eclipse-independent, such that other tools (not just other IDEs, but even other command-line analysis tools) can understand D projects/bundles/packages just as well as DDT. It also saved me a lot of work. If I had to develop my own format to describe all these aspects, it would not be as good as DUB's, guaranteed! I reckon this is true for any other D IDE out there. I use Mono-D and VisualD extensively, and in lieu of those, I fallback to makefiles. Those certainly did make their own equivalent build systems matching the IDE's existing styles. Those IDE's integrate D nicely with the C/C++ experiences. We might have different notions of what as good as DUB's means then. Let's look at these two use cases: * Do those IDEs allow a project specifying a dependency on an D library, without having to download the library, or to configure the build settings for the library? And does doing so still make it possible to integrate with C/C++ projects? * Can you have a cross-plaftorm workspace/solution, and when building the D part of it, the IDE parses the error messages of the D compiler and reports then to the UI in the editor? DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too:( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? I have no idea how Eclipse operates internally... and I shouldn't have to. Isn't that the point of an IDE? All I can say is that CDT works, and I don't know how. If DDT doesn't automatically work with it out of the box, then the IDE experience is kinda pointless (to me at least). If I have to fiddle with a build system by hand, then that undermines the whole point of the IDE as far as I'm concerned. C/C++ and D are related, and they must interoperate. It's the top of the D roadmap. If I'm an IDE user, I think that's more-or-less an admission that I don't understand build environments, and I don't want to. So from that perspective, I think it would be valuable work to make sure DDT and CDT understand eachother. Yes, it would be nice if DDT would automatically integrate with CDT, and handle this use case seamlessly (regardless of using DUB internally or not). But this would be complex work, for little gain. Let me go into detail. First of all, CDT works, and I don't know how: yeah, but CDT only had to concern himself with C/C++, no cross-language stuff. Like you said, DDT and DUB also works well if you stick to the D ecosystem only. If you put a cross-language requirement on DDT, you're actually asking more of DDT than CDT had to worry (which means more work, more complexity). CDT and VisualStudio are IDEs with big companies backing them, they both had multiple developers working on them, full-time, for many, many years now. DDT only has had me working on it, on a volunteer basis (although some of the work I do there, and in Goclipse and RustDT, is related to some commercial work I do). Still, it's just me ATM, so there is an order of magnitude of difference of manpower available. You can't expect the same level of completeness. Only the most critical/important features can be worked on (or simple to implement ones). Also, there is limited gain. Sure, C/C++ and D are related, but A) Not everyone in D world is that concerned with that scenario, C/C++ integration. B) More importantly, adding DDT integration with CDT, would only benefit users of DDTCDT combined, which is a fraction of 'C++ D' users. What about users (and you might be one) that at the end of day don't use DDT/CDT because you can't debug
Re: DDT 0.11.0 released
On 19/03/2015 16:02, Ben Boeckel via Digitalmars-d-announce wrote: It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) Building file-at-a-time is, for developers, on the whole faster than unity builds because you can parallelize it and only have to build what changed. CMake only really works with .d - .o rules (Java support bends this AFAIK due to restrictions in javac, but I vastly prefer -j8 over a single invokation). I think the issue of speed and parallellization is an orthogonal one: The build components should be structured in properly defined, self-contained, versioned libraries/bundles(*) - that can be built, and auto-tested on their own (obviously using the dependencies they require too). That should be the primary (top level) build unit of a build system. But, the way you build each bundle/component, is still up to the build system. You can build it on file-by-file sequentially, or parallelized, etc. I'm not familiar with CMake, so I don't know if it has any concept similar to this, but I suspect not. *: AKA packages in DUB and Ruby, crates in Rust. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 18/03/2015 22:09, Trent Forkert wrote: On Wednesday, 18 March 2015 at 21:12:11 UTC, Bruno Medeiros wrote: What kind of Eclipse projects does it generate? CDT. Anything else would prevent it from supporting multi-language projects, and thus turn it into yet another crappy monolingual NIHS tool, and thus useless for me (and Manu). If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), Nor does it need to. The project builds with either Make or Ninja, and Eclipse doesn't even care that it is building D code, and will build successfully even if you don't have DDT installed. and DDT doesn't work with CDT projects (also duh). Not sure what you mean by that. Installing DDT allows Eclipse to see *.d files (in any project, DDT, CDT or otherwise) as D files that will be opened in Eclipse's editor with syntax highlighting, completion, etc. Without DDT, Eclipse opens D files in an external editor. I just double checked, this all still works as I was expecting it to. When I said it's not really much help, I didn't mean for building: I meant for code completion and other semantic functionality. A CDT project description means nothing for DDT, and as such, code completion and other semantic functionality won't work properly (you will get code completion for the standard library, and for symbols of the .d file you opened, but any other imports/modules will not be found). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 19/03/2015 11:18, Dicebot wrote: On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 18/03/2015 00:12, Trent Forkert wrote: Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I also couldn't launch GDB and debug the example 'hello world' app under Windows. Are there more steps to make this work? If you're using DMD, that simply doesn't work at all. GDB doesn't understand any of the debug formats DMD outputs (COFF/MSVC or OMF), and it likely never will. GDC for Windows is not maintained. As LDC for Windows, I haven't tried it recently. Last time I tried it, debugging support wasn't working ( http://forum.dlang.org/post/qsttkqzbtnhyrogek...@forum.dlang.org ). However may be that has changed recently? I dunno about LDC itself, but I've tried the Rust compiler for Windows, and although a bit buggy, basic debugging support was working: https://raw.githubusercontent.com/RustDT/RustDT/master/documentation/screenshots/sample_debug.png So the same should be possible for LDC as well! Note: I try to collate this information in http://wiki.dlang.org/Debuggers , although perhaps Debugging support should listed by platform, instead of by compiler. If you absolutely must use DMD/MSVC toolchains, well there might be some hope int the future, since work is being done on LLDB such as to be able to debug MSVC executables: http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html (LLDB has an interface emulating GDB, and as such should integrate with Eclipse and other GDB UI frontends) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) A new release fixing a critical regression is out: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 06/03/2015 17:37, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Also fixed that this 0.11.0 version was being reported as 0.10.4 still. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 06/03/2015 18:48, wobbles wrote: On Friday, 6 March 2015 at 17:37:51 UTC, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) This is great, thank you! Just to let you know, in release notice there is the text It is recommended that Recommend re-create project. Im guessing it is meant to be: It is recommended to re-create you're project. Yup, thx, fixed that. -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.11.0 released
A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: GSoC 2015 - Application Rejected
On 02/03/2015 23:00, CraigDillabaugh wrote: On Monday, 2 March 2015 at 22:36:43 UTC, weaselcat wrote: On Monday, 2 March 2015 at 19:08:49 UTC, CraigDillabaugh wrote: Unfortunately our organizational proposal for the 2015 Google Summer of Code was rejected. Thanks to everyone who helped out on this, especially to those who volunteered to mentor. I've asked Google to provide me with feedback, and I will post that here once/if I get something from them. If I am not asked to resign I am happy to volunteer for this post again next year. Hopefully I can learn something from this year and any feedback they provide. Cheers, Craig List of accepted projects https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015 a lot of other languages got accepted :( Yes, but I didn't see Rust, Nimrod, or Go on there, so I suppose we are on even footing with our main competition. Not just Rust, the whole Mozilla was not accepted either: http://blog.queze.net/post/2015/03/03/Mozilla-not-accepted-for-Google-Summer-of-Code-2015 Interesting quote: People who have observed the list carefully may have noticed that there are fewer accepted organizations this year: 137 (down from 190 in 2014 and 177 in 2013). Other organizations that have participated successfully several times are also not in the 2015 list (eg. Linux Foundation, Tor, ...). -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.10.4 release - fixed critical performance bug
A new DDT version is out. Even though it's a minor release, I'm announcing this one here, because it fixes a critical performance bug, introduced in 0.10.0 (DUB support), but only discovered recently: https://github.com/bruno-medeiros/DDT/releases/tag/v0.10.4 The bug is #88, it would cause major delays when using code completion and other semantic features in dub packages that had subpackages (or depended on subpackages, directly or indirectly) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.10.4 release - fixed critical performance bug
On 12/12/2014 17:06, Bruno Medeiros wrote: A new DDT version is out. Even though it's a minor release, I'm announcing this one here, because it fixes a critical performance bug, introduced in 0.10.0 (DUB support), but only discovered recently: https://github.com/bruno-medeiros/DDT/releases/tag/v0.10.4 The bug is #88, it would cause major delays when using code completion and other semantic features in dub packages that had subpackages (or depended on subpackages, directly or indirectly) Oh and also, I would like to make a call for anyone who experiences performance problems or other similar issues to report those or mention them in a relevant thread. Otherwise they might go unnoticed, just as this one did! I don't currently work with large D projects, nor even with D projects that use large libraries (like DWT or GtkD), so such issues can easily be missed for a long time by me if no else reports them. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: LDC 0.15.0 alpha1 released! Please help test!
On 25/10/2014 12:58, David Nadlinger wrote: On Saturday, 25 October 2014 at 09:38:45 UTC, E.S. Quinn wrote: I notice that there's no mingw based windows version with his release. That's just an issue with building the packages for the alpha, the release will have a MinGW version. David But does the LDC MinGW build support debugging information now? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 09/09/2014 20:16, Jacob Carlborg wrote: On 2014-09-09 15:06, Bruno Medeiros wrote: Oh I see. Do people like this behavior BTW? Eclipse could also be configured to work like this, but I'm not sure I would like it, (even if there are no problems such as slow autocompletion.). But maybe it just cause I'm used to it. I wouldn't mind having an option for it. It's already possible to do it (although not obvious at all). Just go to Preferences/DDT/Editor/Content Assist and put the .abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ string in the Auto activation trigger characters field. (It works for JDT too) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 07:30, Jacob Carlborg wrote: On 04/09/14 23:41, Bruno Medeiros wrote: Why is that ugh? You don't have to save the file on each keystroke, just when completion is invoked, right? In MonoDevelop/Visual Studio the completion is basically invoked as soon as you start to type something. Not as in Eclipse when it's invoked manually or only when typing a dot. Oh I see. Do people like this behavior BTW? Eclipse could also be configured to work like this, but I'm not sure I would like it, (even if there are no problems such as slow autocompletion.). But maybe it just cause I'm used to it. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 00:23, Brian Schott wrote: On Thursday, 4 September 2014 at 22:05:35 UTC, Bruno Medeiros wrote: BTW, what is the relation of dscanner to DCD? Or more precisely, why are they separate tools?.. Originally there was just dscanner. One of the things that it did was autocomplete. It wasn't very good at this for a variety of reasons. One of them was that being a plain command-line tool, it had to re-parse EVERYTHING every time you asked for autocomplete. Over time I split the project three ways: The parser/lexer/ast is now libdparse, the autocomplete functionality is in DCD, and static analysis and other stuff is in dscanner. The reason I ask is because there seems to be some functionality only present in dscanner that would be useful for IDEs too, such as dscanner --declaration -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 05/09/2014 17:40, Alex wrote: On Friday, 5 September 2014 at 12:15:09 UTC, Bruno Medeiros wrote: On 05/09/2014 07:32, Jacob Carlborg wrote: Perhaps I'm nitpicking but an external tools doesn't sound like a good idea. A completely separate library that can be shared among tools and be integrated into an IDE, absolutely yes. But not a tool. It's like it was said earlier, a library is easier to integrate, but only if across the same language (for the code the library is written in, and the code the IDE extensions are written in). Well, I spent a (very little though) time getting informed on how everything could be done using dcd-server running in the background. 1) the communication between dcd-server and dcd-client happens via tcp ipc. So extremely easy to implement 2) The currently edited module's text can be piped through that IPC channel to not have to query the hardware IO all the time. 3) My completion 'model' allows having individual import paths for each edited file, project, super-project aka solution. DCD seems not to support this atm(?). 4) D_Parser is heavily woven with all kinds of Mono-D features, so just ripping out the completion component and replacing it with dcd won't bring anything sustainable, since I'd still had to have raw access to all ASTs out there in order to e.g. display a 'breadcrumb' path bar on the editor's top, the doc outline, refactoring features etc. -- An entirely separate Mono-D is needed imho which probably only features basic projecting/build support as well as dcd bindings. Did you, Bruno, discarded your customly written completion framework in favor of dcd? I didn't discard my completion engine, since from what I saw in DCD (at least at the time), DCD didn't seem better than mine (only Mono-D has that honor at the moment ;) ) So I'm keeping it, also because there are a lot of improvements I can make to DDT's completion engine with relative low effort (I just had my time caught up in other features to go into that). Also, there were several limitations with the DCD protocol and/or options. First was lack of DUB support. Then, limited information on the resolved symbols (for example function symbols don't have the full function signature). Then there was also the inability to perform completion with in-memory files. (At least using DCD-client. Are you saying what if the we communicate directly to DCD-server, that is possible? I haven't looked into that, only the README documentation of DCD) I fixed most of these by rolling my own semantic daemon (note, it's not finished yet). Although, to be honest, even though I made an API that supports semantic operations in multiple in-memory files, after I saw Atila Neves lightning talk about fly-check in Vim, I'm fairly convinced just automatically writing all files to the disk would have been good enough, if not even better (I'm thinking the OS would cache the files, so I/O would not be an issue... but that premise would have to be tested) The only significant issue is the same as you mentioned in 4) . I could shift all my semantic features to the daemon at this point, but I would still need a D parser as part of DDT for all the syntax features - the editor outline, code folding, the breadcrumb, etc.. This functionality would have to be moved to the daemon so that the IDE could be completely free of any D parser or D engine. While that is certainly feasible, I wonder if there could be a significant performance hit: The semantic features (code complete, open definition) are only invoked sporadically, but parsing/syntax features require parsing on more or less every keystroke - so that info would have to be retrieved from the daemon nearly constantly, and would add some overhead... It's something to consider. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DCD 0.3.0, libdparse 0.1.0
On 04/09/2014 22:48, David Gileadi wrote: On 9/4/14, 2:29 PM, Bruno Medeiros wrote: On 04/09/2014 09:06, Brian Schott wrote: If you've heard of Jedi or Gocode, I know gocode, but what's Jedi, out of curiosity? I couldn't google it because, well, Star Wars obviously.. The google is weak with you, young Padawan. Assuming from the context that it's some kind of autocompletion library like DCD you can search for https://www.google.com/search?q=jedi+autocomplete Lol, true that. I tried Jedi tool and Jedi code, but didn't occur to use autocomplete... (and the ones I tried still have a full Star Wars connotation) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DCD 0.3.0, libdparse 0.1.0
On 04/09/2014 09:06, Brian Schott wrote: If you've heard of Jedi or Gocode, I know gocode, but what's Jedi, out of curiosity? I couldn't google it because, well, Star Wars obviously.. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 14/08/2014 08:05, Alex wrote: On Wednesday, 13 August 2014 at 21:29:01 UTC, Damian Day wrote: On Wednesday, 13 August 2014 at 14:16:18 UTC, Alex wrote: Hey everyone, it's been quite some while ago that I posted a Mono-D release announcement on to D.announce :) You should've noticed that the installation instruction stuff has been moved to the D wiki - http://wiki.dlang.org/Mono-D There have been several fixes and smaller improvements since the last bunch of bug fix releases. Detailed release notes can be taken from the wiki entry. Cheers, Alex Have you considered integrating some of Brian Schotts work? Perhaps an option to pick an engine DCD or DParser. I'm particularly interested in dscanner integration myself :) In theory, it should be possible if the IPC between the dcd clientserver is not too tricky to handle (or is it indeed just a command call? -- But then I had to save a file first to be able to get completion for nearly each keystroke..ugh). Why is that ugh? You don't have to save the file on each keystroke, just when completion is invoked, right? Even taking the issue of code completion out of the picture, I've recently come to realize that implicit save of IDE files might be good thing on its own, from a UI paradigm perspective (see this comment http://forum.dlang.org/post/lrvna6$2btb$1...@digitalmars.com). I saw this first hand when I tried IntelliJ for the first time a few months ago. It actually struck me as a really nice paradigm, especially so for IDEs, which usually keep a modification history of files already. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: [Mono-D] v2.1.18 Parser/Completion/General fixesimprovements
On 14/08/2014 01:54, Brian Schott wrote: On Thursday, 14 August 2014 at 00:43:38 UTC, Damian Day wrote: I'm not sure you'd want to do that. The DParser completion engine has a few features that DCD doesn't have. (I'm not sure if this is true the other way around) That's true, but duplicated work and all that.. It would be a nice way to battle test DCD and the lexer. Keep in mind that integrating a lexer/parser written in C# into an IDE written in C# is much easier than integrating libdparse would be. The same argument applies to Eclipse and Visual Studio. True, but I'm now convinced that most likely, an IDE/editor architecture where most (if not all) of semantic analysis and operations are performed by an external tool, is the way forward. (Steve Teale made a case for this in a post quite some time ago, I wasn't that convinced then, but I am now) The market of IDEs/editors for new languages is extremely saturated. Even for older, consolidated languages, the market has become more diverse. It used be that Eclipse-JDT was king for Java, or Visual Studio for C# (and C++ to a degree). But now a lot of people swear by IntelliJ IDEA and Netbeans (for Java), and there's MonoDevelop too, for C#. This means its increasingly harder for each IDE/editor to develop their own, full semantic engine, since there is more competition. Especially for upcoming languages where most tooling is being develop by volunteers. With this realization I have started to move DDT to this architecture, it's something that I have been working for the past few months. I'm particularly interested in dscanner integration myself :) Are you talking about displaying static analysis hints in the editor window, or something else? Yes precisely. BTW, what is the relation of dscanner to DCD? Or more precisely, why are they separate tools?.. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Eclipse D Development Tools (DDT) plug-in version 0.10.2 released
On 28/08/2014 22:54, Daniel Kozak wrote: On Thursday, 28 August 2014 at 21:20:48 UTC, Bruno Medeiros wrote: In particular this was a minor release and likely not that worthy of D.announce . There wasn't that many improvements or bug fixes either, you are over-selling it. I don't agree with you, It's worth it. For myself it is very interesing release, because I have Luna and I am on Arch linux :). I would still have posted on D.ide (and the DDT Google Groups), that's what I do for minor releases. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Eclipse D Development Tools (DDT) plug-in version 0.10.2 released
On 29/08/2014 02:51, Dicebot wrote: On Thursday, 28 August 2014 at 21:20:48 UTC, Bruno Medeiros wrote: I appreciate your enthusiasm, but in the future let me post the release announcements myself. In particular this was a minor release and likely not that worthy of D.announce . There wasn't that many improvements or bug fixes either, you are over-selling it. Changelog for new release: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.2 You may underestimate importance of dub dependency support :) Seems like there was a misunderstanding here, little has changed in terms of dependency support (there was already support for DUB dependencies before). The difference is just what happens when semantic operations are invoked (code completion, etc.), depending on the *editor* file where they are invoked. Before, if you invoked such an operation on a file from a DUB package, but that DUB package was not an Eclipse DDT project, the semantic operation would just resolve the elements in that module file, and see nothing else. It would not see DUB dependencies, nor even other source files from the same DUB package. This is what changed. -- Bruno Medeiros https://twitter.com/brunodomedeiros
The No Explicit Save UI paradigm
On 07/08/2014 15:45, David Gileadi wrote: On 8/7/14, 4:18 AM, Bruno Medeiros wrote: This is an interesting behavior I've come across, even before watching this talk: Recently I tried IntelliJ IDEA, and it also goes away with any explicit UI notion of saving a file. It just saves files automatically, as you type. This is interesting, and might well be a marked improvement in UI behavior... This is a UI direction that Mac OSX is going in, presumably as part of their push to bring iOS behavior to the desktop. Apps that use it save as they go, and they have a standard UI to browse through previous versions of your document if you want to go back to (or crib from) something earlier. Interesting. Indeed the only potential issue I saw with this approach was, how does the application mark each local history version of a document? With explicit save it's easy, just create a new version in the local history each time the document is saved. Without explicit save... A smart algorithm/heuristic would have to be put in place. Something like saving a new version after a user stops typing after a while (5min or so?), or after a significant number of changes occurred. (if the local history is smart enough and saves changes incrementally, it can actually store every single change actually) In any case that's workable, and overall it seems like an improvement in UI design. It even reminds me of the talk Inventing on Principle talk Bret Victor gave ( http://vimeo.com/36579366 ), in particular the aspect about reducing (if not removing entirely) the save/compile/run cycle. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DConf 2014 Lightning Talks
On 21/07/2014 20:13, Andrei Alexandrescu wrote: Now available from youtube by default. http://www.reddit.com/r/programming/comments/2bbklj/dconf_2014_lightning_talks/ https://twitter.com/D_Programming/status/491299147015012352 https://www.facebook.com/dlang.org/posts/888753774471638 Andrei In Átila's talk, there is an egregious misuse of the term syntax checking, applied to what is actually language *semantics*, not syntax... ^_^' But cool talk, and cool tool. One question though, I'm hoping people familiar with Emacs could clarify to me: I assume that for flycheck to work in the continuous (as-you-type) way that it is shown to be working, then the files being edited have to be saved on to the disk, so that dmd can check them. Is it this saving done to the actual underlying files, or to some sort of copy? (I'm guessing that it's to the actual underlying files) This is an interesting behavior I've come across, even before watching this talk: Recently I tried IntelliJ IDEA, and it also goes away with any explicit UI notion of saving a file. It just saves files automatically, as you type. This is interesting, and might well be a marked improvement in UI behavior... -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15/07/2014 02:59, Manu via Digitalmars-d-announce wrote: I have had problems with the linker when trying to link GDC and MSC objects together. You lose the debug info for one or the other world. You can't have dwarf and cv8/pdb together. And to be useful, there would need to be some visual studio integration for dwarf debugging :/ Linking problems aside, if GDC on Windows produces proper DWARF debug info, you can debug the GDC compiled code with GDB and a graphical frontend such as DDT+CDT, you don't need Visual Studio. But, like you said, the Windows/MingW port of GDC is not maintained so it's all just theoretical as things stand. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Interview at Lang.NEXT
On 17/06/2014 07:21, Jacob Carlborg wrote: On 16/06/14 16:00, Bruno Medeiros wrote: I sometimes tried to convince dynamic language proponents - the ones that write unittests at least - of the benefits of static typing, by stating that static typing is really just compile time unit-tests! (it is actually) You can actually do compile time unit tests in D, that is not the type system. I.e. unit tests for CTFE functions that runs at compile time. Pretty cool actually :) I know, pretty cool yeah. But specific to D, I was talking about static typing in general. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 20:59, Dicebot wrote: On Tuesday, 17 June 2014 at 19:48:42 UTC, Bruno Medeiros wrote: On 17/06/2014 19:10, deadalnix wrote: On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote: Dunno about DScanner, but if it's being used in DCD, I'd guess it can handle the whole language, or be fairly close to it. Similarly, there is also DParser2 from MonoD and the DDT parser (for the tool I'm working on) HAHAHAHAHAHA ! (The author of these actual tools will tell you the same). I don't understand what point is it you're trying to say here... Are you saying it's ludicrous that people have written complete parsers for D? Parsing D is relatively simple but making any reliable changes without full (and mean _full_) semantic analysis is close to impossible because of code generation and interleaving semantic stages. A lot of simple changes could be made with little or no semantic analysis. I'm not talking about complex refactorings such as Extract/Inline Function, Introduce/Remove Parameter, Pull Method Up/Down, extract Class/Interface, etc. Rather, simple fix changes that would be useful if the API or syntax of the language changes. That's why I asked for examples of dfix changes (even if for hypothetical language changes) - to see how easily they could be implemented or not. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 16/06/2014 22:10, Stefan Koch wrote: The thing I have in mind should be really easy for simple tasks as in `if constuctor in any class has parameter of type oldRouter change that parameter to type new Router` but i habe yet to find a good notation for that I guess a DSL for simple manipulations can be ok to have. But for more complex stuff better to just use the language the parser is written in. I'd guess most people would just be using pre-written manipulations anyways. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 07:25, Jacob Carlborg wrote: On 16/06/14 15:43, Bruno Medeiros wrote: What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) * The parser haven't been available for that long (I think) * Can they handle whole language? Dunno about DScanner, but if it's being used in DCD, I'd guess it can handle the whole language, or be fairly close to it. Similarly, there is also DParser2 from MonoD and the DDT parser (for the tool I'm working on) * Semantic analysis is needed. Otherwise as soon as someone uses templates or mixins the tool won't properly work I think there would be a lot of modifications that one can do without semantic analysis (or limited analysis). But that's why I asked for examples of dfix scenarios. Adding final to every method in certain classes could be done without semantic analysis. Reworking certain constructs to different constructs possibly as well (for example change foreach_reverse to just foreach usage) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 16:45, Bruno Medeiros wrote: Dunno about DScanner, but if it's being used in DCD, I'd guess it can handle the whole language, or be fairly close to it. Similarly, there is also DParser2 from MonoD and the DDT parser (for the tool I'm working on) And DDT is fairly complete, AFAIK, and well covered in tests. There might be some syntax I have missed if I misunderstood the grammar, but that should be fixable easily. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 16:45, Bruno Medeiros wrote: Similarly, there is also DParser2 from MonoD and the DDT parser (for the tool I'm working on) And the DDT parser is fairly complete, AFAIK, and well covered in tests. There might be some syntax I have missed if I misunderstood the grammar spec, but that should be fixable easily. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 19:10, deadalnix wrote: On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote: Dunno about DScanner, but if it's being used in DCD, I'd guess it can handle the whole language, or be fairly close to it. Similarly, there is also DParser2 from MonoD and the DDT parser (for the tool I'm working on) HAHAHAHAHAHA ! (The author of these actual tools will tell you the same). I don't understand what point is it you're trying to say here... Are you saying it's ludicrous that people have written complete parsers for D? * Semantic analysis is needed. Otherwise as soon as someone uses templates or mixins the tool won't properly work I think there would be a lot of modifications that one can do without semantic analysis (or limited analysis). But that's why I asked for examples of dfix scenarios. Until you hit a static if. Which is always. Adding final to every method in certain classes could be done without semantic analysis. Reworking certain constructs to different constructs possibly as well (for example change foreach_reverse to just foreach usage) ditto. How would a static if prevent a tool from adding final to every method in a specified class? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 17/06/2014 20:12, Jacob Carlborg wrote: On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote: Adding final to every method in certain classes could be done without semantic analysis. Reworking certain constructs to different constructs possibly as well (for example change foreach_reverse to just foreach usage) What about methods added via template and string mixins? You cannot add final to a method in a template, because you don't know if it will be mixed in into a class or struct (does the compiler allow final on struct methods?). There's no possible way to handle string mixins, a method can be built up by concatenating strings. -- /Jacob Carlborg Methods added through string mixins would not work. Actually, any AST modification would probably not work through string mixins. That would be an incredibly difficult problem to solve - in many cases, impossible even. And perhaps rightly so, one could make a case that string mixins should be used sparsely? We have to realize that string mixins are very useful, but are a dirty hack that is a replacement for AST macros. As for methods added via templates, the tool would present the option to add final to those templates as well, or just the class. If doing do might break other classes that use the same template, well, that is a problem that transcends whether this transformation is done manually or by a tool. It would not be an issue with dfix itself then. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 12/06/2014 18:53, Andrei Alexandrescu wrote: On 6/12/14, 10:40 AM, Nick Sabalausky wrote: On 6/10/2014 12:35 PM, justme wrote: On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote: Of possible interest. http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/ Andrei IMHO, the coolest thing was when Rob Pike told about the tool they made for automatically upgrading user source code to their next language version. That should be quite easy to implement now in D, and once done, would give much needed room for breaking changes we feel should be done. Pike seemed to be extremely satisfied they did it. Personally, I wouldn't be comfortable trusting such a tool. Besides, I find that upgrading a codebase to a newer language version is one of the most trivial tasks I ever face in software development - even in D. It's a cute trick, but not a worthwhile use of development resources. I very much think the opposite, drawing from many years of hacking into large codebases. I'm completely with Rob here. On a large codebase, even the slightest manual or semi-manual change is painstaking to plan and execute, and almost always suffers of human errors. I got convinced a dfix tool would be a strategic component of D's offering going forward. Andrei What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Interview at Lang.NEXT
On 05/06/2014 08:30, Andrei Alexandrescu wrote: On 6/5/14, 7:59 AM, Nick Sabalausky wrote: So let me get this straight: There are programmers out there who find the occasional type annotations on some declarations to be significantly more work than following a convention of nearly *quadrupling* the amount of code they have to write? Two to three lines of tests for every one line of real code is considered rapid development, saving developer time, just getting things done, etc? And all that's considered a style of coding? You're right, I really don't understand that style of coding at all. ;) Don't get me wrong, I am pretty big on unittests, but even still: If people are trying to save developer time by replacing each minor type annotation with several extra unittests (which are less reliable anyway - greater room for human error), then something's gone horribly wrong. It's usually quite hard to explain such differences in coding stile to people that are used to static typing. That doesn't surprise me. It's also very difficult to explain 2+2==5 to people who are accustomed to basic arithmetic. ;) I have to confess this echoes a few similar confusions I have about the use and advocacy of dynamically-typed languages. One argument I've heard a while back was that static type errors are not proportional response and that static types only detect the most trivial of bugs, so why bother at all. But then the heavy-handed approach to unittesting espoused by dynamic languages, of which arguably a good part would be automated by a static type system, seems to work against that argument. Andrei Dicebot, Nick, Andrei: my thoughts exactly. And I get a lot of that, since my main development language (career-wise) is Java, which dynamic language proponents like to bash for it's verbosity (yes, it's more verbose that it needs to be, but still way better than a dynamic language having to write all those tests!) I sometimes tried to convince dynamic language proponents - the ones that write unittests at least - of the benefits of static typing, by stating that static typing is really just compile time unit-tests! (it is actually) It didn't work, they didn't get it... -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Lang.NEXT panel (dfix)
On 16/06/2014 21:43, Stefan Koch wrote: What's keeping us from having such a tool? It seems that after one has a decent parser (that also keeps tracks of the source ranges of AST nodes), it's easy to write code that does syntactic modifications and then rewrites the source code. And there's several D parsers out there already - so it should be too much effort to get there. Even I am working on a tool that can be easily retrofitted for this purpose. Or maybe I am misunderstanding the amount of semantic analysis that would typically be required? Can someone give some examples of modifications that would be useful for such a dfix tool? (I haven't yet had the time to watch the full panel video, if that's relevant) Well, my recent efforts lead my to belief that I am in over my head with this. But ... many sufficiently simple transformations can be done with a complex regex and for me that is faster, given the trouble I have with writing ASTMatchers for Dscanner. BTW. Does anyone know a good approch to a DSL describeing AST-transformation patterns ? What I currently have is SQL-like Syntax and I feel it won't scale to complex selction and/or transformation patterns. Input is welcome. DSL?! You crazy bro? If you are using DScanner, just let people use D itself to write their own custom AST transformation code. With DUB it should be super easy to compile that code and run it on the target D code. This solution is vastly more simple than inventing your own DSL, and scales way better as a general purpose language will have much more power that selection/transformation patterns. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Dconf 2014 talks - when to be available
On 28/05/2014 14:31, Dicebot wrote: On Wednesday, 28 May 2014 at 12:20:34 UTC, Bruno Medeiros wrote: On 28/05/2014 04:54, Saurabh Das wrote: I actually prefer the slow release of the videos - it gives me enough time to digest each talk and discuss it before the next one grabs mine and everyone else's attention. I think releasing one video every few days leads to much more in-depth discussion on the forum as well. I agree with this. video release != video announcement Huh? I either disagree, or I don't understand your point. A release implies an announcement of some sort somewhere, otherwise it's not really a release... -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Dconf 2014 talks - when to be available
On 28/05/2014 04:54, Saurabh Das wrote: I actually prefer the slow release of the videos - it gives me enough time to digest each talk and discuss it before the next one grabs mine and everyone else's attention. I think releasing one video every few days leads to much more in-depth discussion on the forum as well. I agree with this. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: GDC binaries updated
On 09/05/2014 15:34, Iain Buclaw via Digitalmars-d-announce wrote: On 9 May 2014 12:20, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 07/05/2014 17:42, Johannes Pfau wrote: Am Wed, 07 May 2014 14:38:32 +0100 schrieb Bruno Medeiros bruno.do.medeiros+...@gmail.com: On 04/05/2014 10:38, Johannes Pfau wrote: We've just uploaded new binary releases to http://gdcproject.org/downloads/ ## GDC changes ## As we merged the first parts of Daniel Greens MinGW changes back into GDC we now also provide initial (automated) MinGW builds. These builds are mostly unsupported and will likely have many more bugs than the older releases posted by Daniel so don't expect too much. Glad to hear there is some progress here, but are there plans to make this supported in the future? Also, what is the difference between Daniel Green's build, and the native Standard Builds? Daniels builds apply some more patches, see https://github.com/venix1/MinGW-GDC for details. The builds on gdcproject.org use the standard git sources of gdc which only include the subset of these patches that's necessary to compile run a hello world program. I'm not familiar with the internals of compiler and runtime architecture, but I'm curious, why is is that so many complicated patches are necessary? I understand the D runtime has to access Windows API, correct? But that should all be available in the MinGW target as well, no? Otherwise, what is the difference here when DMD for Windows is compiled, vs when GDC is compiled? DMD x86 on Windows uses the Digital Mars toolchain for linking, etc. DMD x86_64 on Windows uses the MSVC toolchain for linking, etc. GDC on Windows uses the GNU toolchain for linking, etc. Yeah, this much I knew already. Another potentially crucial difference is that DMD compiles directly to object file. GCC requires an assembler installed. This probably does make it easier for DMD to invented custom sections for its own abuse. So it's not so much the D runtime (the 'core', 'rt', 'gc', etc, modules of the D standard library) that is lacking and in need of patches/changes, but rather the DMD frontend and code generator, right? If so, I think I understand. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: How I Came to Write D -- by Walter Bright
On 16/04/2014 09:21, Bienlein wrote: There are a number of job adds for Go developers (see http://golangprojects.com). Go seems to be a good complement for Ruby, Python, PHP which are slow and have bad concurrency. Whoa, that's quite a few jobs already! (Given how relatively new Go is...) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: How I Came to Write D -- by Walter Bright
On 08/04/2014 22:44, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/ We were using C because it was the only high-level language we could find that actually worked on the PC. C + high-level... those where different times indeed! :) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: GDC binaries updated
On 04/05/2014 10:38, Johannes Pfau wrote: We've just uploaded new binary releases to http://gdcproject.org/downloads/ ## GDC changes ## As we merged the first parts of Daniel Greens MinGW changes back into GDC we now also provide initial (automated) MinGW builds. These builds are mostly unsupported and will likely have many more bugs than the older releases posted by Daniel so don't expect too much. Glad to hear there is some progress here, but are there plans to make this supported in the future? Also, what is the difference between Daniel Green's build, and the native Standard Builds? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Interesting rant about Scala's issues
On 03/04/2014 02:55, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg Andrei One interesting point near the end. He glossed over it since he was running out of time, but this was in the slides: What I'm after * I don't need a programming language. * I need a coherent set of tools for creating software. A language is incidental. I totally agree. Sure, the language may be the core, and one of the most important aspects, but the rest of the tool-chain is extremely important too. I don't think everyone in the D community (and outside it too) fully stands behind this idea. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Bountysource activity
On 13/03/2014 18:20, Andrei Alexandrescu wrote: https://www.bountysource.com/issues/1325905-shared-phobos-library-doesn-t-work-on-all-linux-distributions Over $2000 in open bounties left: https://www.bountysource.com/trackers/383571-d-programming-language https://www.bountysource.com/trackers/455080-gdc https://www.bountysource.com/trackers/283332-ldc Andrei I've added a bounty for GDC to produce Windows binary releases! https://www.bountysource.com/issues/1523615-build-script-and-infrastructure-to-produce-and-release-windows-binaries -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.10.0 released - featuring DUB support.
On 18/03/2014 22:27, Jay Norwood wrote: On Friday, 14 March 2014 at 15:44:24 UTC, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. This has really nice source browsing... much better than the VisualD. I end up using both because the debugging support is still better in VisualD. Yeah, I wish more GDB/DWARF support existed in Windows, so that debugging support was better. GDB support would probably be very hard to achieve for D programs that need to compile/link against Windows API or the MSVC toolchain, but for programs that don't need that, debugging support could be nearly as good as Linux/MacOS... :/ One browsing issue I noticed though is that it has a problem finding source for properties, for example if you try to find the isDir definition from lin 2216 of file.d. Yes, there are lots of simple semantic engine improvements that could be made. I haven't yet had time to go back to work on the semantic engine, as I've been tied up in other features (DUB support for example) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.10.0 released - featuring DUB support.
On 24/03/2014 15:13, Casper Færgemand shortt...@hotmail.com wrote: Is the install guide on github up to date? Yes, all documentation should be up to date, including the installation guide. -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.10.0 released - featuring DUB support.
A new version of DDT - D Development tools is out. https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.0 The major new feature is DUB support (there are breaking changes, please read the changelog and updated User Guide sections for more info). A lot of the UI has been cleaned up as well, removing inoperative functionality, changing the references to DLTK concepts (such as interpreters or script), etc. PS: Thanks to Sönke for bringing DUB into an existence, this tool is awesome! (this could even be an understatement... a package management and build tool is crucial for D's success!) -- Bruno Medeiros https://twitter.com/brunodomedeiros
DDT 0.10.0 release - featuring DUB support.
A new version of DDT - D Development tools is out: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.10.0 The major new feature is DUB support (there are breaking changes, please read the changelog and updated User Guide sections for more info). A lot of the UI has been cleaned up as well, removing inoperative functionality, changing the references to DLTK concepts (such as interpreters or script), etc. PS: Thanks to Sönke for bringing DUB into an existence, this tool is awesome! (this could even be an understatement... a package management and build tool is crucial for D's success!) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DigitalMars' GSoC application has been rejected
On 27/02/2014 22:25, Brad Roberts wrote: Also, keep in mind that GSoC is pretty much two things: 1) a nice little pay check for students 2) a bit of structure around getting work done I would say it's one more thing too: Being able to say you participated in GSoC (for your resume/credentials, or just bragging rights). For a student and future graduate, I would say that is valuable, for some students perhaps even more than the monetary rewards. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.9.0 released - GDB debugging integration
On 11/02/2014 14:53, Vladimir Krivopalov wrote:
Hi Bruno,
First off, I wanted to share my appreciation for working on D support in
Eclipse and especially for introducing the debugging capabilities with
DDT - really awesome!
I started playing around with the CDT debugger for D programs and so far
got a question about D dynamic arrays.
Actually they're already supported by GDB out of box, and indeed
debugging with GDB 7.6.2 allows for the following array's output:
code line int[] a = [7, 5];
(gdb) print a
$1 = {7, 5}
but still, if debugging the same code in Eclipse (CDT), I see:
astruct _Array_int{...}
lengthunsigned long2
ptrint *0x77ecdfd0
While it is definitely possible to implement some custom pretty printers
for this (and it shouldn't be that hard), I wanted to first ask whether
you have some clue about how can the D-style array output be forced in
CDT. Thanks!
Please follow this bug: https://github.com/bruno-medeiros/DDT/issues/43
BTW, was that sample run in Linux? Using DMD?
Re: dmd 2.064.2
On 05/11/2013 22:08, Walter Bright wrote: Ok, this is it: http://ftp.digitalmars.com/dmd_2.064.2-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064.2-0_i386.deb http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064.2-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064.2.exe http://ftp.digitalmars.com/dmd.2.064.2.zip http://ftp.digitalmars.com/dmd.2.064.2.dmg http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_amd64.deb http://ftp.digitalmars.com/libphobos2-64_2.064.2-0_i386.deb Regarding the new eponymous template syntax, has this change been updated in the language spec? Seems not. Does this syntax support template constraints? According to the compiler, seems not, but this should be in the spec.
Re: New debugger for D!!!
On 28/01/2014 03:00, Sarath Kodali wrote: On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote: Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-) Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath Ok, going on the contrarian view here, but if those are your supported OSes/compiler, isn't that need fairly adequately filled by GDB at the moment? Why start work on a whole new compiler? Particularly, the Windows debugging scene for D is much more lacking than Linux, so I'm failing to see why all the enthusiasm around here...
Re: New debugger for D!!!
On 28/01/2014 03:00, Sarath Kodali wrote: On Monday, 27 January 2014 at 18:10:03 UTC, Alexander Bothe wrote: Which OSs are supported? Which compilers are supported, which debug info base is used? Is the info directly extracted from the executable aka Dwarf/CV4/PDB support? The sample debug session looks cool, so I'd really like to know this to estimate whether it's worth to integrate it into Mono-D or other IDEs :-) Next month I will be releasing an alpha version with support for Linux, x86, Elf+Dwarf, DMD and GCC. But in the coming months I will add support for other 64 bit OSes and compilers. I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! Thanks for the interest, Sarath Ok, going on the contrarian view here, but if those are your supported OSes/compiler, isn't that need fairly adequately filled by GDB at the moment? Why start work on a whole new debugger? Particularly since the Windows debugging scene for D is much more lacking than Linux, so I'm failing to see why all the enthusiasm around here...
Re: DUB 0.9.20
On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
On 06/12/2013 13:58, Sönke Ludwig wrote: Am 06.12.2013 13:57, schrieb Bruno Medeiros: On 03/12/2013 13:44, Sönke Ludwig wrote: Am 03.12.2013 13:47, schrieb Bruno Medeiros: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub upgrade should be the right call. Possibly with --root=path/to/package or dub upgrade pkgname:subpkgname --root=path/to/package. It's not clear from the name, but yeah, does the trick! The only use case that usually makes sense for it is to upgrade packages. All other commands should implicitly fetch the required packages, including dub describe, so no explicit dependency fetching is necessary. 'dub describe' is doing no such thing for me. Is that a bug? -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? -- Bruno Medeiros - Software Engineer
Re: DUB 0.9.20
On 03/12/2013 13:00, Mike Parker wrote: On 12/3/2013 9:47 PM, Bruno Medeiros wrote: On 29/11/2013 17:01, Sönke Ludwig wrote: A fresh DUB release is out. Apart from the usual bug fixes, there are a few considerable changes: Quick question: is there a way to install/fetch the dependencies of a package, without having to build? That is, without using dub build ? dub install packageName That only works if packageName is a package in the DUB registry. It won't work for a locally created package. -- Bruno Medeiros - Software Engineer
Re: DDT 0.9.0 released - GDB debugging integration
On 02/12/2013 10:35, eles wrote: On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: Quick question: with the current version is it possible to use it with a dub project at all (maybe via a manual project setup)? I was trying to manually set it up, pointing sources as the source folder and trying to get the ~/.dub/packages into the list of libraries, but it did not seem to like it... Yes, manual setup is possible, but you must use absolute path without `~`. Exactly, although you can use some Eclipse resource variables in the path of linked folders. why this? https://github.com/bruno-medeiros/DDT/commit/b7a57f9e0d7915734ba6b175acfc1fd53a7a92f4 The commit it reverted was not meant to go to master, but to a branch. The idea is that master is to be kept potentially shipable at all times, and dub support is not ready (nor was it disabled in the original commit, which is another way that it could be allowed to be commited to master). -- Bruno Medeiros - Software Engineer
Re: DDT 0.9.0 released - GDB debugging integration
On 15/11/2013 08:56, Alexandr Druzhinin wrote: 15.11.2013 00:54, Bruno Medeiros пишет: DDT 0.9.0 (Debugging is Magic) is out, see post: https://groups.google.com/d/msg/ddt-ide/VwA7ifYt9c0/wBcvUSVKNqMJ I installed 4.2 version but get error again: Cannot complete the install because of a conflicting dependency. Software being installed: DDT - D Development Tools 0.9.0.v201311141659 (org.dsource.ddt.feature.group 0.9.0.v201311141659) Software currently installed: Eclipse Platform 4.2.0.I20120608-1400 (org.eclipse.platform.ide 4.2.0.I20120608-1400) Only one of the following can be installed at once: Eclipse Workbench 3.105.0.v20130529-1406 (org.eclipse.ui.workbench 3.105.0.v20130529-1406) Eclipse Workbench 3.103.0.v20120530-1824 (org.eclipse.ui.workbench 3.103.0.v20120530-1824) Eclipse Workbench 3.103.1.v20120906-120042 (org.eclipse.ui.workbench 3.103.1.v20120906-120042) Eclipse Workbench 3.105.1.v20130821-1411 (org.eclipse.ui.workbench 3.105.1.v20130821-1411) Eclipse Workbench 3.104.0.v20130204-164612 (org.eclipse.ui.workbench 3.104.0.v20130204-164612) Cannot satisfy dependency: From: DDT - D Development Tools 0.9.0.v201311141659 (org.dsource.ddt.feature.group 0.9.0.v201311141659) To: org.dsource.ddt.ide.debug [0.1.0.v201311141659] Cannot satisfy dependency: From: DDT Debug support (DSF) 0.1.0.v201311141659 (org.dsource.ddt.ide.debug 0.1.0.v201311141659) To: bundle org.eclipse.ui 3.105.0 Version is the last, what should I do more? My bad. The effective minimum Eclipse Platform version is 4.3.0, not 4.2.0 (I've updated the DDT Installation wiki). Also, it seems as things stand Eclipse cannot update the Platform and install DDT *at the same time*, even within the same Platform major version number. So just do it in two steps, first update Eclipse (Check for updates), then update/install DDT. -- Bruno Medeiros - Software Engineer
Re: DDT 0.9.0 released - GDB debugging integration
On 15/11/2013 13:29, Ary Borenszweig wrote: On 11/14/13 2:54 PM, Bruno Medeiros wrote: DDT 0.9.0 (Debugging is Magic) is out, see post: https://groups.google.com/d/msg/ddt-ide/VwA7ifYt9c0/wBcvUSVKNqMJ Awesome. I like your solution for the debugger (instead of writing something from scratch). Congratulations! Yeah, looks great, although it's not that I've done much myself, in part it was mostly being lucky to have this kind of support available and being able to integrate it this way. At first I thought I might had to copy CDT's debug source code (like Descent did with JDT) and adapt it to DDT but fortunately it was not necessary. -- Bruno Medeiros - Software Engineer
Re: Visual D 0.3.37 released
On 06/11/2013 14:39, Manu wrote: For instance, it seems a shame to have .visualdproj, and .dproj files separate and incompatible. .csproj files are the same between VS and MD, I wonder if the same is possible for D with collaboration? The best approach here is to support an IDE-independent project configuration standard. And Dub is a good choice to go with this approach. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 22/10/2013 14:48, Iain Buclaw wrote: If you are using GCC, you'll be using the GCC toolchain. If you are using MSVC, you'll be using the MSVC toolchain. It's as black and white as that. I know. The point, for me at least, was not weather I could use GCC + MS debuggers or MS compilers + GDB. It was: if you use DMD (64 bit ATM) what debuggers can you use? Can you sucessfully use GDB? If not, could DMD be modified to supported whatever format GDB uses? Also, it's not likely DWARF debug information that it emits, as the COFF object format defines its own intrinsic symbolic debug format. GDB can't read CV8/PDB. I think it's DWARF debug information, even for COFF and PE file format. If I run info source on a GDC compiled program, I get: -- (gdb) info source Current source file is ../../../gcc-4.6.1/libphobos/rt/dmain.d Compilation directory is C:\crossdev\gdc\v2\build\i686-pc-mingw32\libphobos Source language is d. Compiled with DWARF 2 debugging format. Does not include preprocessor macro info. -- I suspect that what is happening is that by default GCC toolchain stores debug information in the COFF (and PE) file format in a non-standard way - it doesn't use the COFF debug standard but uses DWARF data format instead (DWARF is independent of object file formats). And that's why MS tools don't understand that symbolic info, I guess. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 22/10/2013 16:59, Manu wrote: ...okay. Ignore me! You said GCC _is able_ to emit COFF object code, which didn't make it sound like it did, or at least not by default. Which seemed to match my experience (from years ago). I recall a conversation with Daniel Green about making a special COFF-outputting toolchain for me. So what debuginfo is in there then? MS link.exe seemed to ignore it. So, you are saying that GDC does output COFF by default? And is debuggable by gdb? I'm thoroughly confused now, this seems to contradict past experiences. Apparently I've been smoking a lot of crack... See my OP. It seems by default GDC outputs COFF object file format, but with DWARF debug info. But whatever format it is, GDB understands it quite well, that is for sure. GDC+GDB was the main configuration I tested when I was updating the Debuggers wiki page and see what kind of support there was. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 18/10/2013 12:58, Iain Buclaw wrote: On 18 October 2013 12:43, Bruno Medeiros brunodomedeiros+...@gmail.com wrote: On 16/10/2013 22:21, Andrei Alexandrescu wrote: On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei If that was under Windows, it must have been GDC then. The debug format that DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not understood by GDB, which I guess only understands DWARF. GCC is able to emit COFF object code - and GDB can read COFF debug code - though admitedly COFF is a woeful excuse of an object/debug file format. :o) Regards Thanks for the clarification, I didn't know GDB could read COFF as well. My main dev machine is 32 bit (old yeah) so I haven't had yet the chance to try DMD-64 on Windows. Will probably try it at some point on my desktop. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 16/10/2013 13:42, Dicebot wrote: On Wednesday, 16 October 2013 at 12:38:40 UTC, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ Well I do debug `dmd -gc` programs with gdb relatively frequently. What exactly is of interest? We are talking about DMD+GDB on Windows. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 16/10/2013 22:21, Andrei Alexandrescu wrote: On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei If that was under Windows, it must have been GDC then. The debug format that DMD emits on Windows (OMF for x32 and COFF for x64, if I'm correct) is not understood by GDB, which I guess only understands DWARF. -- Bruno Medeiros - Software Engineer
Re: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ -- Bruno Medeiros - Software Engineer
