digitalmars.D.announce - DMD 0.155 release
- Walter Bright <newshound digitalmars.com> Apr 28 2006
- Lionello Lunesu <lio lunesu.remove.com> Apr 28 2006
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Apr 28 2006
- Hasan Aljudy <hasan.aljudy gmail.com> Apr 28 2006
- Wang Zhen <nehzgnaw gmail.com> Apr 28 2006
- Lionello Lunesu <lio lunesu.remove.com> Apr 28 2006
- Tydr Schnubbis <fake address.dude> Apr 29 2006
- Walter Bright <newshound digitalmars.com> Apr 29 2006
- Tydr Schnubbis <fake address.dude> Apr 30 2006
- Walter Bright <newshound digitalmars.com> Apr 30 2006
- Don Clugston <dac nospam.com.au> May 02 2006
- Walter Bright <newshound digitalmars.com> May 02 2006
- "ElfQT" <dethjunk yahoo.com> May 05 2006
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> May 05 2006
- pragma <pragma_member pathlink.com> May 05 2006
- Ingle Thomas <Ingle_member pathlink.com> May 06 2006
- Don Clugston <dac nospam.com.au> May 07 2006
- "news.digitalmars.com" <dethjunk yahoo.com> May 05 2006
- "ElfQT" <dethjunk yahoo.com> May 05 2006
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> May 05 2006
- Tydr Schnubbis <fake address.dude> May 05 2006
- Sean Kelly <sean f4.ca> Apr 28 2006
- Juan Jose Comellas <jcomellas gmail.com> Apr 28 2006
- Kyle Furlong <kylefurlong gmail.com> Apr 28 2006
http://www.digitalmars.com/d/changelog.html
Apr 28 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Walter, thank you!! L.
Apr 28 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
(or http://www.digitalmars.com/d/changelog.html#new0155, to avoid all that scrolling when one reads this later...)# Removed std.recls, instead use http://synesis.com.au/software/recls/.
This will also avoid the C++ requirement for building Phobos, while still allowing you to get a new version of recls later. It also works around the "documentation issue" of std.recls. Now all we need is an upgrade for zlib: 1.2.1 -> 1.2.3 http://www.zlib.net/zlib123.zip I believe the current version has some security problems... http://www.kb.cert.org/vuls/id/238678 http://www.kb.cert.org/vuls/id/680620 Or has these been patched in the DMD version of zlib 1.2.1 ? But it looks like a solid update, let's see if we can upgrade GDC with all of them since it's at DMD 140 now. --anders
Apr 28 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
The attached windbg debugger is a little bit wierd. Font is too small ... hard to see things. When you open a "program", all the other "source" windows disappear. Does't seem to see local variables very well?
Apr 28 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Thank you, Walter. I hope you redistribute windbg in a separate package next time.
Apr 28 2006
Wang Zhen wrote:Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Thank you, Walter. I hope you redistribute windbg in a separate package next time.
It's the debugger everybody's been waiting for!(From 1996 nonetheless) L.
Apr 28 2006
Wang Zhen wrote:Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Thank you, Walter. I hope you redistribute windbg in a separate package next time.
The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it. I didn't change any of it's settings, so it doesn't seem to work out of the box for me. Anyone else experienced this? But windbg 6 (which I got from Microsoft's site) works fine most of the time. What exactly am I missing out on by not using the old version? I've only used it for debugging access violations so far, which seems to work. And it opens the source code file and shows in which function the violation occurred. Seems that line numbers might be missing, since it only show which function call (call stack), not the exact line in that function. It would be really nice to have some recommandations for how to use windbg, pros and cons for each version etc. Other than the windbg 6 tutorial link ( http://mtaulty.com/blog/(e4b1ut55q0wf0545z043zsm5)/archive/2004/08/03/608.aspx ). Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
Apr 29 2006
Tydr Schnubbis wrote:The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it. I didn't change any of it's settings, so it doesn't seem to work out of the box for me. Anyone else experienced this?
No. I use windbg all the time, and I have a old (slow) machine.But windbg 6 (which I got from Microsoft's site) works fine most of the time. What exactly am I missing out on by not using the old version?
Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
There's a patch to do that you can install.
Apr 29 2006
Walter Bright wrote:Tydr Schnubbis wrote:The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it. I didn't change any of it's settings, so it doesn't seem to work out of the box for me. Anyone else experienced this?
No. I use windbg all the time, and I have a old (slow) machine.But windbg 6 (which I got from Microsoft's site) works fine most of the time. What exactly am I missing out on by not using the old version?
Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
There's a patch to do that you can install.
I take it you mean this one: http://www.digitalmars.com/d/archives/digitalmars/D/32313.html It's for dmd 0.144, and seem to be some missings symbols from the later versions of phobos. I hope the author will update it sometime. Could be very handy. I got this error: debug\lib\pipestream.obj(pipestream) Error 42: Symbol Undefined _D3std6stream6Stream6isOpenFZx debug\lib\pipestream.obj(pipestream) Error 42: Symbol Undefined _D3std6stream6Stream3eofFZx debug\serverlist.obj(serverlist) Error 42: Symbol Undefined _D3std6thread6Thread5_ctorFDFZikZC3std6thread6Thread --- errorlevel 3
Apr 30 2006
Tydr Schnubbis wrote:I got this error: debug\lib\pipestream.obj(pipestream) Error 42: Symbol Undefined _D3std6stream6Stream6isOpenFZx debug\lib\pipestream.obj(pipestream) Error 42: Symbol Undefined _D3std6stream6Stream3eofFZx debug\serverlist.obj(serverlist) Error 42: Symbol Undefined _D3std6thread6Thread5_ctorFDFZikZC3std6thread6Thread
recompiling the patch should do it.
Apr 30 2006
Walter Bright wrote:Tydr Schnubbis wrote:The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it. I didn't change any of it's settings, so it doesn't seem to work out of the box for me. Anyone else experienced this?
No. I use windbg all the time, and I have a old (slow) machine.But windbg 6 (which I got from Microsoft's site) works fine most of the time. What exactly am I missing out on by not using the old version?
Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.Would be even nicer if the D runtime would print line numbers itself on access violations. Or a full stack trace. :)
There's a patch to do that you can install.
Walter, is there any reason that the patch can't be incorporated into Phobos? Together with the -cov option (!), it does 99.9% of everything I've ever used a debugger for, and does it much more conveniently, too. It's great to have windbug for the last 0.1%, of course.
May 02 2006
Don Clugston wrote:Walter, is there any reason that the patch can't be incorporated into Phobos? Together with the -cov option (!), it does 99.9% of everything I've ever used a debugger for, and does it much more conveniently, too. It's great to have windbug for the last 0.1%, of course.
Sloth on my part.
May 02 2006
Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
What about Visual Studio 2003? I've tried it with my D code, and it seems to me that it knows everything windbg knows. I will look into this further... also with VS2005. I've just tried the debugger that's all. Also, is there some problem, maybe a known one, with try cathc blocks and debugging. With windbg, after an error in a try block, it didn't stepped into catch, but signalled an exception. I this normal? (I will check it with VS too.) ElfQT
May 05 2006
"ElfQT" <dethjunk yahoo.com> wrote in message news:e3ftla$1nec$1 digitaldaemon.com...Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
What about Visual Studio 2003? I've tried it with my D code, and it seems to me that it knows everything windbg knows. I will look into this further... also with VS2005. I've just tried the debugger that's all.
I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this? Instead, I use VS6, in which you can just open an EXE file, and start debugging it.
May 05 2006
In article <e3g20i$1udh$1 digitaldaemon.com>, Jarrett Billingsley says..."ElfQT" <dethjunk yahoo.com> wrote in message news:e3ftla$1nec$1 digitaldaemon.com...Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
What about Visual Studio 2003? I've tried it with my D code, and it seems to me that it knows everything windbg knows. I will look into this further... also with VS2005. I've just tried the debugger that's all.
I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this? Instead, I use VS6, in which you can just open an EXE file, and start debugging it.
I'm only familiar with VS6* myself, but I vaguely recall that it has a properties panel for the current project, where you can set the EXE name to run when debugging. After setting it, the IDE just hooks that program into the debugger when you start a debugging session. Perhaps there's something similar in the more recent versions of visual studio for this. * - I really thing MS had it right with version 6. Why they had to go and change it up and make it resource hog is beyond me. - EricAnderton at yahoo
May 05 2006
In article <e3g3nc$213n$1 digitaldaemon.com>, pragma says...In article <e3g20i$1udh$1 digitaldaemon.com>, Jarrett Billingsley says..."ElfQT" <dethjunk yahoo.com> wrote in message news:e3ftla$1nec$1 digitaldaemon.com...Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
What about Visual Studio 2003? I've tried it with my D code, and it seems to me that it knows everything windbg knows. I will look into this further... also with VS2005. I've just tried the debugger that's all.
I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this? Instead, I use VS6, in which you can just open an EXE file, and start debugging it.
I'm only familiar with VS6* myself, but I vaguely recall that it has a properties panel for the current project, where you can set the EXE name to run when debugging. After setting it, the IDE just hooks that program into the debugger when you start a debugging session. Perhaps there's something similar in the more recent versions of visual studio for this. * - I really thing MS had it right with version 6. Why they had to go and change it up and make it resource hog is beyond me. - EricAnderton at yahoo
I agree with you 100%. They broke visual studio. Why? .Net Although I do have to admit vs 2005 is pretty nice if you have the horsepower to run it.
May 06 2006
pragma wrote:In article <e3g20i$1udh$1 digitaldaemon.com>, Jarrett Billingsley says..."ElfQT" <dethjunk yahoo.com> wrote in message news:e3ftla$1nec$1 digitaldaemon.com...Newer windbg's don't seem to support codeview 4 debug info, which is what dmd generates.
I've tried it with my D code, and it seems to me that it knows everything windbg knows. I will look into this further... also with VS2005. I've just tried the debugger that's all.
able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this? Instead, I use VS6, in which you can just open an EXE file, and start debugging it.
I'm only familiar with VS6* myself, but I vaguely recall that it has a properties panel for the current project, where you can set the EXE name to run when debugging. After setting it, the IDE just hooks that program into the debugger when you start a debugging session. Perhaps there's something similar in the more recent versions of visual studio for this. * - I really thing MS had it right with version 6. Why they had to go and change it up and make it resource hog is beyond me.
Plus it moves your toolbars around mysteriously. I've never figured out what it's doing. Moving from VS6 to VS2003 was the biggest productivity mistake I ever made. Now with D, I'm enjoying using VS6 again. I must confess, though, that my favourite Microsoft IDE was VC4. When you pressed F1, 'Help' came up in 0.2 seconds, and it didn't mention Visual Basic anywhere :-).
May 07 2006
I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this?
Here's a samlpe VS2003 solution. Open, Build, set breakpoint, and press F5. http://elfqt.synthetik.hu/szallit/D/D_DX_Tut05_Textures.zip ElfQT
May 05 2006
I've tried to debug external executables in VS2003, but it only seems to be able to attach to currently-running processes, making it useless for debugging most things (i.e. pretty much anything that's not a GUI app and which doesn't crash immediately). Can you shed some light on this?
Here's a samlpe VS2003 solution. Open, Build, set breakpoint, and press F5. http://elfqt.synthetik.hu/szallit/D/D_DX_Tut05_Textures.zip
And here's a bare VS2003 solution. http://elfqt.synthetik.hu/szallit/D/D_VS_sampleSln.zip ElfQT
May 05 2006
"ElfQT" <dethjunk yahoo.com> wrote in message news:e3gjc4$6t2$1 digitaldaemon.com...http://elfqt.synthetik.hu/szallit/D/D_DX_Tut05_Textures.zip
And here's a bare VS2003 solution. http://elfqt.synthetik.hu/szallit/D/D_VS_sampleSln.zip
Those are pretty cool. Thanks. Although, I'll probably end up still using VS6, as I don't even have to create a new project to do it.
May 05 2006
Walter Bright wrote:Tydr Schnubbis wrote:The windbg that comes with dmd 0.155 is useless for me, because it runs so slow it looks like it hangs when I try to run an app with it. I didn't change any of it's settings, so it doesn't seem to work out of the box for me. Anyone else experienced this?
No. I use windbg all the time, and I have a old (slow) machine.
doesn't work for me. I'm about to give up my project, because printf debugging takes ages...
May 05 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Awesome. These fixes may be just enough to get Tuple working. And the debugger to boot! Thanks, Walter :-) Sean
Apr 28 2006
This bug (crash in gcx.mark() when using several threads) should probably be closed too: http://d.puremagic.com/bugzilla/show_bug.cgi?id=114 Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
Apr 28 2006
Walter Bright wrote:http://www.digitalmars.com/d/changelog.html
You are as I always say, one of the men. (not THE man though, sorry)
Apr 28 2006









Lionello Lunesu <lio lunesu.remove.com> 