Re: Patterns of Human Error - my presentation at the DC ACM
Nice slides, very simple and elegant. This reminds me of when I started with D. I found a lot of these 'details' unload quite some burden I had with C++ and made programming that much more enjoyable.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
David Nadlinger s...@klickverbot.at wrote in message
news:ihkub8$1ia4$1...@digitalmars.com...
On 1/24/11 10:20 PM, Nick Sabalausky wrote:
Does Git really not have real revision/changeset numbers?
[.]
Not that I've actually used DVCSes much yet, but my understanding is
that the same can be set of Hg and yet Hg handles revision/changeset
numbers just
fine. The nice things (plural) about those is that they're both readable
and
comparable.
Hg has no �real revision/changeset numbers� either - there is a
more-or-less-monotonic number assigned to the various changesets, but
it's only valid for a single, *local* checkout, using them e.g. in a NG
post would be a very wrong thing to do
(http://mercurial.selenic.com/wiki/RevisionNumber).
Even without really using DVCSes it always seemed clear to me that an
incremented number would be relative to a particular branch. So if you
specify what branch you're talking about (which could usually just be
assumed to be the main official one unless otherwise specified), shouldn't
that be enough?
Git supports a relative notation as well, which is what I personally want
to use most of the time anyway (e.g. HEAD^, master~4, something@{1 year
ago}, .).
Ah, so it *does* then? Great! Happen to have a link that explains it?
This covers most of it to see what's possible:
http://progit.org/book/ch6-1.html
You can customize git log with a format string, try this for example:
git log --pretty=format:%h - %an, %ar : %s %d
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote:
Lutger Blijdestijn lutger.blijdest...@gmail.com wrote in message
news:ihn21d$2esd$1...@digitalmars.com...
Nick Sabalausky wrote:
David Nadlinger s...@klickverbot.at wrote in message
news:ihkub8$1ia4$1...@digitalmars.com...
On 1/24/11 10:20 PM, Nick Sabalausky wrote:
Does Git really not have real revision/changeset numbers?
[.]
Not that I've actually used DVCSes much yet, but my understanding is
that the same can be set of Hg and yet Hg handles revision/changeset
numbers just
fine. The nice things (plural) about those is that they're both
readable
and
comparable.
Hg has no ?real revision/changeset numbers? either - there is a
more-or-less-monotonic number assigned to the various changesets, but
it's only valid for a single, *local* checkout, using them e.g. in a NG
post would be a very wrong thing to do
(http://mercurial.selenic.com/wiki/RevisionNumber).
Even without really using DVCSes it always seemed clear to me that an
incremented number would be relative to a particular branch. So if you
specify what branch you're talking about (which could usually just be
assumed to be the main official one unless otherwise specified),
shouldn't
that be enough?
Git supports a relative notation as well, which is what I personally
want
to use most of the time anyway (e.g. HEAD^, master~4, something@{1
year ago}, .).
Ah, so it *does* then? Great! Happen to have a link that explains it?
This covers most of it to see what's possible:
http://progit.org/book/ch6-1.html
You can customize git log with a format string, try this for example:
git log --pretty=format:%h - %an, %ar : %s %d
Ahh, that's not remotely what I was hoping it was. Everything is all
relative to the current version which means that *every* time you commit,
*every* changeset gets completely renamed (HEAD@{5} becomes HEAD@{6},
etc), and there doesn't appear to be any syntax to refer to the next
changeset (only the previous), which makes it barely useful at all. And
not only that, but they *dissapear* after a certain amount of time.
Browsing through http://hginit.com/index.html, it looks like with Hg,
everything works just as well as with SVN, the only difference being that
you need to remember to specify which repository you're talking about
whenever you give a number.
I see, you want a convenient name for a particular commit, is that it? But
even the hg revision number is discouraged to be used to talk with others,
this is from the manual:
It is a strictly local convenience identifier (...) Revision numbers
referring to changesets are very likely to be different in another copy of a
repository. Do not use them to talk about changesets with other people
When there is a lot of branching going on (even in a local repository) these
revisions numbers become useless and confusing. A unique identifier is much
more useful. You can't expect other people to piece together how the
revision number has come to be, that is extremely brittle.
Obviously I'm not saying DMD should have gone Hg, I'm just kinda shocked
by how horrid Git's approach is for referring to changesets. (Personally,
that alone would be enough to get me to use Hg instead of Git for my own
projects. Heck, I've become pretty much sold on the idea of DVCS, but
because of this I think I'd actually sooner use SVN for a new project than
Git.)
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky wrote: ... You can't expect other people to piece together how the revision number has come to be, that is extremely brittle. They don't need to piece it together because you can just say... ...which repository you're talking about. ...which repository you're talking about. ...which repository you're talking about. . . . . ...which repository you're talking about. . . . . . ok ok ok ok ok I get it. I spend some quality time with google and have found this: $ git describe --tags phobos-2.046-664-g938e1cc So phobos is at the 664th commit since 2.046 http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to- refer-to-commits/
Re: Texas LinuxFest 2011 call for papers now open
Andrei Alexandrescu wrote: http://www.texaslinuxfest.org/callforpapers/ One topic of interest is Open Source Programming Languages. If someone could explain to me the various subtle nuances of what an open source programming language is, I'll try to make a D-related submission and of course I recommend anyone else to do the same. Andrei This is a matter of perspective, I think these are the possibly interesting angles and issues for D: - availability and development of Open Source compilers (OSI compatible license) - cross-platform design, this extends beyond linux but is often a concern and goal in the Open Source world - development process of the language (and std lib) itself: here the community participation is important. For D it's an interesting (and ongoing) story to tell. - usefulness and place in the open source ecosystem: I believe D has a potential here as a serious alternative for both mono and java. Mono, the open source implementation of .net, has loads of potential patent issues and for this reason is not supported by some distro's. Java also has it's issues. Positioning D as a solution to those problems (rather than an alternative for C++ or dynamic languages) will please the crowd, for sure :) Interoperability with C is also important here.
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... You can never be sure with patents, as someone else in another thread already pointed out: it's virtually impossible to write a piece of software that doesn't infringe patents. Yes, it's like bugs: you can tell when you found one, but never know your software is free of it. (well, that is almost true) Of course, the situation is worse with Java (as seen in Oracle suing Google for using a Java-derivate in Android) and Mono (you never know if Microsoft will tolerate this forever. Even if they promised not to sue for current .net related patents, you never know about patents applying to features in future versions of .net). With D at least people still would have to find patents that are infringed - and even then the case isn't as clear as with Java/mono, where it's obvious that the Java/.net related patents are infringed. So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Technically that is right, but I find it a bit of an understatement because every non trival software project has potential issues. With .NET and Java you *know* you have patent issues, with D any potential patent issue is a tragic mistake that still has to be proven to exist. Those are not on the same scale, so I wouldn't use the term 'less trouble' You also have ownership to take into account, I would rather trust Walter Bright not using submarine patent traps than MS or Oracle :)
Re: Texas LinuxFest 2011 call for papers now open
Daniel Gibson wrote: ... So yes, the point that D may cause less trouble than Java/.net can be made, but you probably shouldn't claim that D doesn't infringe any patents, because you can't possibly know (nobody can, there are just too many software patents to check, even for big companies). Perhaps I should elaborate a bit. mono is simply out of the question in a large part of linux. Fedora for example, has D as a feature for its 14 release but doesn't support mono. Java is more complex, but if we take it out of the picture it leaves (some of) linux with C / C++ on the one hand and a lot of higher level dynamic languages on the other. In between are some more 'exotic' languages such as haskell. Perhaps I'm wrong, but I see a big void there where D can step in, mostly because of its set of features. In the non-open-source world, Java and .NET are already taking care of much of this void.
Re: std.xml2 candidate
Andrei Alexandrescu wrote: On 12/11/10 7:15 PM, Andrei Alexandrescu wrote: On 12/11/10 7:23 AM, Michael Rynn wrote: Availability of Updated xml parser for D2, organised very presumptively as std.xml2 [snip] Great! Do you plan to submit this to Phobos? One more thing - with XML parsers, I think Tango has definitely set the performance bar where it belongs. Any proposal for Phobos would need to meet it. Andrei That is considerable. A quick benchmark suggests that a lot of work is needed. If you take into account that tango's xml parser does less validation and that it is up to par with the fastest C++ parsers out there, I suggest lowering the bar a little bit at first. For example, outperforming libxml2.
Re: std.xml2 candidate
so wrote: If you take into account that tango's xml parser does less validation and that it is up to par with the fastest C++ parsers out there, I suggest lowering the bar a little bit at first. For example, outperforming libxml2. There is no reason a D code should perform worse than C++ if you are not using some high level constructs. When it comes to strings/slicing/template, you might actually get performance boost comparing to C++. The C++ parser mentioned here (RapidXML) depends heavily on these. I know, and tango's parser is proof of that. But it can take a lot of work getting to that level. Right now we have an xml library a lot of people don't want to use, has bugs and performs 60 times worse than tango's. Imho it's better to include it if performance is merely acceptable and see if it is possible to improve from there on.
Re: Build a D project is now easy
Leandro Lucarella wrote: Russel Winder, el 22 de noviembre a las 19:10 me escribiste: On Mon, 2010-11-22 at 16:41 +, Manfred_Nowak wrote: Russel Winder wrote: but it has come to the end of its useful life why. I ask because I just realized, that llvm still uses it. For really small systems compiled on a single platform, Make can still cut it. But being an external DSL, the separation of relationship specification notation and action notation, and especially the platform specific action notation lead to insurmountable problems. Go is trying to persevere with Make but the cracks show readily. Also Make shows the cracks for large projects, it doesn't really scale. False. Autotools was a brave attempt to make Make make big projects for Posix-compliant platforms. CMake is a bold attempt to ensure Make Automake is one of the biggest mistakes *ever*. handles things in a more platform independent way. Autotools is, I think also reaching the end of its useful life -- it was an immense bit of m4 hackery, and deserves respect, just as Make does. There is no point of comparison between Make and Autotools, Autotools is a huge hack. Make is limited in scope, but it does what it's supposed to do extremely well. The alternative to all this is to use an internal DSL, i.e. use a programming language directly. SCons and Waf plough this furrow -- to name but the main two in a C, C++, D, LaTeX context. SCons and Waf both suffer some serious issues, but they are the current market leaders for a more modern system. I tried quite a few build systems for a big project (cmake, waf, aap, scons, omake) and all had their own issues and specially limitations. Eventually I decided to learn Make seriously, wrote a good Makefile and never looked back... Make can be very hard to learn, specially because people tend to use it wrongly and there are very few good examples and tutorials/docs. PS: I'm really talking about GMake :) Wow, GMake is almost a full blown programming language! If you have one of those few good examples handy, would you mind sharing a link?
Re: d.vim and Fused
Russel Winder wrote: ... What this email is really about though is to ask: where is the best place to keep a permanent, i.e. not just on a mailing list, record of all the D editor support stuff. As well as Emacs and Vim there must be support for TextMate, Eclipse, NetBeans, IntelliJ IDEA, . . . all of which could be collated into a single place that people could go to, and which Google could index. I think this is the best place: http://prowiki.org/wiki4d/wiki.cgi?EditorSupport
Re: Utah Valley University teaches D (using TDPL)
bearophile wrote: Lutger Blijdestijn: Actually the unix convention is to give exit code 0 as an indicator of success, so there is feedback. It is very usable for scripting. But currently something like that is not present in the D unittest system. rdmd --main -unittest somemodule.d
Re: DDT 0.4.0 released (formerly Mmrnmhrm)
Looking pretty good so far!
Re: dmd 1.065 and 2.050 release
Walter Bright wrote: This is primarily a bug fix release. And relaxed purity rules. They rule!
Re: QtD is resumed
Max Samukha wrote: As there is interest in the project, we have decided to proceed. Stay tuned. I'm drinking one on this, cheers!
Re: New home page
Walter Bright wrote: Stephan Soller wrote: This is especially handy when doing a presentation about a programming language since you can use JavaScript to write a small syntax highlighter (the grammar in the D documentation was really handy for that). :) A javascript D syntax highlighter? Please post! This is a popular javascript syntax highlighter: http://alexgorbatchev.com/SyntaxHighlighter/ I've written a D plugin for it (its trivial and not completely correct): http://github.com/Lutger/d_utils/blob/master/shBrushD.js
Re: d bindings for enet
Stephan wrote: enet (http://enet.bespin.org/) is a thin network layer based on UDP. i post here in case anybody else finds it useful. is there any appropriate dsource project i can add these ? Stephan I believe this is the place, and anybody with a dsource account can commit here: http://www.dsource.org/projects/bindings
Re: QtD is suspended
Georg Wrede wrote: On 09/17/2010 01:01 AM, Lutger wrote: Max Samukha wrote: After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged. This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day. Having some experience in this, I really don't think other people can even begin to think what Max feels at this point. I could go on-and-on about this, but those who've never invested enough to break their back and then simply be met by folks who !believe! they have any way of understanding, I really think they should stay shut up. I take it this is directed at me. Look, it was a gut reaction. I don't understand why, but if anyone takes offense I'm sorry, I didn't want to provoke that.
Re: QtD is suspended
Max Samukha wrote: After a good amount of hesitation, we have decided to put the QtD project on hold. QtD has a potential to become a complete and effective development platform for D but it is not going to happen soon (unless people with harder hearts take it over). We have spent half of the day hunting yet another dmd bug-o-feature and that is the last straw. We offer our apologies to people who put their hope upon the project. Please come back in a year or two when the language has a stable compiler with the features fully specified, implemented and debugged. This is a loss, it must be frustrating for you spending so much time on it. Thank you anyway for the effort, it was quite exciting to see QtD almost come to be! I hope it will be continued some day.
Re: QtD is suspended
Is the most recent flavor of QtD the repositoy at bitbucket?
Re: bash completion for dmd and rdmd
Jordi Sayol wrote: Al 12/09/10 17:48, En/na Lutger ha escrit: It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or ~/.bash_profile: . d-completion.sh It will enable autocomplete for dmd and rdmd in bash. You may need to install the bash-completion package of your distro. Can I add it on the next deb/rpm packages? Of course! But please use this version: http://github.com/Lutger/d_utils I'll be happy to know if there are any errors, it's mostly taken from existing completion scripts. I don't think such a small script needs a license but I'll put one in if needed.
Re: D Concurrent GC
Sean Kelly wrote: Sean Kelly Wrote: Leandro Lucarella Wrote: Not quite ready for prime-time yet, but I think it's in a stage when it could be interesting anyway (at least for developers or people that want to experiment): http://llucax.com.ar/blog/blog/post/-1a4bdfba Nice work! I've gotten this to compile as the GC for druntime using D2 but have ran into a snag. Okay, all fixed. Porting the GC to D2 was more work than porting it to druntime specifically. There are still a few hacks in place to work around const issues and I faked the PointerMap stuff, but the GC seems to work just great. I'll have to find a reasonable performance test for comparison. Oh, I'll send you the modified code as well. Are you going to integrate it in druntime?
bash completion for dmd and rdmd
It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or ~/.bash_profile: . d-completion.sh It will enable autocomplete for dmd and rdmd in bash. You may need to install the bash-completion package of your distro.
Re: bash completion for dmd and rdmd
Andrei Alexandrescu wrote: On 9/12/10 10:48 CDT, Lutger wrote: It's ugly but it seems to work: http://dl.dropbox.com/u/6777848/d-completion.sh Put it in /etc/bash_completion.d/ or (preferably) invoke it from ~/.bashrc or ~/.bash_profile: .. d-completion.sh It will enable autocomplete for dmd and rdmd in bash. You may need to install the bash-completion package of your distro. Cool! This should be on D's website. Any zsh completion experts to provide something similar for zsh? Andrei Thanks. As per suggestion of Russel Winder I created a github account: http://github.com/Lutger/d_utils I've added completion for the linker. The script should be cleaned up though before putting it on the D website. I'll try to do it but I don't know bash very well, so it takes some time.
Re: dmd 1.063 and 2.048 release
Thanks everybody for the hard work, good release!
Re: This just in: authorless TDPL becomes collector's edition
Andrei Alexandrescu wrote: Due to a pretty odd mistake at the printer, the first 1000 copies of TDPL will not have the name of the author on their cover. (The name still appears on the back cover and the spine.) The history of printing is rife with rare printing mistakes that have become collector's editions. Preorder now to be among the first 1000 readers who get the authorless TDPL edition. Andrei Just got my authorless copy from the local bookstore, they have several more of those in stock at their little C++ corner :) I'm looking forward to reading it.
Re: dmd 1.062 and 2.047 release
Great, thank you! 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? There are some other modules without documentation like std.openrj and std.perf. Is there a page somewhere that documents their fate? I could only find this one: http://www.wikiservice.at/wiki4d/wiki.cgi?LanguageDevel
Re: dmd 1.062 and 2.047 release
Andrei Alexandrescu wrote: Lutger wrote: Great, thank you! 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. There are some other modules without documentation like std.openrj and std.perf. I removed std.openrj a while ago. Andrei std.openrj is still included is the src folder and in the repository. There is a commit on it 4 weeks ago, perhaps it should be deleted from svn? http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/openrj.d?rev=1519
Re: d2tags - converts DMD2's JSON output to Exuberant Ctags format
Andrei Alexandrescu wrote: MIURA Masahiro wrote: Hi, Being happy to see issue 3415 (broken JSON format) fixed, I have written a utility to convert DMD2's JSON output to Exuberent Ctags format. This enables you to tagjump in Vim and other editors/IDEs. It's just 150+ lines, thanks to D2's powerful string handling. Enjoy! http://github.com/Dubhead/d2tags usage: % dmd -Xftags.json foo.d % d2tags tags.json tags Very useful, and a beautiful example of D scripting. I wonder if this is of enough general utility to warrant inclusion within the D distribution, along with rdmd. Thoughts? Yes it's very useful. How about also including the source in the examples directory?
Re: GDB Patched
Robert Clipsham wrote: On 30/04/10 00:39, Jesse Phillips wrote: I'm a little surprised I didn't see this announced here, at least I can't find it. GDB has had the patch accepted! http://www.llucax.com.ar/blog/blog/post/06d99f3b It has been more than accepted, it is now in the source tree, and will be in the 7.2 release of GDB :D Bug: http://d.puremagic.com/issues/show_bug.cgi?id=3207 Commit: http://sourceware.org/git/?p=gdb.git;a=commit;h=870850ddab624f9d0111a4a0733cf7f5edf9bf91 Thats great!
Re: DDebber Request for Review
Jesse Phillips wrote: Walter Bright Wrote: 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 I know of dmd-installer, at least as a Windows installer. The README in rpm explains how to build a DEB? One thing DDebber is going for is building a package that could be accepted in the main Debian repo if the license didn't prevent this. I really want a libphobos which is needed when it becomes a shared library (could actually be in the official repositories when that happens :) If you have a script you are happy with and don't want to go the repository route, I'll see if I can get the Tango repository to distribute it once Tango is also packaged. You could try getting LDC with Tango into debian, there are no license problems with them.
Re: DDebber Request for Review
Jesse Phillips wrote: Lutger wrote: You could try getting LDC with Tango into debian, there are no license problems with them. My goal isn't exactly to get anything into the official repo. This is my first time really doing packaging and I'd like to figure out what is best for D. The conflicts between v1, v2, Phobos, and Tango coupled with the packages depending on one or another, or any combination... makes packaging very unclear. Yes and that's exactly why this is a fine project, though getting in an official repo will be extra valuable. I might attempt it for fedora when, if ever, I get to finish my current projects. Is there any userbase for D1 without Tango at the moment? I'd think there is only the combination D1 plus Tango with gdc/ldc/dmd, and D2 with dmd getting any use to speak of. dmd is not redistributable and ldc seems to be more actively developed, so that's why I suggested that combo.
Re: DMDScript now under Boost license
Thank you. Under svn there is both the gpl and boost license files, and no indication which is the right one. Could you remove gpl.txt to avoid confusion?
Re: dmd 1.057 and 2.041 release
Michal Minich wrote: On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote: I want to focus more on the fact that you are declaring the data after the slice as being no longer used. kind of assumeUnique ... assumeNoArrayReference ? I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.
Re: dmd 1.057 and 2.041 release
Thanks! A pleasant surprise to see interface contracts.
Re: dmd 1.056 and 2.040 release
This release makes me smile. Thank you so much Walter, and everybody who contributed too.
Re: why Ddbg is not updated anymore...
On 01/19/2010 09:32 PM, Matthias Pleh wrote: Stephan schrieb: I dunno if anyone knew this before but i wanted to give my kudos to a guy that did a lot for the D community by developing the still best debugger for the D Programming Language Ddbg (http://ddbg.mainia.de/releases.html) The question often came up why it is not updated anymore. Well the reason for this is that Jascha Wetzel the developer of Ddbg earns the big bucks now with his product Turbolence 4D (http://jawset.com/) and his company Jawset Visual Computing TURBULENCE.4D makes the most realistic and efficient methods in CG fluid dynamics available in standard software Well and recently his product got used in the new Bruce Willis movie Surrogates (http://chooseyoursurrogate.com/). All in all I whish him the best for the future and that he will never forget D when developing next cutting edge software. The downside is that Ddbg finally needs a new developer for the future to get updated. In the second part of the mentioned restrictions in the license.txt is written: * You may only redistribute the software unmodified, in the form and prepackaging it is available from the official website. It's seems as if redistributing of a changed version is not allowed. (But perhaps my english understanding is not good enought, I'm not an english native speaker :) So in this case, we need to write a debugger from scratch. greets matthias That's unfortunate, Jascha Wetzel has done some incredible things (not only ddbg). His code is really nice too, if ever someone would want to pick this up maybe he can be convinced to change the license.
Re: D compiler as part of GCC
On 01/18/2010 03:45 AM, Jerry Quinn wrote: [also posted to D.gnu] Hi, folks, I'm interested in creating a D front end for GCC that would be part of the GCC codebase. My feeling is that a GDC that is part of GCC distributions will likely have more life than one that must be updated whenever a new GCC release comes out. As with linux kernel in-tree drivers being kept up to date, an integrated GDC would tend to move forward as well. To do this though, copyright on the code must be assigned to the FSF. This means that even though the DMD front end sources are licensed under the GPL, they cannot be directly used to write this front end as the copyright is owned by DigitalMars. Everyone who contributes code must not look at the DMD compiler source code to avoid accidentally contributing code illegally. Therefore, this will be a completely new implementation of D. The obvious disadvantage of doing this is that it will be a slow process to get to a working D compiler. However, one advantage to the D world is firming up and validating the language specification so that the language is not defined by what the DMD compiler does. My personal desire is to implement (and track) the 2.0 language since I would like to see that feature set available through GCC. Second, by the time a working front end becomes part of GCC, the 2.0 language will likely be complete. One question I have (of many) is whether a different name should be used. If this is called GDC there will be some confusion with the current GDC. What thoughts do you all have? In general is there interest in this project, especially contributing to it? Thanks, Jerry I do not want to discourage such a great project, especially since I lack the skills myself to contribute. However I think helping either GDC or LDC with their D2 branches and getting them into a distro will be far more effective. Whatever you decide to embark on, wish you all the best!
Re: New vim d.vim syntax highlighting script
Thanks!
Re: dmd 1.054 and 2.038 release
Thanks a lot everybody. Also special thanks to Don for his increased involvement and stepping up to help with some serious bugfixing! It feels like D2 is becoming more solid and usable every release in spite of major features still being added. Happy new year! It will be an exciting one for D.
Re: SciD: the humble beginning
Chad J wrote: dsimcha wrote: ... The other option is to make sure everything is loosely coupled to the GUI lib so it can be easily swapped for another one. The downside is that this has some tradeoffs in terms of simplicity and probably performance that I don't think I want to make and is probably a classic example of overengineering. Is it really that hard to have the GUI libs in question just give you some pixels in memory or an opengl context? Then you could use your own highly optimized plot drawing routines instead of relying on the GUI lib to do this. I figured this kind of thing would be unbeatable for performance, unless the library ties your hands. If you are willing to do opengl (it's a bit more work) then I think that is a very good idea. Both QtD and GtkD should have good opengl interop, so you could at a later stage support both libraries.
Re: SciD: the humble beginning
Lutger wrote: Chad J wrote: dsimcha wrote: ... The other option is to make sure everything is loosely coupled to the GUI lib so it can be easily swapped for another one. The downside is that this has some tradeoffs in terms of simplicity and probably performance that I don't think I want to make and is probably a classic example of overengineering. Is it really that hard to have the GUI libs in question just give you some pixels in memory or an opengl context? Then you could use your own highly optimized plot drawing routines instead of relying on the GUI lib to do this. I figured this kind of thing would be unbeatable for performance, unless the library ties your hands. If you are willing to do opengl (it's a bit more work) then I think that is a very good idea. Both QtD and GtkD should have good opengl interop, so you could at a later stage support both libraries. On second thought, you will lose performance dramatically on systems that don't have a good opengl driver / graphics card.
Re: Metaprogramming in D : Some Real-world Examples
Bill Baxter wrote: ... This is almost just a preprocessor macro trick, except for this line: mixin( FoldStringsOf!visitMethodOf( [Sum, Product] ) ); The essence is to generate a bunch of methods from a list of names. I was thinking to include a similar example from the world of 3d graphics, which is generating all the swizzles of a vector* (got the idea from Tom S.). That's got the method generation from a list, but it also generates the list too. Interesting. I noticed it's also possible to pass a module as an alias and to things with it, but haven't come across an example of where that would be used. Modules are almost something in D, but just not yet. Another way is to have a swizz member template that lets you do v.swiz(zyx). That's arguably better in that you don't pay for it if you don't use it. But being able to generate all the methods with D is still kinda spiffy. * Most GPU languages (HLSL,glsl,Cg) have a swizzle syntax, such that for a float3 v; v.zyx gives you float3(v.z,v.y,v.x). And this works for all suffixes. v.xxx, v.xzy, etc. Also for different numbers of components. eg. v.xz is float2(v.x,v.z). --bb swizzling is a neat example! I also have code that actually implements the visitor interface with stubs that print, throw or assert, but it's kind of hairy.
Re: Code Poet, an IDE for D
Jeremie Pelletier wrote: watching wrote: what a pityful sate d is in. this probably shows, that you can't use d for anything serious and by the time you guys are through discussing things, people will be using something different for good. too bad I really don't think so, the very purpose of this IDE I'm developing is to make D easier to use and develop large scale projects with. The only thing still in the way of using D with graphical applications right now is the lack of proper bindings to cross-platform GUI toolkits for D2. Out of curiosity, did you consider GtkD and QtD? Have you thought about how to do plugins / extensions already? Of all the best software I'm using it seems a large part comes from the extensions. I wish you all the best with this project, great to see something started again on this front.
Re: DMD svn and contract inheritance
Walter Bright wrote: Jason House wrote: With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. The problem is, one doesn't know if it is a problem with the change or if it is a problem with the user code. To determine that requires working with and understanding the user code. It's just impractical for me to do that with a large base of code like that. But you don't have to take the stance that no regressions may occur (for this very reason). I think automated builds + tests can be useful in different ways: - the authors of the code can be notified and look at the problem. Some will care and help you spot bugs earlier or may fix their own code earlier. This is at no cost to you. Eventually, this task can perhaps be delegated completely? - when a lot of stuff breaks, it is an indicator at least. - while you may need a lot of investment to determine all problems, at least some category of problems you may recognize quickly.
Re: dmd 1.048 and 2.033 releases
Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance.
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hac8nb$26j...@digitalmars.com... Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update. Compiler now detects some cases of illegal null dereferencing when compiled with -O A bug-detection feature that's turned on with -O? I assume that's just a temporary situation and is related to either it currently being detected by the optimizer and the feature maybe being in a trial phase? Or maybe just a typo? ;) Somewhere in the huge thread(s) on the topic Walter mentioned the optimizer does (some of) the required flow analysis, so presumably it needs to run in order for this to work.
Re: Descent, now with Open Type Hierarchy
Just updated, this is such a great feature :) Since a couple of versions ago, Descent seems much more stable too, fortunately. You made my day, thanks so much!
Re: Descent generated documentation
*drools* Some more wishes: D2 support? Couple of minor suggestions for the aesthetics (this is a matter of taste too of course): - make the declarations stand out more, bold font or something. - all the non-comments stuff should be in a different, monospace font - parameters names in italic - name of the module as the title of the html page In general, I very much would love to see little javascript if at all, CSS for styling with use of div's (and CSS classes). This so that people could style it themselves easily (and contribute nice sheets?). Oh, is it possible to detect overloads? You could add links to them (like with the class hierarchy) or group them together. Could it be done across modules? Last detail: small message at the bottom saying it was generated with descent at date so and so. Right, I'll stop for now :)
Re: Descent generated documentation
Cool, can you do preconditions and class invariants too?
Re: dmd 1.046 and 2.031 releases
Thanks everybody!
Re: dmd 1.046 and 2.031 releases
bearophile wrote: ... D does introduce another operator, the :..case operator g. Unfortunately the brain of all people will see just .. as the operator there, and it has a different semantics there, it's a special case. I am not going to like this. I don't think that will happen. After all, many brains got used to [..) and [..], this is not that different. In the context of case statements, an inclusive range is more intuitive. std.string: deprecated std.string.find and std.string.find, replaced with std.string.indexOf; deprecated std.string.rfind and std.string.irfind, replaced with std.string.lastIndexOf; added flag CaseSensitive for indexOf and lastIndexOf; removed startsWith and endsWith because std.algorithm defines them; defined std.string.byDchar. Replacing the simple to read, and easy to understand names find and rfind with indexOf and lastIndexOf that are longer and also have upper case letters in the middle looks doesn't look like an improvement. indexOf and lastIndexOf are much more descriptive of what the function actually does, I think they are easier to understand.
Re: Diamond, a D Memory Debugger (and profiler) and thesis
Vladimir Panteleev wrote: On Fri, 03 Jul 2009 12:06:05 +0300, Nick B nick.barbal...@gmail.com wrote: Vladimir Panteleev wrote: On Mon, 22 Jun 2009 10:55:37 +0300, Extrawurst s...@extrawurst.org wrote: Sounds great, is it possible to read the aforementioned thesis too ? I've been undecided whether I should post it online, for the reason that it was written for a committee of Moldavian professors who had no clue what a garbage collector is (not to mention having heard of D), and were definitely not going to read my thesis (just listen to the 10-minute presentation)... Even though I did put some effort into it, it may have some inaccuracies. So please don't judge it too harshly :P Thesis: http://thecybershadow.net/d/Memory_Management_in_the_D_Programming_Language.pdf Presentation (PowerPoint 2007, sorry): http://thecybershadow.net/d/Presentation.pptx Vladimir I would just like to thank you posting your thesis. It was an interesting and enjoyable read. regards Nick B. I'm glad you liked it, I guess my effort didn't go to waste after all :) Surely not, I'm still reading it too. Don't forget that but a small percentage of readers will actually post feedback!
Re: ldc 0.9.1 released
Great news, happy to see x86_64 on the feature list :)
Re: ldc 0.9.1 released
Robert Clipsham wrote: ... I actually thought about giving this a try about a week ago. I managed to get all but one file to compile with the current version of the D2 front end (2.021 I believe)... Not bad considering my (lack of) C/C++ knowledge. If there's some interest for it I suppose I could give it another shot and try to merge the latest front end, it'd be a good chance for me to finally learn C/C++ (I made the delmistake/del decision to learn D first... I found it too awesome to bother learning the obviously inferior C/C++ :P). I'm interested, for sure.
Re: Taunting
Ary Borenszweig wrote: http://www.youtube.com/watch?v=rtYCFVPfx4M when is the next release, pretty please? :)
Re: Descent 0.5.5 released
Sweet, thank you!
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Walter Bright wrote: Tomas Lindquist Olsen wrote: I think it's a great idea, there's some decent arguments that they should have more general names, but I like the idea that you'd always know which group to look in for specific issues, even when we're at D4! I do have reservations about the idea, based on experience with all the Digital Mars C++ newsgroups. There are too many, making for rather thin traffic. It's tedious to check them all for new postings, which means that that doesn't happen, and new postings often languish as a result. The main D n.g. gets a lot of action, which feeds on itself. I'm reluctant to mess with success. Similar to what Knud Soerensen suggested: Rename .learn to .programming and .d to .design or .future. And while we're at it: merge .dwt .gnu .ide .debugger into .tools or .toolchain or something like that. That way you end up with even less newsgroups!
Re: Planet D is back
Thank you for doing this.
Re: Slide design
Walter Bright wrote: Sean Kelly wrote: For lectures I basically have a choice between two options: 1. Take notes and not remember a darn thing that was said. 2. Not take any notes and remember the lecture. Eh, I found that the physical act of taking notes tended to fix it in my brain. Furthermore, at Caltech there tended to be no textbook and no handouts, so you went by your notes. Exams were open-note, too. So taking good notes was indispensible. I have the same experience. Often I took notes but discarded them later. The act of writing things down helps to remember and focus on the important things, since you are forced to be selective. It takes a bit of practice to be able to listen attentively and write at the same time though. Some people just try to write everything down frantically even if they don't understand it - that just doesn't help.
Re: dmd 2.029 release
Russell Lewis wrote: ... Case in point: I have been bitten by this perhaps half a dozen times *already* porting older code. This code used to work fine: writefln(The value is: %d, myVar, . Do something!); ... I bet a lot of to-be-ported D code will have this bug, I know my code will. When you want to print a format string this way - last argument(s) simply appended, it saves you two characters typing. When something saves any characters typing and produces the same result, programmers will do that.
Re: dmd 2.029 release
Daniel Keep wrote: ... -Lars The best bet for 64-bit D executables at this point is probably LDC; dunno what the current state is, though. -- Daniel if you grep the dmd backend sources for x86_64, you'll get some results. Don't know what that means though, the source looks like magic to me!
Re: Descent 0.5.4 released
How wonderful, thank you VERY much! OT: I've found eclipse 3.4.x under 64-bit linux less than stable with descent, but the 3.5 stream release works pretty good so far.
Re: Descent 0.5.3 released
Thank you so much, I really appreciate this IDE. What would make me most happy, personally, is getting Descent to parse command line output from dmd and jump to errors in the source file. Next up the wishlist is actually building from Descent, but this is less important. Dsss support would be awesome too.
Re: DMD 1.037 and 2.020 releases
Great release, thank you!
