Re: D vs C++
This is certainly a personal preference, but I would add static typing to that list. On Sun, Dec 26, 2010 at 2:06 PM, Walter Bright wrote: > bearophile wrote: > >> One of the few advantages of D over Python is that in D you are able to >> implement efficient and custom data structures without leaving the D >> language >> itself :-) >> > > few? > > How about: > > 1. scope guard > 2. multithreaded programming (the GIL doesn't count) > 3. inline assembler > 4. immutability > 5. purity > 6. far faster performance > 7. RAII > 8. direct interface to C > 9. templates > 10. CTFE > 11. generative programming >
Re: thin heaps
> I think they'd be a good addition to std.container. > Why? What more do you need that std.container.BinaryHeap doesn't provide?
Re: Please vote on std.datetime
+1 for inclusion, including the unittests just the way they are. Why? Because I've been waiting for a decent datetime module for a while and this looks like one. There's no good reason not to include the unittests. Yes, there is an abundance of them. But there's _huge_ potential for small, off-by-one bugs in something like this, and I think maximum coverage, even if some of it overlaps, can only be a good thing. On Thu, Dec 9, 2010 at 8:40 PM, Jonathan M Davis wrote: > On Thursday 09 December 2010 16:26:13 Andrei Alexandrescu wrote: > > Jonathan M. Davis has diligently worked on his std.datetime proposal, > > and it has been through a few review cycles in this newsgroup. > > > > It's time to vote. Please vote for or against inclusion of datetime into > > Phobos, along with your reasons. > > Well, I'm obviously voting for inclusion. ;) > > I wrote it. I'm not about to claim that it's perfect, but overall I like it > and > think that it's quite good. Unfortunately, either most everyone likes it > and has > said nothing, or they (understandably) didn't want to read it. > > I would point out though, that as it stands, including std.datetime would > require including my time module as core.time (which has been discussed to > some > extent with Sean, since it was pretty much his idea in the first place that > some > level of integration should occur there) as well as including my unittests > module as something like std.unittests (which was reviewed here on some > level, > and has definitely been improved from its initial version, but hasn't > exactly had > overwhelming support). The unittest functions could be integrated privately > into > std.datetime, but I think that that would be a disservice to the community > at > large. > > Regardless, I'm obviously for including it. > > - Jonathan M Davis > > > P.S. The most recent code is here: http://is.gd/hYwOV >
Re: DMD2 .deb fails to install on Ubuntu 10.10 – j ust remove »shell«?
On Thu, Dec 9, 2010 at 12:01 AM, Russel Winder wrote: > On Wed, 2010-12-08 at 17:29 -0800, Walter Bright wrote: > > Walter Bright wrote: > > > Andrei Alexandrescu wrote: > > >> This seems pretty urgent. Walter? > > > > > > I asked Jordi, who prepares the .deb files. > > > > Should the binaries be installed on /usr/local/bin instead? > > No. The whole point of debs is that you have a managed /usr/bin where > all the binaries go. Clearly this means you have to have executable > names that are not the same as any other package in either Debian or > Ubuntu. Clearly, in general, this is impossible. However, people just > get on and do the impossible anyway. > > If /usr/lib is used, the same holds. > > Other stuff should be going in /usr/share/dmd and /usr/share/doc/dmd > which do not suffer the same naming issues, unless someone else is > distributing a dmd package. > > I can't use the debs at the moment as they are for i386, and I only deal > in amd64. As soon as amd64 debs are produced I will start using them > instead of having my lash-up install so as to use 32-bit materials on a > 64-bit system. > Ah but you can! sudo aptitude install gcc-multilib libc6-i386 lib6-dev-i386 sudo aptitude install ia32-libs sudo dpkg -i --force-architecture [dmdpackage] > > The project should consider building Ubuntu debs using Bazaar and > Launchpad via a DMD PPA. It would be good if gcd also used this route. > > Anthony Williams builds debs for Just::Thread that are targeted at > Ubuntu but also happen to work on Debian. > > -- > Russel. > > = > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:russel.win...@ekiga.net > 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder >
Re: Discussion about D on the gentoo forum
On Sat, Nov 27, 2010 at 8:11 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > > http://forums.gentoo.org/viewtopic-p-6498541.html?sid=f59057ee36c58c923cd13d4be3f839f2 > > > Andrei > Perhaps you could answer the OP's question as to "what happened to it"?
Re: One year of Go
> > Can you please explain when have you missed them? Because after writing > quite a bit of Go code, and talking with other people that has written even > more Go code, almost nobody has found this to be an issue. > This is such a crap argument, I don't even know how to counter. Perhaps instead of trolling the D mailing list (and reddit and HN), you should put that effort into fixing your [what I and many "other people" believe to be an] inherently broken pet language. On Fri, Nov 12, 2010 at 9:14 AM, Pillsy wrote: > uriel_follower wrote: > > > Pillsy Wrote: > [...] > > > At this point I'm mystified as to why language designers just keep > > > on making this same mistake by leaving support for generic > > > programming out of their statically typed languages. Java and C# > > > had to graft generics onto their languages after the fact; why > > > ignore that? > > > Can you please explain when have you missed them? > > I haven't even bothered trying Go because lacking support for generics is > so obviously the Wrong Thing[tm]. > [...] > > Specially now the new append() builtin has taken care of most of > > the remaining cases where generics might have been marginally > > useful. > > Wait, why did they need to introduce a *whole new builtin*? Why should this > have to be builtin *at all*? > [...] > > Because nobody ever reused any code in languages without > > generics! > > Re-using code in statically typed languages is harder if they don't have > generics. > > And after seeing people say, "Oh, yeah, you really don't need generics in > our language!" a few times only to sheepishly bolt them on a few years later > doesn't inspire much confidence this time around. > > Cheers, > Pillsy >
Re: duck!
On Sat, Oct 16, 2010 at 9:01 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > On 10/16/10 2:30 CDT, Christof Schardt wrote: > >> auto d = duck!Drawable(c); // awes >>> >> >> What about "as" ? >> >> auto d = as!Drawable(c); >> > > Nice too, and evokes "to". "to" was a success in spite of the fact that > it's difficult to talk about (e.g. "Could you use 'to'?" "To what?" etc). I > still prefer "duck" because it doesn't have this problem. > > > Speaking of which, it looks like std.conv is a good place to put duck in. > > > Andrei > > Hmm.. I was going to suggest /dev/null but I suppose that works too. If we have to have it, I would vote for "as" over "duck" simply because duck can be interpreted either a noun with only metaphorical relevance or as a verb with no relevance at all. On the other hand, "as" is simple and gets the point across.
Re: Halting problem (was: "in" everywhere)
On Sat, Oct 9, 2010 at 9:11 AM, Stewart Gordon wrote: > On 08/10/2010 00:39, Tomek Sowiński wrote: > > >> What's the halting problem? >> > > Basically, it's the challenge of determining algorithmically whether an > arbitrary algorithm given arbitrary input will eventually halt or carry on > running forever. > > The point is that the halting problem is known to be unsolvable. The > standard proof of this is as follows. Suppose the halt analyser algorithm > we seek exists. Call it WillHalt(Algorithm, Input). Then we can consider > WillHalt(Algorithm, Algorithm). > > Then we can define a new algorithm, LoopIfHaltsOnItself(Algorithm), defined > as > > if WillHalt(Algorithm, Algorithm) then >loop forever > else >return > > Now try to analyse the outcome of LoopIfHaltsOnItself(LoopIfHaltsOnItself). > > > Personally, I think it's a shame that the halting problem can't be solved. > If it could, we could use it to solve many mathematical problems that have > as it happens remained unsolved for centuries. > > Stewart. Or more poetically, No general procedure for bug checks succeeds. Now, I won’t just assert that, I’ll show where it leads: I will prove that although you might work till you drop, you cannot tell if computation will stop. For imagine we have a procedure called P that for specified input permits you to see whether specified source code, with all of its faults, defines a routine that eventually halts. You feed in your program, with suitable data, and P gets to work, and a little while later (in finite compute time) correctly infers whether infinite looping behavior occurs. If there will be no looping, then P prints out `Good.’ That means work on this input will halt, as it should. But if it detects an unstoppable loop, then P reports `Bad!’ — which means you’re in the soup. Well, the truth is that P cannot possibly be, because if you wrote it and gave it to me, I could use it to set up a logical bind that would shatter your reason and scramble your mind. Here’s the trick that I’ll use — and it’s simple to do. I’ll define a procedure, which I will call Q, that will use P’s predictions of halting success to stir up a terrible logical mess. For a specified program, say A, one supplies, the first step of this program called Q I devise is to find out from P what’s the right thing to say of the looping behavior of A run on A. If P’s answer is `Bad!’, Q will suddenly stop. But otherwise, Q will go back to the top, and start off again, looping endlessly back, till the universe dies and turns frozen and black. And this program called Q wouldn’t stay on the shelf; I would ask it to forecast its run on itself. When it reads its own source code, just what will it do? What’s the looping behavior of Q run on Q? If P warns of infinite loops, Q will quit; yet P is supposed to speak truly of it! And if Q’s going to quit, then P should say `Good’ — which makes Q start to loop! (P denied that it would.) No matter how P might perform, Q will scoop it: Q uses P’s output to make P look stupid. Whatever P says, it cannot predict Q: P is right when it’s wrong, and is false when it’s true! I’ve created a paradox, neat as can be — and simply by using your putative P. When you posited P you stepped into a snare; Your assumption has led you right into my lair. So where can this argument possibly go? I don’t have to tell you; I’m sure you must know. By reductio, there cannot possibly be a procedure that acts like the mythical P. You can never find general mechanical means for predicting the acts of computing machines. It’s something that cannot be done. So we users must find our own bugs. Our computers are losers! - Geoffrey K. Pullum
Re: "in" everywhere
2010/10/8 "Jérôme M. Berger" > Steven Schveighoffer wrote: > > On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke > > wrote: > > > >> On 10/7/2010 13:57, Andrei Alexandrescu wrote: > >>> On 10/7/10 14:40 CDT, bearophile wrote: > Another solution is just to accept O(n) as the worst complexity for > the "in" operator. I don't understand what's the problem in this. > >>> > >>> That means we'd have to define another operation, i.e. "quickIn" that > >>> has O(log n) bound. > >> > >> Why? > >> > >> I can't say I've ever cared about the big-O complexity of an operation. > > > > Then you don't understand how important it is. > > If big O complexity is so important, then why does everyone use > quicksort (which is O(n**2)) and not heap sort or merge sort (which > are O(n*log(n)))? > >Jerome > -- > mailto:jeber...@free.fr > http://jeberger.free.fr > Jabber: jeber...@jabber.fr > > Because on average quicksort is faster than heap sort, and uses much less space than merge sort. Also, trivial guards can be put in place to avoid running quicksort in a worst case (pre-sorted data) scenario.
Re: What would you rewrite in D?
Open SSL http://www.peereboom.us/assl/assl/html/openssl.html
Re: Fedora 14 will integrate D into the distribution
> Currently doing a marathon sprint to merge D2 frontend with 2.025 by the > end of > the month, or within the first week of next month, depending on how many > things > get broken in the process... > > Iain > The end of this month? As in about 30 hours from now? Because that would be really impressive.
Re: One more update on d-programming-language.org
Some tutorials/ nicely documented example programs on using the phobos library would be greatly appreciated. Reading through digitalmars.com/d/2.0/phobos/ requires too much filling-in-the-blanks on the reader's part. Another idea: The vala team made nice, very comprehensive side-by-side comparisons[1] between vala-java, and vala-c#, which makes the transition into vala very smooth and easy, wheras learning D is a bit like dumping a jigsaw puzzle on a table and not having the final picture to look at while you solve it. [1] http://live.gnome.org/Vala/ValaForJavaProgrammers http://live.gnome.org/Vala/ValaForCSharpProgrammers On Tue, Sep 14, 2010 at 10:01 AM, Andrei Alexandrescu < seewebsiteforem...@erdani.org> wrote: > > > I think we'll move forward with that one. I'll start working on the > content. Ideas for good tutorial examples? > > Andrei > >
[OT]: Google AI Challenge: starter package for D
On Friday (Sept. 10), Google/The University of Waterloo is going to open up registration for the next Google AI Challenge. Right now they are accepting "starter packages" for any language with a free compiler that can run on Ubuntu 8.04 (what their server runs), which means dmd is a candidate. I have already gotten a sort-of thumbs up from the contest organizer on getting them to host D as a language[1], and this evening I put together a starter package[2]. However, I am still very much a novice with D, so I was hoping some of you experts could take a look at the code and give some suggestions, particularly regarding performance enhancements. Each bot is allowed 1 second of calculation time per turn, and doing file IO haphazardly like I do is probably eating up a lot of that time. The files in question are the ones ending in .d; everything else just behind the scenes stuff that doesn't change. [1] http://ai-contest.com/forum/viewtopic.php?f=18&t=423 [2] http://bitbucket.org/Queue29/d_starter_package/src Seth Hoenig seth.a.hoe...@gmail.com
Re: Why C++ compiles slowly
On Thu, Aug 19, 2010 at 4:45 AM, Walter Bright wrote: > Walter Bright wrote: > >> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html >> >> I'll be doing a followup on why D compiles fast. >> > > On reddit: > > http://www.reddit.com/r/programming/comments/d2wwp/why_c_compiles_slow/ > Thanks for the free Karma, btw :P
Re: Does D support dynamically allocated multi-dimensional arrays?
Awesome, that worked. And thanks, I wasn't aware of d.learn. On Sun, Aug 15, 2010 at 9:33 PM, Jonathan M Davis wrote: > On Sunday 15 August 2010 19:20:12 Seth Hoenig wrote: > > What I really want is something like this: > > > > auto s = args[1]; > > auto t = args[2]; > > auto d = new int[s.length][t.length]; > > > > but the compiler complains with the error: Error: Integer constant > > expression expected instead of s.length > > > > So then I try to fudge it with something like: > > > > auto d = new int[][t.length]; > > d.length = s.length; > > > > But then accessing elements of d throws an exception: > > core.exception.rangeer...@lev(7): Range violation > > > > Soo.. how am I supposed to make a matrix when I don't know the dimensions > > at compile time? > > Oh, and questions like this are generally supposed to go on the D.Learn > list. > This list is more for discussing language features and the direction of the > language rather than asking and answering questions about how to use D. > > - Jonathan M Davis >
Does D support dynamically allocated multi-dimensional arrays?
What I really want is something like this: auto s = args[1]; auto t = args[2]; auto d = new int[s.length][t.length]; but the compiler complains with the error: Error: Integer constant expression expected instead of s.length So then I try to fudge it with something like: auto d = new int[][t.length]; d.length = s.length; But then accessing elements of d throws an exception: core.exception.rangeer...@lev(7): Range violation Soo.. how am I supposed to make a matrix when I don't know the dimensions at compile time?
