Re: dmd 1.056 and 2.040 release
Michel Fortin wrote: On 2010-02-04 01:39:44 -0500, Walter Bright said: Michel Fortin wrote: It's about something interesting I added to this bug report. I submitted a patch for it, 363. Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections. I think you're right.
Re: dmd 1.056 and 2.040 release
Michel Fortin wrote: On 2010-02-04 01:39:44 -0500, Walter Bright said: Michel Fortin wrote: It's about something interesting I added to this bug report. I submitted a patch for it, 363. Thanks. The linker keeps sections in the right order now... except for __tlscoal_nt. If I'm not mistaken, this section should probably get the same treatment as the *_beg and *_end sections. Changeset 365
dmd 1.057 and 2.041 release
Lots of meat and potatoes here, and a cookie! (spelling checker for error messages) http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.057.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.041.zip Thanks to the many people who contributed to this update!
Re: dmd 1.057 and 2.041 release
bearophile wrote:
While this hangs my compiler, I don't know why:
double[100_000] arr = 0.0;
static this() {
arr[] = typeof(arr[0]).init;
}
void main() {}
Well, it didn't hang, it just took a while. I found the problem.
Re: dmd 1.057 and 2.041 release
bearophile wrote:
Note: this produces the same very large binary, I don't know why:
double[100_000] arr = void;
static this() {
arr[] = typeof(arr[0]).init;
}
void main() {}
obj2asm tells the tale. (obj2asm is an incredibly useful tool, I don't
know why nobody uses it.)
double[100_000] arr = void;
puts arr in the thread local storage segment. Unfortunately, there is no
bss for TLS.
__gshared double[100_000] arr = void;
puts arr in the BSS segment, which takes up space in your executable but
not the executable *file*.
Re: dmd 1.057 and 2.041 release
Don wrote: Bug 1914 Array initialisation from const array yields memory trample was fixed, in D2 only. Can we get this into D1 as well? The problem is I don't think it's the right fix, and I haven't spent the time figuring it out yet.
Re: obj2asm
Trass3r wrote: obj2asm tells the tale. (obj2asm is an incredibly useful tool, I don't know why nobody uses it.) Maybe because it's not free (and not much advertised). obconv also supports disassembling various object file formats + conversion between them and it's open source: http://www.agner.org/optimize/#objconv obj2asm might provide something fancy that objconv doesn't but its page doesn't show anything that would justify paying 10$. At first glance, obj2asm will pretty-print the codeview debug info in the object file, and will mix source lines with corresponding assembler lines. Obj2asm also comes with a bunch of other utilities, any one of which is worth the $15 if you need them: ◦chmod Change/list file attributes ◦coff2omf Convert COFF object and lib files to OMF ◦diff Compare text files ◦diffdir Compare directory trees ◦dump Dump files ◦dumpexe Dump executable files ◦dumpobj Dump object files ◦flpyimg Read/Write floppy disk image ◦grep Search files for strings ◦libunres Scan libraries for unresolved externals ◦makedep Makefile dependency generator ◦obj2asm Object file disassembler ◦patchobj Patch object files ◦smake Advanced make program ◦whereis Search for files http://www.digitalmars.com/ctg/obj2asm.html
Re: dmd 1.057 and 2.041 release
Bernard Helyer wrote: On 09/03/10 09:12, Walter Bright wrote: obj2asm tells the tale. (obj2asm is an incredibly useful tool, I don't know why nobody uses it.) Maybe a minor quibble, but obj2asm is really slow. If I'm going to disassemble something, I am never going to reach for obj2asm: Hmm, I never noticed it being slow at all. I wonder what's going on. `ds` is a dmdscript testscript.d executable: [~]$ time objdump -d ~/bin/ds >ds.s real0m1.139s user0m0.912s sys0m0.052s [~]$ time obj2asm ./bin/ds >ds.s # If you pass an absolute path (starts with '/'), obj2asm tries to interpret it as an argument. >_< real0m55.809s user0m11.009s sys0m31.094s And out of curiosity, why do you charge for it on Windows, but provide it on Linux for free? Because the rest of the utilities are fairly windows-centric? Yes, it's because I don't have a similar group of stuff I can bundle for Linux.
Re: dmd 1.057 and 2.041 release
Bernard Helyer wrote: On 10/03/10 08:57, Bernard Helyer wrote: On 10/03/10 07:54, Walter Bright wrote: Hmm, I never noticed it being slow at all. I wonder what's going on. Obviously, I can't tell from here, but I can tell you what my system says obliquely. It spends that minute at 100% CPU, and about 100 megs resident (which it allocates quickly, and then hovers about at). It isn't spending a lot (almost none, AFAICT via iotop, it just does its reading and writing in a couple of big chunks) doing IO. And of course, as you can see, it spends an atypical amount of time in kernel space. Large blocking syscall? It's a mystery. The only I/O it does is merely read the file.
dmd 1.057 and 2.041 deb packages
are now up thanks to Jordi Sayol http://www.digitalmars.com/d/download.html
Re: dmd 1.057 and 2.041 release - operator overloading docs typo
Nick Treleaven wrote: BTW on this page: http://www.digitalmars.com/d/2.0/operatoroverloading.html The 'Index Operator Overloading' link text at the top is duplicated for the link to the 'Slice Operator Overloading' section ;-) Not any more!
Re: April 13th: Presenting D at the Beijing Linux User Group
Lionello Lunesu wrote: I'll be presenting the D Programming Language at the next monthly BLUG meeting. It'll mostly be for people who haven't heard of D yet. There'll be a fair chunk of D1 in there, but I'm hoping to touch some of D2's new features as well. Awesome! (I'm fairly new to 'presenting stuff' in general, so all tips are highly welcomed.) I've noticed that things seem to go better if the presenter tries to engage the audience by asking them questions thereby inviting more of a group discussion, as opposed to just reading the slides to them.
Re: April 13th: Presenting D at the Beijing Linux User Group
Lionello Lunesu wrote: Good tip, thanks. welcs I'm wondering: should I do the 'scrolling HTML', in true D style? The lazy part of me says yes :)) I've abandoned it in favor of pdf: 1. HTML rendering sucks compared with pdf rendering. I don't know why, but when it gets blown up on a big screen, the HTML looks lousy. (The fonts.) 2. HTML tends to not scale well to different screen resolutions. So, if you're using a projector or something with a different screen res than you developed the presentation on, it can look cropped or otherwise goofy. PDF seems to scale well automatically. 3. It's hard to do any sort of simple graphics in HTML. It's easy with a powerpoint program. 4. I've had problems with margins on HTML, i.e. some projectors would do things like just cut off the left side. No problems with PDF. 5. The scrolling HTML comes off as quirky to a lot of people, and that reflects poorly on the presenter and what they're presenting. 6. I've been using Impress (part of Openoffice) and while it can be a wacky thing to use now and then, the result can be exported to a pdf which is pretty bulletproof and looks great when projected. 7. PDF packs everything you need into one convenient file. HTML is a directory full of files. 8. Your presentation computer may have a different browser than the one you developed the presentation on, and so may render unexpectedly differently, or even fail completely. Always always always carry an extra copy of your PDF's on a USB stick and an SD card, and carry them separately from your laptop. Laptops break and get stolen. With your presentation on a USB stick, you're good to go with just about any computer available. I've also found it worthwhile to bring along a laser pointer. It's easier than running around at the last minute trying to scrounge one from the event organizers. Same goes for a wireless remote that plugs into your laptop to page up and down. The remote and the laser are often in one convenient device. Bring fresh batteries for the remote!
Re: April 13th: Presenting D at the Beijing Linux User Group
Andrei Alexandrescu wrote: On 03/10/2010 01:55 AM, Lionello Lunesu wrote: I don't have a watch, but it seems that I might need one then. Wouldn't hurt. You can always borrow one from an attendee. Heck, you can get one for $10 from the corner drugstore.
Announcing bugzilla for dmdscript
Both C++ and D versions: http://bugzilla.digitalmars.com/issues/
Re: dmd 1.057 and 2.041 release
Lars T. Kyllingstad wrote: It seems array literals have become dynamic arrays, but I can't find any mention of that in the change log. I'll fix.
Re: Tango built as a dynamic library
Jacob Carlborg wrote: I've managed to build Tango as a dynamic library with DMD on Mac OS X. I had some problems first but I managed to solve them and everything seems to work now. Thanks for doing this. In the next update, I plan to remove the special deh sections, and instead make the EH tables available through the ModuleInfo. This should simplify the management of multiple sections, as the only data structure that needs to be aggregated will be the ModuleInfo array.
Re: Tango built as a dynamic library
Michel Fortin wrote: On 2010-03-16 15:01:43 -0400, Walter Bright said: In the next update, I plan to remove the special deh sections, and instead make the EH tables available through the ModuleInfo. This should simplify the management of multiple sections, as the only data structure that needs to be aggregated will be the ModuleInfo array. Shouldn't that also apply to TLS sections for when the linker does not support the feature? I'm thinking of Mac OS X and Windows XP with dynamically-loaded DLLs. Rainer Schuetze has found a way to work with the system TLS properly. It's not the linker that's the problem, it's Windows systems earlier than Vista.
dmd 2.042 release
This is necessary to fix a memory corruption problem with arrays introduced in 2.041. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.042.zip Thanks to the many people who contributed to this update!
DMDScript now under Boost license
http://www.digitalmars.com/dscript/index.html
Re: DDebber Request for Review
Jesse Phillips wrote: I would like to announce DDebber. http://dsource.org/projects/ddebber Looks like we have an embarrassment of riches here. Jordi Sayol i Salomó has sent me a shell script to do it, and Cristi has contributed a script to do it that is in http://www.dsource.org/projects/dmd-installer
Re: DMDScript now under Boost license
Walter Bright wrote: http://www.digitalmars.com/dscript/index.html Now on reddit! http://www.reddit.com/r/programming/comments/biufj/javascript_engine_released_under_boost_license/
Re: DMDScript now under Boost license
strtr wrote: Walter Bright Wrote: http://www.digitalmars.com/dscript/index.html Would it be possible to have some sort of scripting as part of D? What did you have in mind?
Re: DMDScript now under Boost license
strtr wrote: Scripting in de form of a dialect/subset of D in the std/language. I don't know enough about scripting to say anything specific/useful. It's just that if scripting were part of D, I would have used it already where the possibilities mentioned by Robert Clipsham just look that much bigger a step. And being part of the language/community simply instils trust. I thought about that a lot, but CTFE seems to fill that gap well enough.
dmd 1.058 and 2.043 release
http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.058.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.043.zip Thanks to the many people who contributed to this update!
Re: dmd 1.058 and 2.043 release
bearophile wrote: In the situation I've shown in 3972 a better error message is the two error messages (or something similar): spam.d(2): Error: module 'test' has mismatched file name 'spam.d'. foo.d(2): Error: module 'bar' has mismatched file name 'foo.d'. The error is not a mismatched file name, which is perfectly legitimate in D. The error is two different files have the same module name.
Re: dmd 1.058 and 2.043 release
Don wrote: Please don't clutter the announce newsgroup with bug reports. And in general, do NOT put multiple bugs in one report. In particular, it's worth saying this to everyone: if something causes a compiler segfault or an internal compiler error, ALWAYS put it in its own report. In > 95% of cases it's a different bug, even if it looks the same as something else. Don's right. But it is ok to reply with a link to a bugzilla report.
Re: dmd 1.058 and 2.043 release
bearophile wrote: Walter Bright: Thank you for your answer. The error is not a mismatched file name, which is perfectly legitimate in D. Do you mean that in D it is OK to have a file named "foo.d" with inside it at the top written "module bar;" ? Yes. What's the rationale behind this? (I don't like this). The flexibility comes in handy now and then.
Going to ACCU next week
with Andrei to do a full day D tutorial. I'm not sure how connected I'll be with email and stuff. http://accu.org/index.php/conferences
Re: April 13th: Presenting D at the Beijing Linux User Group
Lionello Lunesu wrote: The presentation came and went, and was much appreciated, judging from the reactions :) Great! I hope you enjoyed it as well.
Re: Visual D released
Rainer Schuetze wrote: Enjoy, Rainer Awesome!
Re: Visual D released
Mike Parker wrote: FYI, I posted about this announcement on my blog (The One With D) and someone submitted the post to Reddit. Several of my D blog posts have been submitted to Reddit before, but none have had the sort of response I'm seeing now. I just checked my stats on a whim and the post about Visual D has the most single-day hits of any post in the 4 years I've been running the blog. Every time I refresh the stats page the hit count climbs higher. The missing link: http://www.reddit.com/r/programming/comments/bt0ts/visual_d_program_d_in_visual_studio/
Re: Going to ACCU next week
Bruno Medeiros wrote: On 10/04/2010 18:55, Walter Bright wrote: with Andrei to do a full day D tutorial. I'm not sure how connected I'll be with email and stuff. http://accu.org/index.php/conferences Hum, I read last weekend the ACCU booklet they gave with all the descriptions of the conferences, started to feel a bit more disheartened that I wouldn't stay for the whole conference, they had some pretty interesting talks! No regrets though, and there's always next year. But anyways, it was nice meeting you guys, Walter and Andrei, and maybe next time you are here in Europe we'll meet again, and maybe can garner a few more D enthusiasts from the community. :P Yes, it was great meeting you in 3D land!
Re: Going to ACCU next week
Chris Mueller wrote: I also hope some videos will be available for this event :) That would be great! Sorry, there were no videos taken of the event.
Bob Martin talks about FP at the OpenVolcano10 conference
Not terribly interesting, but what the heck. http://sleepoverrated.com/archive/2010/04/functional-programming-openvolcano10/ I appear about 8 minutes in. The OpenVolcano10 conference was organized by Roy Osherove in one day! We were all stuck behind the ash cloud in England. My presentation on D unfortunately didn't get recorded. BTW, Bob was actually able to explain monads to me a bit later, and I'm grateful to him for that. More on OpenVolcano10 can be found here: http://twitter.com/#search?q=%23openvolcano10
Re: Masahiro Nakagawa and SHOO invited to join Phobos developers
Moritz Warning wrote: Walter takes any possible copyright taint very serious. Yes, I do. It is extremely important for D's future that D and Phobos be clear of any intellectual property legal problems. Phobos is now under the Boost license, which is the most liberal one we could find that was in common use and meets with corporate and lawyer approval. All submissions to Phobos must be under this license. Better someone told W about it before he does an emergency blow up of phobos. ;) Yes, I'm glad to hear about it sooner rather than later. Maybe you can talk to the Tango devs to clear up this matter? I suggest that the Tango devs convert the Tango modules that can get full agreement by their respective devs be converted to the Boost license. The Boost license is free of the legal problems that BSD has, and is compatible with the Phobos license.
Re: Masahiro Nakagawa and SHOO invited to join Phobos developers
Moritz Warning wrote: On Thu, 29 Apr 2010 09:24:22 -0700, Walter Bright wrote: Moritz Warning wrote: [..] Maybe you can talk to the Tango devs to clear up this matter? I suggest that the Tango devs convert the Tango modules that can get full agreement by their respective devs be converted to the Boost license. The Boost license is free of the legal problems that BSD has, and is compatible with the Phobos license. As far as I have heard, Tango changed it's license to be compatible with Phobos in the first place. Tango is originally based on Phobos code, and I gave explicit permission for it to be incorporated into the Tango project & BSD license, but the BSD license does not permit code to flow the other way without the explicit permission of the Tango devs. Some code has moved back to Phobos, in particular Sean & Don's work, because Sean & Don are the developers of that code and it is their prerogative to do what they please with it. But Phobos then changed it's license and now it's incompatible again. What were the reasons for Phobos to change the license? I suspect is was discussed before, do you have a link? Phobos was formerly actually a collection of different licenses, Phobos 1.0 still is. Some was public domain. The reason it was switched (for Phobos 2) to Boost was: 1. Boost is corporate and lawyer approved, making it a no-brainer for commercial, professional use of Phobos 2. Boost is the most liberal license we were able to find 3. Public domain is not recognized in many countries 4. Having one license for Phobos makes it much easier to manage and deploy The perennial problem with the BSD license is the binary attribution clause. Tango believes it has a solution to this by embedding the appropriate string in object.d, but I don't know if this has been legally tested and it still puts a constant burden of explanation on the Tango team. It's just a problem that I can see no reason to adopt.
Re: Masahiro Nakagawa and SHOO invited to join Phobos developers
Nick Sabalausky wrote: It looks like the Tango devs are pretty much settled on BSD-only with some hack to get around the binary attribution thing: http://www.dsource.org/projects/tango/ticket/1701 The problem with the hack is everyone trying to use the library professionally will (if one is lucky) ask about the binary attribution thing, and one would have to convince them that the hack takes care of it. This puts a never ending burden on the team. If one is unlucky, they'll just avoid the library because of that license, and you'll never hear from them about the lost opportunity. Those options are bad and worse, hence changing the license is a much more attractive proposition going forward.
Re: GDB Patched
Jesse Phillips wrote: GDB has had the patch accepted! Great news!
Re: Can we all please stop overreacting?
Chris Wright wrote: Walter said, basically, that since it's possible that SHOO may have used code from Tango, Tango devs should relicense their work. Not exactly. To rephrase, I said that since SHOO has viewed Tango's source code, there is the appearance of impropriety. Not that there actually is any impropriety. It's the appearance I wish to avoid. I am not accusing anyone of infringement, and have no basis to. I have asked the Tango devs to relicense their work. I feel that if that can be accomplished, this would bury this issue once and for all, and the rift between the communities should heal. That's insulting. It's admitting theft and demanding that the victim call it a gift. If it were a policy, Walter would have a way of badgering us into relicensing most of Tango against our will. I can't make you do anything you don't want to. I especially have no means, desire, or intention of forcing anyone to change their license or give up their copyrights. I'm not saying that SHOO copied any Tango code. Walter's reaction, though, means I would never relicense any code for Phobos. I've repeatedly stated, and say so again, that I give explicit permission to Tango to incorporate any or all of code I have written for Phobos into Tango, and to relicense those derived works as necessary to be compatible with Tango. Tango's garbage collector is such a derived work, and I have no issue with it. As for Phobos code I did not write, in order to relicense it, you'd have to get the permission of the author(s) of it, which is stated in each module. But it is entirely unnecessary to relicense it - the Boost license allows you to use it any way you want to. The Boost license is not viral, it will not "infect" anything you hook it up to (neither does the BSD license - in fact, the only real difference between the BSD and Boost licenses is the binary attribution clause).
Re: Can we all please stop overreacting?
Daniel Keep wrote: I won't discuss the details, but I *have* been accused of ripping off someone else's code. So have I, falsely, many times. Perhaps I am overly cautious about these issues, but I feel compelled to be. (I've also been on the other side, my game Empire was once described as the "most ripped-off game in history" , with not only people making ripoff versions, but people actually deleting my name out of the source code and putting their own name in. Having a registered copyright of the source code saved the day on that one.) It was particularly hurtful given that my code was written entirely separately without ever having even used, let alone seen, the other person's code. The accusation was based, literally, on the name of a single function. And yeah, it really upset me to be called, more or less, of being a cheat and a liar. I totally am sympathetic to this. It is just as bad to be falsely accused as it is to have someone take what is yours. But I didn't copy from them, and I knew that the accusation was baseless. Rather than throw away my code, I double-checked that there was nothing that could be reasonably seen to be copied and moved on. One of the great things about svn is it provides a verifiable legal trail of the evolution of the source code, so when and where bits of it came from can be documented if necessary. Ironically, making things open source seems to greatly reduce the chances of code theft!
Re: Can we all please stop overreacting?
Andrei Alexandrescu wrote: Second, I recall a similar accusation (I'm not sure whether it was coming from 'retard' or someone else) about an arrogant [...] Probably meaning me .
dmd 1.059 and 2.044 release
Highlights are the improved gdb support, better error messages, better json support, unittest changes, and a number of nuisance compiler bugs fixed. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.059.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.044.zip Thanks to the many people who contributed to this update!
Re: dmd 1.059 and 2.044 release
Bernard Helyer wrote: Unfortunately, GDB still doesn't work with it over here. Robert is going to try one of my test cases and see what he can see. Good.
Re: dmd 1.059 and 2.044 release
Bernard Helyer wrote: On 03/05/10 11:40, Walter Bright wrote: Bernard Helyer wrote: Unfortunately, GDB still doesn't work with it over here. Robert is going to try one of my test cases and see what he can see. Good. I can't stop laughing. I assume you meant to trim that quote down some! *g* LOL, I meant good that Robert is working on it, not good that it doesn't work!
Re: dmd 1.059 and 2.044 release
Robert Clipsham wrote: It seems changeset 451, your version of the fix, doesn't work... Despite me testing that it worked when you committed it :/ Reverting the change fixes the issue. Any ideas why?
Re: dmd 1.059 and 2.044 release
bearophile wrote: It contains two wrong unit tests, but dmd prints just about the first one, maybe I am missing something: Looks like I broke it with a last minute change. Sigh.
Re: dmd 1.059 and 2.044 release
bearophile wrote: It contains two wrong unit tests, but dmd prints just about the first one, maybe I am missing something: test(3): unittest failure core.exception.asserter...@test(3): unittest failure changeset 289 fixes it
Re: dmd 1.059 and 2.044 release
Bernard Helyer wrote: I've had the infinite loop thing, too. As well as the '2:' to ouput. My fault, grr.
Re: dmd 1.059 and 2.044 release
Robert Clipsham wrote: And other cases. Simplest solution seems to be to revert the change, but it's up to you what you do... As long as it's fixed I don't care how it's done :) Dang, I found the problem. Working on a fix.
Re: dmd 1.059 and 2.044 release
bearophile wrote: It contains two wrong unit tests, but dmd prints just about the first one, maybe I am missing something: test(3): unittest failure core.exception.asserter...@test(3): unittest failure How about signing up for the beta mailing list?
dmd 1.060 and 2.045 release
This is to fix the unittest and dwarf screwups in the last release. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.060.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.045.zip
Re: dmd 1.060 and 2.045 release
Robert Clipsham wrote: Still a long way to go though, various (much!) smaller issues that need fixing... If no one else gets to them I'll go on a debug fixing spree at some point in a couple of months and see if we can't get bug #4044 (debugging tracker) closed :) I agree that getting all the gdb issues sorted out will be a nice win.
Re: dmd 1.060 and 2.045 release
Robert Clipsham wrote: While you're reading, is there any chance you could take a look at my post on the dmd-internals ML and give me some feedback? I noticed you agreed with Brad in a bug report, but to what extent? When I get around to fixing all those bugs I'd like to know where you stand so I can work on some enhancements to debug info as well as just bug fixes :) Basically, I don't think the switches need to change, just: -g: debugger can handle D data types and extensions -gc: make it work with whatever the debugger can handle, i.e. for debuggers that don't know about D
Re: dmd 1.060 and 2.045 release
Robert Clipsham wrote: You'd be ok with, for example: -g add symbolic debug info -gcadd symbolic debug info, pretend to be C++ Instead of C then? Or some other language that debuggers support? I say this as C++ supports more of D's features, so we'd be able to give better debugging info for debuggers without explicit D support. Yes. There was another point in that post, about the D extensions to DWARF... I think it is unlikely that patches to support D's extensions to DWARF would be accepted into gdb, particularly as the values for the DW_TAG's conflicts with things in the DWARF4 spec. I think there should be a way to act like D but without these extensions. Ideally the solution to this is to try and get the extensions officially into the DWARF spec, which I'd be willing to push for if possible. That's the problem with D extensions; unless they get officially adopted they conflict with future changes to the spec. We need to get them officially adopted.
Re: dmd 1.060 and 2.045 release
Robert Clipsham wrote: On 04/05/10 19:50, Walter Bright wrote: That's the problem with D extensions; unless they get officially adopted they conflict with future changes to the spec. We need to get them officially adopted. Too late for this, DWARF 4 has introduced conflicts with them already. We could try and get them pushed for dwarf 4, but if they get in the values of the tags will have to change (not really a problem, as only one debugger supports them I think, and to my knowledge it isn't widely used for D yet... So we'd be able to talk to the developers and work around this). I'd be willing to take action to get them pushed for DWARF 4 or (if it's too late for that) DWARF 5, if that's OK with you? Yes, do it!
Re: dmd 1.060 and 2.045 release
Robert Clipsham wrote: On 05/05/10 20:36, Robert Clipsham wrote: On 04/05/10 20:43, Walter Bright wrote: Yes, do it! http://dwarfstd.org/ShowIssue.php?issue=100504.1 Please feel free to comment on it/make corrections :) "This has been assigned issue #100504.1. We are not accepting extension proposals for DWARF Version 4, but will consider this for the next version." Looks like we'll have to wait a while for its inclusion. In the mean time could I suggest we move the DW_TAG's of dmd's extensions to the area of the spec specified for language specific extensions? I'm not sure if this was specified in DWARF 2 which dmd uses, or what the range is (I don't have the spec to hand), but it would be good not to conflict with DWARF 4. Good idea. Another good idea could be to decide how else DWARF could be extended to help with debug info so we have more chance of getting some useful things for debugging into DWARF 5.
Re: dmd 1.060 and 2.045 release
Alex Makhotin wrote: It takes ~40 seconds 50% load on the dual core processor(CentOS 5.3 kernel 2.6.32.4), to get the actual error messages about the undefined identifier. Definitely there's a problem.
Re: dmd 1.060 and 2.045 release
Walter Bright wrote: Alex Makhotin wrote: It takes ~40 seconds 50% load on the dual core processor(CentOS 5.3 kernel 2.6.32.4), to get the actual error messages about the undefined identifier. Definitely there's a problem. The problem is the spell checker is O(n*n) on the number of characters in the undefined identifier.
Re: dmd 1.060 and 2.045 release
Alex Makhotin wrote: Walter Bright wrote: Walter Bright wrote: Alex Makhotin wrote: It takes ~40 seconds 50% load on the dual core processor(CentOS 5.3 kernel 2.6.32.4), to get the actual error messages about the undefined identifier. Definitely there's a problem. The problem is the spell checker is O(n*n) on the number of characters in the undefined identifier. Is there a way to disable it? Currently, no.
Re: dmd 1.060 and 2.045 release
Steven Schveighoffer wrote: That can't be it. The identifier shown by Alex is only 33 characters. O(n^2) is not that slow, especially for smaller variables. There must be other factors you're not considering... I recompiled dmd with the profiler (-gt switch) which confirmed it.
Re: dmd 1.060 and 2.045 release
Steven Schveighoffer wrote: On Thu, 06 May 2010 17:07:12 -0400, Walter Bright wrote: Steven Schveighoffer wrote: That can't be it. The identifier shown by Alex is only 33 characters. O(n^2) is not that slow, especially for smaller variables. There must be other factors you're not considering... I recompiled dmd with the profiler (-gt switch) which confirmed it. So a single unknown symbol (from Alex's example) which can be checked against each existing symbol in O(n^2) time, takes 40 seconds on a decent CPU? How many other symbols are there? 33^2 == 1089, if there are 1 symbols, that's 10 million iterations, that shouldn't take 40 seconds to run, should it? Are there more symbols to compare against? Do you use heuristics to prune the search? For example, if the max distance is 2, and the difference in length between two strings is >2, you should be able to return immediately. Check out the profiler output. It's clearly the vast number of calls to the symbol lookup, not the time spent in each call. - Num TreeFuncPer CallsTimeTimeCall 50409318 632285778 145858160 2 Dsymbol *syscall ScopeDsymbol::search(Loc ,Identifier *,int ) 50411264 131394915 106356855 2 void **syscall StringTable::search(char const *,unsigned ) 50409329 341960075 105532978 2 Dsymbol *syscall DsymbolTable::lookup(Identifier *) 50409329 236427096 105037393 2 StringValue *syscall StringTable::lookup(char const *,unsigned ) 12602340 61389061967393753 5 Dsymbol *syscall Scope::search(Loc ,Identifier *,Dsymbol **) 12602178 69391519766918360 5 void *cdecl scope_search_fp(void *,char const *) 25204505 46135292052529164 2 Dsymbol *syscall Module::search(Loc ,Identifier *,int ) 504121372503847425038474 0 unsigned cdecl Dchar::calcHash(char const *,unsigned ) 3520 1428323068203493755781 void *cdecl spellerX(char const *,void *cdecl (*)(void *,char const *),void *,char const *,int ) 12602664 6811916 6811916 0 syscall Identifier::Identifier(char const *,int ) 12602178 6299089 6299089 0 void cdecl Module::clearCache() 12602183 6151175 6151175 0 Module *syscall Module::isModule() 1600 113294261 2 StringValue *syscall StringTable::update(char const *,unsigned ) -
Re: dmd 1.060 and 2.045 release
Walter Bright wrote: I recompiled dmd with the profiler (-gt switch) which confirmed it. For those interested, try out changeset 470.
Re: dmd 1.060 and 2.045 release
Walter Bright wrote: Walter Bright wrote: I recompiled dmd with the profiler (-gt switch) which confirmed it. For those interested, try out changeset 470. On my timing tests, the time spent is linear with the number of characters in the identifier. It's still too slow, though.
Re: dmd 1.060 and 2.045 release
Steven Schveighoffer wrote: It may not be an issue, the spell checker is simply a nice hint, but isn't essential to determine errors. It's a good summary of the situation. I've felt that as long as the message took under a second to generate, it was ok. Realistically, I don't see anyone using identifiers as long as you tested unless they were machine generated. In my own code, I've found the spell checker is more than a nice hint. Most of the time it nails it and speeds fixing the problem because I don't need to myself go and manually look up the correct spelling. Iterating through the symbol table is not impossible, it's just a lot of work as it is not designed for that. There are also some issues with shadowing. Furthermore, I'd like the speller to work with the symbol table in the C++ compiler, too, which I don't wish to reimplement.
Re: Shin Fujishiro joins Phobos
Andrei Alexandrescu wrote: Please join me in welcoming Shin Fujishiro to Phobos. Welcome!
Re: I rewrite std.time for Phobos
Steven Schveighoffer wrote: First, I hope this can be included, it looks like very solid code. Second, if it cannot be included, I hope this does not dissuade you from contributing to Phobos for other modules. Basically, the next time there's a suggestion of infringement from anyone, I'd like a specific list of the lines of source that are infringing. I don't think there's any reasonable way to deal with it otherwise. It shouldn't be necessary to guess what those lines might be.
dmd 1.061 and 2.046 release
This is to fix the spell corrector speed problems and several forward reference bugs. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.061.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.046.zip
Re: dmd 1.061 and 2.046 release
Ary Borenszweig wrote:
Walter Bright wrote:
This is to fix the spell corrector speed problems and several forward
reference bugs.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.061.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.046.zip
Add hints for missing import declarations.
What does that mean?
Write the following program:
---
void main()
{
writeln("hello world!");
}
---
compile it and see what happens. I think it'll be clear!
Re: dmd 1.061 and 2.046 release
Leandro Lucarella wrote: I saw the patches, and having all hardcoded in the compiler doesn't seems like a good idea =/ I know the hardcoding is probably not the best, but I wanted to try it out to see if it was a good feature before committing a lot of work to it. The alternative is to use some sort of configuration file for it. The problem, though, is that the hints are for newbies, and newbies probably aren't going to get a configuration file properly set up, especially if there are multiple such files.
Re: dmd 1.061 and 2.046 release
Don wrote: Walter Bright wrote: Leandro Lucarella wrote: I saw the patches, and having all hardcoded in the compiler doesn't seems like a good idea =/ I know the hardcoding is probably not the best, but I wanted to try it out to see if it was a good feature before committing a lot of work to it. The alternative is to use some sort of configuration file for it. The problem, though, is that the hints are for newbies, and newbies probably aren't going to get a configuration file properly set up, especially if there are multiple such files. I think the only purpose of such a feature is to increase the chance that a newbie's "hello world" compiles successfully. The importance of that can't be underestimated, I think. First impressions matter. Yes, or at least have a to-the-point error message rather than just an undefined identifier. It's amazing how much information we take for granted. For example, I've been trying to use Apple's xcode system. I find it hard to do the most trivial things, like trying to figure out how to just start the thing. Apple's web site isn't much better, it's got to be the most hard to read site I've ever encountered. The text is a faint grey on white, of all things, and the font is so poorly rendered my eyes turn red and painful after a while reading it. I have to actually select the text in order to read it. I find this astonishing, am I doing something wrong? It won't render at all in Explorer. The D web site is rather pedestrian, but at least it's easy on the eyes.
Re: dmd 1.061 and 2.046 release
Jacob Carlborg wrote: On 5/15/10 11:00, Walter Bright wrote: Apple's web site isn't much better, it's got to be the most hard to read site I've ever encountered. The text is a faint grey on white, of all things, and the font is so poorly rendered my eyes turn red and painful after a while reading it. I have to actually select the text in order to read it. I find this astonishing, am I doing something wrong? Looking at Apple's developer site and the API reference, for me the body of the text is black using firefox, some minor parts are in gray. I'm using firefox. Even on their main developer.apple.com/iphone/index.action, most of the text is light grey on white. Now click on "getting started documents", which brings you to a page that will not render in Explorer or Firefox, only Safari. In the docs themselves, a very light blue font is used for links that is illegible. The code examples in the docs are even lighter grey on white. Couple this with the unusually small font used, and it's literally painful to read. For a company that prides itself on excellent readability, I am astonished, and I can't believe I'm the only one with problems reading their pages.
Re: dmd 1.061 and 2.046 release
Leandro Lucarella wrote: I think the feature could be nice if it needs no configuration at all (it searches the import path and looks for modules where a missing symbol is). The problem with that is often newbies have trouble setting up import paths.
Re: dmd 1.061 and 2.046 release
Jérôme M. Berger wrote: Walter Bright wrote: Jacob Carlborg wrote: On 5/15/10 11:00, Walter Bright wrote: Apple's web site isn't much better, it's got to be the most hard to read site I've ever encountered. The text is a faint grey on white, of all things, and the font is so poorly rendered my eyes turn red and painful after a while reading it. I have to actually select the text in order to read it. I find this astonishing, am I doing something wrong? Looking at Apple's developer site and the API reference, for me the body of the text is black using firefox, some minor parts are in gray. I'm using firefox. Even on their main developer.apple.com/iphone/index.action, most of the text is light grey on white. Text is black here. But it is very thin, are you sure this isn't an anti-aliasing issue? Yes, because there is some legible black text on other parts of the page. Now click on "getting started documents", which brings you to a page that will not render in Explorer or Firefox, only Safari. Works fine here. Firefox 3.6.3 on Linux. 3.0.18 on Ubuntu.
Re: dmd 1.061 and 2.046 release
Charles Hixson wrote: On 05/15/2010 02:00 AM, Walter Bright wrote: The D web site is rather pedestrian, but at least it's easy on the eyes. *Pedestrian*?? The D web pages are a marvel of clarity and utility. Compare them to the Python web pages, which I rate a second best. Things are documented with relative clarity, one can generally find what one needs with a bit of searching, even if one doesn't know what it's named. Etc. The D web site has only two minor (*minor*!) problems One is the search engine which doesn't work on local copies. The other is that one needs to disable google translation on local copies, or everything loads too slowly. (The first of those is probably impossible to deal with, but the second looks trivial.) If by pedestrian you mean clean, clear, and easy to use, then give me more pedestrian. People often say it doesn't look professional. I agree it could probably use better colors, etc. But for this kind of web site, I think it's just wrong to use flash, javascript, or anything that takes a long time to load. I don't like pages that have a tiny bit of content surrounded by acres of flashy, blinky, hovering advertisements. I don't like websites that sacrifice readability in favor of a "look". I don't like web pages that refuse to reflow if the window size is changed. The site should print properly, and be mechanically convertible to a reasonably decent looking pdf. The site needs to be friendly to search engines, and usable by screen readers. Yes, there are blind programmers, and at least one blind D programmer. It's obnoxious to make a site they cannot use. I'm also old, and just don't like sites that use small fonts, cute fonts, blurry fonts, fonts with poor contrast, etc. They're hard, even painful, to read. When I was a kid writing letters to my aged relatives, my mom told me that they'd struggle to read typical handwriting, and that it's nice to use a typewriter instead. I always remembered that advice, and when I started using word processors for letters, the ones I'd send to them I'd always enlarge the font quite a bit. Web sites should avoid setting specific font sizes, so low vision users can enlarge it. I recently completed a revamp of the digitalmars site that got rid of the table based layout in favor of using floating CSS layout. The result looks a bit nicer, and the printing should be much better. My sole problem with D is one that's probably impossible to address: the lack of libraries. When I need libraries, I usually end up using some other language. But it sure isn't the web page. (DSource is marvelous, but most of the libraries listed appear to be either moribund or morbid.) The library situation hopefully will get better over time. And thanks for the kind words about the site (!), it is nice to hear them.
Re: dmd 1.061 and 2.046 release
Nick Sabalausky wrote: I recently completed a revamp of the digitalmars site that got rid of the table based layout in favor of using floating CSS layout. The result looks a bit nicer, and the printing should be much better. Speaking as a web developer, I've found that floating CSS is irritatingly gimped compared to tables when trying to adjust how things flow upon resizing. (Speaker as a web user, I've never cared one bit whether a site used floating CSS vs tables.) Doing them as floating CSS makes it possible to "nodisplay" the navigation sections when formatting for print. The whole HTML/CSS design is such a horrific kludge it's a wonder it works at all.
Re: dmd 1.061 and 2.046 release
Steven Schveighoffer wrote: On Mon, 17 May 2010 13:29:19 -0400, Andrej Mitrovic wrote: Charles Hixson Wrote: The D web pages are a marvel of clarity and utility. Compare them to the Python web pages, which I rate a second best. OT: The funny thing about the Python website, is that I never managed to find a direct link to the package repo (pypi) from the main site. And yet if I google PyPI, and follow a link to pypi.python.org, a Package Index tab suddenly appears on the top left. If I click on another tab, it dissapears again. Needlessly inconsistent imo. (+ how are newbies supossed to find the libraries if they're not linked from the main site?) The D website's navigation bar suffers the same problems. I cannot reproduce such bad behavior.
Re: dmd 1.061 and 2.046 release
Steven Schveighoffer wrote: The end result is, sometimes I can't find a link I clicked on before, because I'm no longer on the exact right page -- the nav bar is totally dependent on the current page! I agree, the nav bar changes from page to page. Not sure that's a problem, though.
Bartosz' Message Passing talk tonight
Title: The Anatomy of Message Passing Speaker: Bartosz Milewski Date: May 19, 2010 Time: 7 pm Place: Microsoft Eastside Campus, Bldg 41, Townsend (see our website www.nwcpp.org for directions).
Re: dcollections 1.0 and 2.0a beta released
Andrei Alexandrescu wrote:
I wrote a solution to the problem in native D. It goes like this:
alias Container!(int, addable | purgeable) Messerschmidt;
void messWith(Messerschmidt i) {
... use i's capabilities to add and purge ...
}
I agree with Michael Fortin that the | is questionable. I'd like to suggest
instead that it should instead be a variadic list of names, like:
alias Container!(int, addable, purgeable) Msserschmidt;
Perhaps the names should follow a naming convention,
alias Container!(int, ContainerAddable, ContainerPurgeable) Msserschmidt;
The problem with using scoped names, like Container.Addable, is scoped names
cannot be added to.
Re: dcollections 1.0 and 2.0a beta released
Andrei Alexandrescu wrote: See the -mergefunc compiler switch of LDC, to merge identical functions (like ones produced by template instantiations). This feature is not very powerful yet, but it's present and I have seen it works. Indeed. I'm no expert in linkers, but in my opinion this is one of the most basic optimizations a linker should perform. And C++ has pushed linkers to do that for years now so I'd expect most linkers to do that already... The problem with templates are more the multiple slightly different instanciations. In general this is good for performance, but it's only needed for the code paths that need to be fast. I think generic containers should be fast. There's been talk that Walter's slow porting of the linker to C and then D will put him in the position to introduce such an optimization. Unfortunately, it's an agonizingly slow process. It also does nothing for Linux or OSX.
Re: dcollections 1.0 and 2.0a beta released
Andrei Alexandrescu wrote: On 05/19/2010 09:59 PM, Robert Jacques wrote: Yes and No. I understand where your coming from, but I think it's a bad idea. First, I think it needlessly expands the radius of comprehension needed to understand and use the library. (See Tangled up in tools http://www.pragprog.com/magazines/2010-04/tangled-up-in-tools) For the record, I strongly agree with this. I do too, but that's the easy part. Living up to those ideals is extremely hard, usually because most designers think they have designed simple interfaces when everyone else thinks they didn't. In this whole container discussion, I'd like to point out something Andrei pointed out to me. The one extremely successful example of pluggable components is the unix filter model. Essentially, one program pipes its output to the next, which pipes its output to the next, etc. The unix console is designed around that paradigm. If we can get anywhere close to that level of success with ranges and containers, we should all be well pleased.
Re: dcollections 1.0 and 2.0a beta released
Walter Bright wrote: If we can get anywhere close to that level of success with ranges and containers, we should all be well pleased. Mike Taylor has a phrase for that I think is well-coined: "impedance matching", defined as the work necessary to get one library module to work with another library module. One example of bad impedance matching is C++ iostreams' attempt to make a memory buffer look like a file. Phobos propagated that mistake in its own streams.
Re: dcollections 1.0 and 2.0a beta released
Walter Bright wrote: If we can get anywhere close to that level of success with ranges and containers, we should all be well pleased. Mike Taylor has a phrase for that I think is well-coined: "impedance matching", defined as the work necessary to get one library module to work with another library module. One example of bad impedance matching is C++ iostreams' attempt to make a memory buffer look like a file. Phobos propagated that mistake in its own streams. A better way is to use ranges, where the file is accessed via a range and a memory buffer is accessed via a range. Then anything that operates on data is written to the range, not a fake file interface.
Re: dcollections 1.0 and 2.0a beta released
Michel Fortin wrote:
On 2010-05-21 22:55:16 -0400, Walter Bright
said:
Walter Bright wrote:
If we can get anywhere close to that level of success with ranges and
containers, we should all be well pleased.
Mike Taylor has a phrase for that I think is well-coined: "impedance
matching",
defined as the work necessary to get one library module to work with
another
library module.
This makes me think about something.
In principle, I like the idea of containers being reference type. It
works well when passing a container to functions. But at the same time,
I despite it. By-reference containers forces you to have extra
indirections even when you don't need them, and you have to worry about
null. Sometime a value-type would be better, when creating more complex
data structures for instance:
class Channel {
private {
Array!Message inbound;
Array!Message outbound;
}
...
}
What's the point of having extra indirection here?
Good question. I think the answer is:
1. When do you ever want to copy a collection? I almost never do, because
copying one is an inherently expensive operation.
2. When you copy a collection, do you copy the container or the elements in the
container or both? One would have to carefully read the documentation to see
which it is. That increases substantially the "cognitive load" of using them.
3. Going to lengths to make them value types, but then disabling copying them
because you want people to use them as reference types, seems like a failure of
design somewhere.
4. That silly extra level of indirection actually isn't there. Consider that
even value locals are accessed via indirection: offset[ESP]. For a reference
collection we have: offset[EBX]. No difference (yes, EBX has to be loaded, but
if it is done more than once it gets cached in a register by the compiler).
5. Just making them all reference types means the documentation and use become a
lot simpler.
Re: [OT] Web font sizing
Stewart Gordon wrote: But maybe it's acceptable if all you're doing is compensating for the font you've chosen looking a little bigger or smaller at the same point size than the default Times New Roman. That said: - somebody might have set a different font as default in browser settings or a user stylesheet - who decreed that the factory default in all graphical browsers shall be Times New Roman, anyway? With style sheets, you can set the font size as larger or smaller than the default. This should be good enough. Setting fonts as pixel sizes is just wrong.
Re: "D Programlama Dili" is almost finished
Ali Çehreli wrote: It is a Turkish D2 book. I know that this news is not very useful for the members of this forum, but I am proud to announce that my D book targeting the Turkish reader is almost complete. It is for the novice programmer. Complete with exercises and solutions, it starts with the assignment operator and gradually builds other concepts. (I must say that D is an easy language to teach to novice programmers.) Since starting in July 2009, I've been making the chapters freely available at http://ddili.org/ders/d/ The free pdf version is around 520 pages these days. After finishing the final two chapters, I will get back to bringing the information up to date, e.g. the new operator overloading syntax should replace the old one. On a personal note, as far as I know, this book has been the first in computer technology where Turkish precedes any similar work in English. :) Thank you, Ali This is great work, and thanks for adding the google translator widget too! I put a link http://www.digitalmars.com/d/2.0/index.html and on http://twitter.com/D_Programming
D Programming now on twitter
http://twitter.com/D_Programming also use #d_lang to connect D related tweets
Re: OT: Use of D-icon
Matthias Pleh wrote: Am 28.05.2010 20:06, schrieb Walter Bright: http://twitter.com/D_Programming also use #d_lang to connect D related tweets OT: I'm working on a redesign for wiki4d. Now I've seen the D-logo on twitter and I like it. :) Can we use this picture for wiki4d? That was submitted by a user many years ago, the problem is I lost track of who it was. But I do recall he meant it to be used, so go ahead.
Re: new layout on wiki4d
Matthias Pleh wrote: For those, who aren't yet aware of the wiki-site: http://www.prowiki.org/wiki4d/wiki.cgi Suu-weeet!
Re: Bartosz' Message Passing talk tonight
Phil Deets wrote: The website has a new post for a June meeting now, but there is no date or time posted. I e-mailed the contact e-mail address about this, but I got a delivery failure notification so the address must be out of date. Does anybody know when the June meeting is? Here's the announcement for the June meeting. I plan on attending, I think it'll be fun. Of course, it will be great to see there as many of our D community as can come! (Afterwards, we go out for a drink & some food at the local watering hole.) === Next week Gavriel Plotke will be talking about the harnessing of the power of the graphics chip as a massively parallel supercomputer that sits, mostly idly (uless we play a lot of games, that is), inside most computers. Title: Massive Multithreading on the GPU. GigaFlops or... TeraFlops? Speaker: Gavriel Plotke, Microsoft Senior SDET Date: Wednesday, June 16the Place: Microsoft Eastside Campus, Bldg 41, Townsend (see our website www.nwcpp.org for directions). Abstract: The modern GPU is a massively parallel supercomputer that has 2 orders of magnitude more processing power then a single CPU Core. But the threading model is very different than the CPU. Don't get left behind on knowing about this different paradigm. Bio: I've been with Microsoft for 3 years on the DirectX High Level Shader Language compiler test team. I've been a champion of the new Compute Shader features of DirectX11. While I have some graphics background, it was my assembler language and compiler writing background that got me the job. Early in my career I worked on the internals of a mainframe spreadsheet product as a competitor to VisiCalc and Lotus123. It was a time when everyone in a big office would have a mainframe terminal and no one had a PC. It was a great product, but time moved on, and Excel on inexpensive PCs ate our lunch. After that I spent a many years doing business contract work - different projects, different platforms, lots of database design. Now I help support programming on today's supercomputer, the modern graphics card.
dmd 1.062 and 2.047 release
There are a lot of improvements in this release, done by quite a lot of people working on it. Thanks to everyone who pitched in! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.062.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.047.zip
Re: dmd 1.062 and 2.047 release
Andrei Alexandrescu wrote: Lutger wrote: I noticed both std.concurrency and std.json are not (yet?) included in the documentation. Does that have any bearing on their status, are they usable and / or stable? std.container too. Fixed.
Re: dmd 1.062 and 2.047 release
strtr wrote: My project takes 4 times longer to compile with 1.062 (iso 1.061). It now takes 1min 20sec on my p4 and memory doesn't seem to be the problem (<80MB). I'd rather have it below 30sec :) I have no idea why that might be. Anyone else have this problem?
Re: dmd 1.062 and 2.047 release
strtr wrote: It's the optimization :) Without -O compilation took only a few seconds! Well, that explains it! Little attempt is made in the optimizer to make it compile faster if that would interfere with generating faster code.
Re: dmd 1.062 and 2.047 release
Brad Roberts wrote: On Tue, 15 Jun 2010, Walter Bright wrote: strtr wrote: It's the optimization :) Without -O compilation took only a few seconds! Well, that explains it! Little attempt is made in the optimizer to make it compile faster if that would interfere with generating faster code. Chances are that the changes to allow more inlining contribute to handing the optimizer more work to chew on too. You're very likely right.
D rpm packages for Linux
D rpm packages now available http://www.digitalmars.com/d/download.html thanks to Jordi Sayol.
D web site facelift
David Gileadi was kind enough to spend some time redesigning the look of the D web site. A preview of it is up on d-programming-language.org. This isn't about the content, just the look/style/feel. Comments welcome. Please don't put links to anything other than the front page yet, as the organization may change.
Re: D web site facelift
Walter Bright wrote: d-programming-language.org http://www.d-programming-language.org
Re: D web site facelift
Adam Ruppe wrote: The text is borderline illegible, due to poor contrast combined with a small text size. What browser are you using? In IE it renders well, and I'm picky about that sort of thing.
