Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I finally watched it (I failed to survive the long over-nighters until 10am to watch this one live _). I want to offer congratulation and thanks to Iain for this work! For me, this is perhaps the single most important work in the D ecosystem yet this year, and for me, I think the debugging environment remains the single most significant hurdle to confident and practical adoption of D in industry. Thanks Manu. I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;) I think you've probably earned a break ;) It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?). Link: http://zerobugs.codeplex.com Couple of clones on github too: https://github.com/search?q=zerobugs Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it. Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!) On the back of your work, what advantage would that debugger have over established and more refined tools? What would a 'D debugger' have to offer when the debug backend understands D internally, and can even handle D expression evaluation? There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately...
Re: Coloring terminal output.
On Sunday, 13 July 2014 at 20:11:19 UTC, yamadapc wrote: Hello all :) I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Links: http://code.dlang.org/packages/colorize https://github.com/yamadapc/d-colorize https://github.com/fazibear/colorize It looks good. This stuff is always a pain to handle so i appreciate you wrapping this up into a library. :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I finally watched it (I failed to survive the long over-nighters until 10am to watch this one live _). I want to offer congratulation and thanks to Iain for this work! For me, this is perhaps the single most important work in the D ecosystem yet this year, and for me, I think the debugging environment remains the single most significant hurdle to confident and practical adoption of D in industry. Thanks Manu. I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;) I think you've probably earned a break ;) It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?). Link: http://zerobugs.codeplex.com Couple of clones on github too: https://github.com/search?q=zerobugs Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it. Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!) On the back of your work, what advantage would that debugger have over established and more refined tools? I've never used zerobugs, but it looked interesting a few years back, but didn't think it worth the money (actually, I seldom purchase software) in comparison to FOSS. What would a 'D debugger' have to offer when the debug backend understands D internally, and can even handle D expression evaluation? I think the experience is simply more natural to the end user. You code in D, you debug in D. I do it all the time for C++ when I'm probing for a problem in gdc. Copying a line of code and pasting it into the command prompt, checking the result. It's one of these features that I never noticed until I started doing this work in gdb. *Then* I realised that I would have to implement a ground-up interpreter for D. Luckily GDB has awesome support for many language concepts, both in functional and procedural languages. So most of the work was just extending existing opcodes to behave in a D-like manor. ;-) Iain.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
druntime: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ target phobos: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib That works? So it probably doesn't need the includes set in the makefile.
Re: DMD v2.066.0-b3
LINUX ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v (v-storage_class (STCmanifest | STCstatic)) == 0 v-init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v !(v-storage_class STCmanifest) !v-isDataseg() v-init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense.
Re: DMD v2.066.0-b3
On Monday, 14 July 2014 at 11:57:33 UTC, Dragos Carp wrote: LINUX ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v (v-storage_class (STCmanifest | STCstatic)) == 0 v-init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v !(v-storage_class STCmanifest) !v-isDataseg() v-init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense. http://forum.dlang.org/post/yavpusxgxwgbaepct...@forum.dlang.org
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I finally watched it (I failed to survive the long over-nighters until 10am to watch this one live _). I want to offer congratulation and thanks to Iain for this work! For me, this is perhaps the single most important work in the D ecosystem yet this year, and for me, I think the debugging environment remains the single most significant hurdle to confident and practical adoption of D in industry. Thanks Manu. I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;) I think you've probably earned a break ;) It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?). Link: http://zerobugs.codeplex.com Couple of clones on github too: https://github.com/search?q=zerobugs Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it. Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!) On the back of your work, what advantage would that debugger have over established and more refined tools? I've never used zerobugs, but it looked interesting a few years back, but didn't think it worth the money (actually, I seldom purchase software) in comparison to FOSS. What would a 'D debugger' have to offer when the debug backend understands D internally, and can even handle D expression evaluation? I think the experience is simply more natural to the end user. You code in D, you debug in D. I do it all the time for C++ when I'm probing for a problem in gdc. Copying a line of code and pasting it into the command prompt, checking the result. It's one of these features that I never noticed until I started doing this work in gdb. *Then* I realised that I would have to implement a ground-up interpreter for D. Okay, so I'm confused. You said you're working on an expression parser for D right? Assuming that is present, why would a D-specific debugger have any advantage over an existing debugger with your GDC? Or is the point that zerobugs already rolls its own debugger which has an expression parser? Luckily GDB has awesome support for many language concepts, both in functional and procedural languages. So most of the work was just extending existing opcodes to behave in a D-like manor. ;-) Right. Do you know about LLDB? I presume it'll be equally competent? I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility. With that, you should be able to (finally!) use Clang(/LDC) in place of MSVC, so then we're left with the debug environment... If LLVM are making a commitment to producing Microsoft object and debug output, it stands to reason that LLDB will support them too?
Re: DMD v2.066.0-b3
I've been running beta2, and I noticed that class debugging isn't working. There was a discussion some time back about how class members weren't evaluated correctly in Win64, and it was said that it was fixed in master. I was excited and patiently awaiting the release. Can anyone who knows about this stuff comment? On 14 July 2014 22:00, Dicebot via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Monday, 14 July 2014 at 11:57:33 UTC, Dragos Carp wrote: LINUX ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip I think something got wrong on building the 2.066.0-b3. The sources from dmd.2.066.0-b3.linux.zip are not the same with the tagged version 2.066.0-b3 in git (for dmd at least). For example: unzipped dmd2.066-b3/src/dmd/nogc.c:65 if (v (v-storage_class (STCmanifest | STCstatic)) == 0 v-init) git v2.066.0-b3 dmd/src/nogc.c:65 if (v !(v-storage_class STCmanifest) !v-isDataseg() v-init) Maybe you should rebuild this or simply ignore -b3 and create a -b4. Because of improper tagging, testing actual binaries of -b3 makes no sense. http://forum.dlang.org/post/yavpusxgxwgbaepct...@forum.dlang.org
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14 July 2014 15:15, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 21:14, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 07:22, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 15:58, Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14 July 2014 06:19, Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I finally watched it (I failed to survive the long over-nighters until 10am to watch this one live _). I want to offer congratulation and thanks to Iain for this work! For me, this is perhaps the single most important work in the D ecosystem yet this year, and for me, I think the debugging environment remains the single most significant hurdle to confident and practical adoption of D in industry. Thanks Manu. I guess I'll be having trouble finding the next most important work in the D ecosystem next year. ;) I think you've probably earned a break ;) It brings me to the interesting realisation (which I already knew, I have just been denying), that for D to proceed on Windows, MSVC will have to go... and I don't know how to go about this :/ MS's debugger will presumably never support these features, but the de facto Windows toolchain emit's PDB for use with the MS tools. I wonder if there are competing debuggers that support PDB which could support unofficial extensions to PDB which may express D better? Zerobugs was aimed at D users back when it was a commercial product. It has since been released under a boost licensed for a couple years now, but has into gone into obscurity (I think?). Link: http://zerobugs.codeplex.com Couple of clones on github too: https://github.com/search?q=zerobugs Being written against GTK, it's UI should be cross-platform to Windows, so it *could* be a good base project to start from, then build Windows debugging support into it. Someone else will need to do initial reviewing and triaging of this stuff (we need a new Lieutenant!) On the back of your work, what advantage would that debugger have over established and more refined tools? I've never used zerobugs, but it looked interesting a few years back, but didn't think it worth the money (actually, I seldom purchase software) in comparison to FOSS. What would a 'D debugger' have to offer when the debug backend understands D internally, and can even handle D expression evaluation? I think the experience is simply more natural to the end user. You code in D, you debug in D. I do it all the time for C++ when I'm probing for a problem in gdc. Copying a line of code and pasting it into the command prompt, checking the result. It's one of these features that I never noticed until I started doing this work in gdb. *Then* I realised that I would have to implement a ground-up interpreter for D. Okay, so I'm confused. You said you're working on an expression parser for D right? Assuming that is present, why would a D-specific debugger have any advantage over an existing debugger with your GDC? Or is the point that zerobugs already rolls its own debugger which has an expression parser? Luckily GDB has awesome support for many language concepts, both in functional and procedural languages. So most of the work was just extending existing opcodes to behave in a D-like manor. ;-) Zerobugs rolls its own debugger, its only strength vs GDB is that being separate from the GNU toolchain, it may be more friendly to getting in PDB/MSVC support, for instance. Right. Do you know about LLDB? I presume it'll be equally competent? I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility. With that, you should be able to (finally!) use Clang(/LDC) in place of MSVC, so then we're left with the debug environment... If LLVM are making a commitment to producing Microsoft object and debug output, it stands to reason that LLDB will support them too? I haven't looked at LLDB I'm afraid, so I can't comment.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
Am Tue, 15 Jul 2014 00:15:01 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility. Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem. The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these. So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM. There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute...
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Nope doesn't. Setting VCDIR and SDKDIR via the make command works.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
On 14.07.2014 16:55, Trass3r wrote: Nope doesn't. Setting VCDIR and SDKDIR via the make command works. Works for me. Maybe you need a newer version of make (there was a silent update in 2012, my version is 5.06). This kind of escaping also depends a lot on the used shell, I'm just using cmd.exe.
DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/ https://www.facebook.com/dlang.org/posts/884725944874421 https://twitter.com/D_Programming/status/488748669869780992 Andrei
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
On Monday, 14 July 2014 at 18:17:25 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/ https://www.facebook.com/dlang.org/posts/884725944874421 https://twitter.com/D_Programming/status/488748669869780992 Andrei http://youtu.be/o5m0m_ZG9e8
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Setting VCDIR and SDKDIR via the make command works. Works for me. Maybe you need a newer version of make (there was a silent update in 2012, my version is 5.06). Well if you don't set VCDIR you won't get proper include paths. So no clue why it works for you.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? As long as they rely on the MS linker they only need to emit proper debug info into the object files. But that's still TODO: http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
This is my favorite DConf 2014 talk. I absolutely admire dedication Mike has pushed through many annoying issues through to the point he has prevailed :) Best proof of concept for D usage in embedded barebone world I have seen so far.
Re: DConf 2014 Day 2 Talk 7: Tiny, Ubiquitous Machines Powered by D by Michael D. Franklin
On 7/14/2014 12:32 PM, Dicebot wrote: This is my favorite DConf 2014 talk. I absolutely admire dedication Mike has pushed through many annoying issues through to the point he has prevailed :) Best proof of concept for D usage in embedded barebone world I have seen so far. Post this on reddit!
Re: Coloring terminal output.
I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Cool! Would it be hard to add windows support?
Re: Coloring terminal output.
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote:
Cool! Would it be hard to add windows support?
I don't think it can be done with this setup - the colorize thing
returns a string, but Windows does color via API calls
independently of the string.
My terminal.d offers color output through special function calls:
https://github.com/adamdruppe/arsd/blob/master/terminal.d
works on both platforms.
import terminal;
void main() {
// get the terminal object for linear output
auto terminal = Terminal(ConsoleOutputType.linear);
// set foreground and background colors
terminal.color(Color.green | Bright, Color.black);
// to use default btw:
// terminal.color(Color.DEFAULT, Color.DEFAULT);
// write with this instead of regular stdout
terminal.write(hello\n);
}
Re: Coloring terminal output.
On Mon, Jul 14, 2014 at 20:09:04 +, Adam D. Ruppe via Digitalmars-d-announce wrote: My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d Scanning this, I see missing termcap for screen and screen-256color which are fairly common. Also rxvt-unicode-256color (if it supports 256 colors which a quick scan didn't seem to indicate). --Ben
Re: DMD v2.066.0-b3
On 14.07.2014 16:17, Manu via Digitalmars-d-announce wrote: I've been running beta2, and I noticed that class debugging isn't working. There was a discussion some time back about how class members weren't evaluated correctly in Win64, and it was said that it was fixed in master. I was excited and patiently awaiting the release. Can anyone who knows about this stuff comment? You have to use -gc instead of -g to enable the '.' to '@' translation inside class names.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
On 14.07.2014 21:05, Trass3r wrote: Setting VCDIR and SDKDIR via the make command works. Works for me. Maybe you need a newer version of make (there was a silent update in 2012, my version is 5.06). Well if you don't set VCDIR you won't get proper include paths. So no clue why it works for you. Ok, I'm not starting the bare cmd.exe, but the one from VS that calls vcvars32.bat. That way the INCLUDE environment variable contains the correct paths. I agree, the VCDIR/SDKDIR settings in the makefile are not very helpful, but can also be ignored that way.
Re: DUB Bash Completion
On Monday, 14 July 2014 at 00:10:38 UTC, Mathias LANG wrote: complete --config= too, so you could tab complete Yeah, that would be nice. Need to add som json parsing to the bash logic. Any suggestions on how to most easily and portably do that?
Re: Coloring terminal output.
On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote: On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote: Cool! Would it be hard to add windows support? I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution.
Re: Coloring terminal output.
On Tuesday, 15 July 2014 at 00:21:09 UTC, Alexandre L. wrote: On Monday, 14 July 2014 at 22:51:17 UTC, yamadapc wrote: On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote: On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote: Cool! Would it be hard to add windows support? I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution. If you wish, I have some small examples on my github. github.com/mrtryhard/dlang Directory 'console'. It provides minimalistic console support for Windows only. However I was pissed that some headers / functions weren't available so I kind of lacked the updates on it. Sorry, I meant example for Windows support*.
Re: Coloring terminal output.
On Monday, 14 July 2014 at 22:51:17 UTC, yamadapc wrote: On Monday, 14 July 2014 at 20:09:05 UTC, Adam D. Ruppe wrote: On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote: Cool! Would it be hard to add windows support? I don't think it can be done with this setup - the colorize thing returns a string, but Windows does color via API calls independently of the string. My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d Suliman: As Adam mentioned, to add windows support we'd have to use a different set-up. I'm thinking on a clean solution to this, but a special printing function will have to be called. I'm actually discussing this at https://github.com/yamadapc/d-colorize/issues/2 Adam: Cool; that seems like a nice solution. If you wish, I have some small examples on my github. github.com/mrtryhard/dlang Directory 'console'. It provides minimalistic console support for Windows only. However I was pissed that some headers / functions weren't available so I kind of lacked the updates on it.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 00:32, Johannes Pfau via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Am Tue, 15 Jul 2014 00:15:01 +1000 schrieb Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: I don't see that GDC/GDB will ever be useful in the Windows environment due to incompatible object and debug formats, but LLVM are making the push for full MSVC compatibility. Can you provide some more details about this? MinGW uses the standard PE object format, afaik. GCC-4.9 also supports SEH exceptions (on 64 bit, not sure about 32). The mingw 'runtime' is a small layer on top of the microsoft runtime, to provide C99 functions and similar stuff. I don't think that should be a problem. http://clang.llvm.org/docs/MSVCCompatibility.html They emit line numbers so far apparently. But I understand the intent is to properly populate the object with cv8 debug data. The linker takes care of generating the pdb file. So, are you saying that GDC binaries will link successfully against the mscrt suite? I've used it in the past, and it never wanted to link against the ms libs. In addition, when I did try and link C and D code together, I got loads of CRT conflicts when trying to link glibc and mscrt together. I believe the goal for LLVM is to target the same runtime as MSC does, otherwise you're just asking for link trouble. The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? The linker outputs the pdb file, the objects are populated with cv8. Can GCC write cv8 output? I'm sure it's possible to creatively coax the cv8 data blocks to store non-MS data without being stripped or crashing the linker... That said, I don't know anything about cv8/pdb, and if it's able to sufficiently express D concepts as is. MS supports quite a few languages, so it must be reasonably competent as it is...? MinGW can use dwarf debug info on windows and I guess you get all benefits of Iain's gdb work on windows. It is annoying if you get crashes in the microsoft C runtime or any other library compiled with microsoft tools though, as there's no dwarf debug info for these. 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 :/ So overall I don't see why mingw should work fine on windows. Of course there's less incentive for GCC devs to support windows, but I doubt that's different for LLVM. I think there would be plenty of incentive if it worked. I haven't tried it out for a while. I'll give it a whirl and see what's changed, but while the dwarf/cv8 conflict remains, I can't see it being a practical solution. There's also nobody working actively on the MinGW gdc port right now, afaik. We don't even know the test suite results for mingw. So if you want to contribute... This has indeed been my biggest issue with GDC in the past.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Mago had D expression evaluation from the start, showing associative array elements was added a bit later. Have you tried it out? How does it deal with some of the cases Iain brought up; enum's, globals/statics, tls, etc.
Re: DMD v2.066.0-b3
On 15 July 2014 07:37, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 16:17, Manu via Digitalmars-d-announce wrote: I've been running beta2, and I noticed that class debugging isn't working. There was a discussion some time back about how class members weren't evaluated correctly in Win64, and it was said that it was fixed in master. I was excited and patiently awaiting the release. Can anyone who knows about this stuff comment? You have to use -gc instead of -g to enable the '.' to '@' translation inside class names. Shouldn't that be the default then? It's no good not being able to view class members... Are you sure that's the problem? If I inspect a class, it shows a grid populated with the proper number of members, but the member names are blank and the values are blank too. Occasionally, if there are many members, the first 10 or so are blank, but then the rest display properly from there down. It's very strange... you haven't experienced this? If the problem is as you say, I'm surprised that it would occasionally work past the first 10 members or so...
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 15 July 2014 04:27, Rainer Schuetze via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 14.07.2014 08:22, Manu via Digitalmars-d-announce wrote: There are alternative tools available for windows too, but I think the key for Windows developers remains proper integration into Visual Studio, and PDB support. I guess the biggest hurdle there is integrating D concepts info into MS's proprietary PDB format. Expressing debug info like C really won't get us the full mile. Rainer bundles Mago with VisualD. I wonder what that's doing lately... Aldo has put a lot of work in extending mago to 64-bit. I guess the next version of Visual D will come with it. Does that mean it's working? It's very hard to tell from the project website. TBH, I actually thought Mago was a dead project for years because the last activity on the website looks like 2012. He should consider moving to github, then we can have some visibility. Mago had D expression evaluation from the start, showing associative array elements was added a bit later.
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Tue, 08 Jul 2014 09:03:37 -0700, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: https://news.ycombinator.com/newest (please find and vote quickly) https://twitter.com/D_Programming/status/486540487080554496 https://www.facebook.com/dlang.org/posts/881134858566863 http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Andrei So instead of replying to each messages and accumulating a LOT of quoted text I will attempt to answer some of your questions here. The first is that I would like to challenge the assumption that Scene Graphs are somehow Less Performant. In fact the they are a very highly performant solution to many problems, yes there are a few drawbacks but they are far outweighed by the performance gains. Remember that when you are designing a system you must consider the system as a whole, it's WAY to easy to get caught up in individual concerns. Most AAA game engines use some form of scene graph. The one I am familiar with is CryENGINE 3. Now those scene graphs are more specialized, but there is absolutely no reason that a scene graph has to be slow. In fact D's immutability may give the compiler (and us) the ability to build the most performant scene graph in the world. Scene graphs make relative transforms easy for example, and since that is really all you're doing in 3D, making that easy for the computer is a massive win. As for similarity in graphics subsystem API's they are, at best, superficial. When you actually try to implement something on top of them, you end up forcing the abstraction far higher than you'd think. Plus the high-level API design was something that Walter, Andrei, and I all agreed on at the start. I want to reiterate that Aurora is NOT a high-performance game engine and we won't even pretend to try. The focus on 2D is not about how difficult 2D versus 3D is, but about project scope. We want to build Aurora in components that are useful on their own. Based on previous message traffic in the forum I think that more people will find use for the 2D components than the 3D components. Writing a DSL for shaders is one of those things that sounds good until you actually try it. There is a LOT of complexity, both at the language level and the number of output variations, within shaders that would have to addressed. While D is appealing to game designers, Aurora is very explicitly NOT targeting them. They will either create their own engines or using a COTS system that's already available. Walter made this point extremely clear to me when he asked me to take this project on. Yes, performance is not a goal, because we are intentionally not targeting scenarios where that is the first concern. I understand that a lot of people want Aurora to be a high-performance graphics API with a focus on games, but that isn't our goal. Simplicity is the goal and we will sacrifice performance where it directly conflicts with that goal. If you need a high-performance game engine, I would strongly recommend either creating a custom solution or using an off-the-self system. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
