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!
