Re: DVM - D Version Manager
On 2011-01-25 23:30, Jérôme M. Berger wrote: Jacob Carlborg wrote: On 2011-01-25 20:33, Jérôme M. Berger wrote: Jacob Carlborg wrote: Platforms: currently only Posix Nitpick: it is more restricted than that. Platform is currently only posix *with bash shell*. A lot of people use other shells, including non-Bourne shells (most frequent are zsh, ksh and tcsh). Jerome Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? Well, for other Bourne shells (like zsh or ksh), it will probably mostly be a question of putting the initialization code in the right file (i.e. .zshrc or .kshrc). Other than that, unless you are doing something pretty fancy, the same code should work. For C-shells (like tcsh) the syntax is pretty different, so it will probably require more changes. However, it has been a while since I last used tcsh, so I cannot tell you how much work it would be. Jerome Ok. -- /Jacob Carlborg
Re: DVM - D Version Manager
On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
== Repost the article of Kagamin (s...@here.lot) == Posted at 2011/01/26 07:31 to digitalmars.D.announce Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier. And I use git to download the source from github.com for druntime. But I found that in it subdirectory import, there is only contain std and object.di, missed the core subdirectory for druntime. Why? Or, the core subdirectory exists on the github.com, but we can no see it? or there have some other way except git to download it? waiting for kindly help. Best regards David.
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 15:10:08 +0200, David Wang osx.da...@live.com wrote: And I use git to download the source from github.com for druntime. But I found that in it subdirectory import, there is only contain std and object.di, missed the core subdirectory for druntime. Why? Or, the core subdirectory exists on the github.com, but we can no see it? or there have some other way except git to download it? waiting for kindly help. Best regards David. The source code of druntime is under the src/core directory[1]. The .di files in the import directory are generated automatically during the build[2]. [1]: https://github.com/D-Programming-Language/druntime/tree/master/src/core [2]: https://github.com/D-Programming-Language/druntime/blob/master/win32.mak#L361 -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: DVM - D Version Manager
On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. I typically find /bin/sh features to be enough for implementing most scripts. A good reference (if you don't have it) is Unix in a nutshell, probably my most used textbook. -Steve
Re: DVM - D Version Manager
On Wed, 2011-01-26 at 08:58 -0500, Steven Schveighoffer wrote: [ . . . ] FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. For some definition of usually. On Debian and Ubuntu /bin/sh is a symbolic link to dash not bash. I typically find /bin/sh features to be enough for implementing most scripts. And the only guaranteed portable script -- assuming Windows without Cygwin or MSYS is excluded ! [ . . . ] -- 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 signature.asc Description: This is a digitally signed message part
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. A little example: today I commited changeset 35912, and 35780 - 10 day ago. Try to recall these random-looking numbers after reading a couple of posts in this NG.
Re: DVM - D Version Manager
Steven Schveighoffer Wrote: On my ubuntu system too -- to my surprise ;) It is a new thing they did, about a release or two ago. The reason was because /bin/sh pointed to bash and _did not_ adhere to the sh standard.
Re: DVM - D Version Manager
On 2011-01-26, Jesse Phillips jessekphillip...@gmail.com wrote: Steven Schveighoffer Wrote: On my ubuntu system too -- to my surprise ;) It is a new thing they did, about a release or two ago. The reason was because /bin/sh pointed to bash and _did not_ adhere to the sh standard. It was a system speed enhancement. Much of the bootup speed gain was due to switching to dash. bash is slow. bash adhere's to sh standards is just fine except that it won't flag extensions, so you can still end up with bashisms in your shell script. I've never had any issues w/bash. I write shell scripts that run in bash2, bash3, bash4, ash, dash, ksh88, ksh93, mksh, SunOS sh, Tru64 sh, AIX sh, HP-UX sh.
Re: DVM - D Version Manager
Jacob Carlborg wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. You cannot. You need to modify the environment for the current shell, which is the shell that the user is currently using (no matter what else may or may not be installed on the system). This has two consequences: - You need to have some code that is run when the shell starts (i.e. from .bashrc, .zshrc or .kshrc). That code will define the proper aliases and/or functions (at the time being, this is mostly the dvm function in dvm.sh (*)). This can be accomplished by having a different version of this file for each shell; - You need to generate the contents of $dvm_result_path in a format that the shell will understand. The easiest way to do that is probably to define a few extra functions in dvm.sh to enable setting environment variables in a portable way and handle additional requirements (like builtin hash -r which is definitely a bash-ism). Then generate the $dvm_result_path using these functions instead of the normal shell syntax. Jerome (*) BTW, I hope you do not add the full contents of dvm.sh nor a source dvm.sh in .bashrc the way it is now. Otherwise, a misconfiguration may prevent the user from starting a shell! -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Kagamin s...@here.lot wrote in message news:ihpjji$115f$1...@digitalmars.com... Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. A little example: today I commited changeset 35912, and 35780 - 10 day ago. Try to recall these random-looking numbers after reading a couple of posts in this NG. 1. That's obviously a *lot* easier than 9f4e5ac4f0a3 and 13cf8da225ce 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes.
Re: DVM - D Version Manager
On Wed, 26 Jan 2011 15:24:56 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: On 2011-01-25 23:59, Jesse Phillips wrote: Jacob Carlborg Wrote: Yeah, I guess you're right, didn't think there were a lot people who used other shells. Since I almost know nothing about shell scripting and even less about non-bourne shells, will it be possible to port to other shells? How much do they differ? -- /Jacob Carlborg To add to Lutger's message. I believe it is sh that is required by all Posix systems, or at least an equivalent. Similarly I think vi is also a requirement. In all likelyhood you probably used a Bash specific feature, but usually everyone has bash even if they use zsh... Though Ubuntu/Debian has started pointing /bin/sh to dash which is complaint with posix... Ok. I'll see I can use only sh. FWIW, /bin/sh is usually a symlink to bash, and it makes bash behave like the original Bourne Shell. /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. Yes, it should limit you to /bin/sh supported commands I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec export = supported, but has a more limited syntax than bash source = supported via . builtin hash = supported rm = command (shell independent) exit = supported exec = supported -Steve
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Kagamin s...@here.lot wrote in message news:ihp46m$b3$1...@digitalmars.com... Nick Sabalausky Wrote: official public repo: r184 official public repo: r185 ...etc. Versus: 9f4e5ac4f0a3 13cf8da225ce ...etc. I don't know about other people, but I find the former to be far more readable, far more descriptive, and actually possible to reason about. Sure, the latter can be copy-pasted and it still refers to the same changeset, but other then that it's meaningless gibberish. LOL, this meaningless gibberish is usually called a unique identifier. I don't care what it's called. *Both* of the above examples are obviously unique. Repo name + revision number *does* uniquey identify one and only one changeset. Are you deliberately missing that point?
Re: DVM - D Version Manager
Jacob Carlborg d...@me.com wrote in message news:ihq02n$28ki$1...@digitalmars.com... On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborg d...@me.com wrote: I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec Can't all (or most) of that be done in straight D?
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, and then criticizing Git co. for being horrid because they don't use your idea. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable.
Re: DVM - D Version Manager
On 2011-01-26 21:53, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message news:ihq02n$28ki$1...@digitalmars.com... On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, Jacob Carlborgd...@me.com wrote: I typically find /bin/sh features to be enough for implementing most scripts. I have no idea. I need to be able use the following commands/functions: export, source, builtin hash, rm, echo, exit, exec Can't all (or most) of that be done in straight D? It all comes done to one thing, the source function. If you launch an application in a shell that application can't set environment variables that will be available to the shell when the application exits. So instead I have most of the application written in D with a bash function that wraps the application. It works like this: 1. The function calls the D application 2. The D application performs all it needs to and writes a shell script to a file 3. The bash function calls source with this file as a parameter -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky a@a.a wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. I don't see how merging would cause a problem. A merge is a new commit, so it would get the next new revision number just like any other new commit would. Yes, but the commit numbers lose any meaning beyond the order in which the commits are added to the repository. That's barely useful, except when you know they're part of the same linear development history. And from what people have been saying, rebasing is only kosher on private repos so any little bit of awkwardness in there woudn't be a big deal (and I'm not sure how awkward it would be anyway since if if you're shuffling history around you'd *expect* the revision numbers to change since that's exactly what you're doing anyway). I meant non-destructive rebasing (not rewriting history), for example when backporting a feature, or when applying a feature branch on top of the latest master. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? They can't be ordered by time of authorship, for certain. Official is technically meaningless in a DVCS, because no repository is holy by design (otherwise it wouldn't be really distributed). If the maintainer of a repository becomes MIA, anyone can take over without any problems. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable. Then a clone of a clone of a clone of a clone needs four clone numbers, plus a revision number. It'd look something like 5:1:2:1:1056. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!!
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxqfimjtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky a@a.a wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky a@a.a wrote: 2. 35912 and 35780 are obviously related to each other in a certain way. I can tell just buy glancing that 35912 is a little over 100 commits after 35780. And I can immediately tell that they're both *far* newer than, say, 243. And far older than, say, 54928. Try doing that with hashes. None of these assertions hold in a DVCS repository. Merging in or rebasing an old branch ruins everything. I don't see how merging would cause a problem. A merge is a new commit, so it would get the next new revision number just like any other new commit would. Yes, but the commit numbers lose any meaning beyond the order in which the commits are added to the repository. That's barely useful, except when you know they're part of the same linear development history. It may not as meaningful as an SVN repo that never does any branching. But it's still much more meaningful than a hash. And from what people have been saying, rebasing is only kosher on private repos so any little bit of awkwardness in there woudn't be a big deal (and I'm not sure how awkward it would be anyway since if if you're shuffling history around you'd *expect* the revision numbers to change since that's exactly what you're doing anyway). I meant non-destructive rebasing (not rewriting history), for example when backporting a feature, or when applying a feature branch on top of the latest master. I guess I still don't see the problem there. It's still a new change that wasn't there before, hence a newly incremented revision number. And if it wants to add some meta-data referring to where it was copied over from, then ok.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxqmbpftuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? Why wouldn't it be? It didn't exist in that branch befoe, and then it was added to that branch. Feature X was introduced in Version 2.31 and didn't exist in the 1.x line. But then Feature X was backported to the 1.x line at time Y / revision Y, which was right after we fixed 1.x's bug A and right before we fixed 1.x's bug B. What's wrong with that? Seems perfectly sensible to me.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. Personally, I'm not about to claim that git does everything the best way possible, but I find it much more pleasant to deal with than svn. Other distributed VC systems may be better. There may be a better way that hasn't been found yet. I don't know. But I _do_ find git to be a major improvement over svn. - Jonathan M Davis
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.974.1296080574.4748.digitalmars-d-annou...@puremagic.com... On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Heh, fair enough :) Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. I tend to be really bothered by steps backwards that I don't see as being necessary. Seems to be a common theme with me.
Re: DVM - D Version Manager
On 2011-01-26 15:24:56 -0500, Jacob Carlborg d...@me.com said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Mercurial gives every revision two numbers: changeset: This field has the format of a number, followed by a colon, followed by a hexadecimal (or hex) string. These are identifiers for the changeset. The hex string is a unique identifier: the same hex string will always refer to the same changeset in every copy of this repository. The number is shorter and easier to type than the hex string, but it isn't unique: the same number in two different clones of a repository may identify different changesets. example-- changeset: 0:0a04b987be5a http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html -- see section: A Tour Through History Is that the kind of thing you're wanting? --bb On Wed, Jan 26, 2011 at 2:37 PM, Nick Sabalausky a@a.a wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.974.1296080574.4748.digitalmars-d-annou...@puremagic.com... On Wednesday, January 26, 2011 13:54:04 Nick Sabalausky wrote: Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky a@a.a wrote: Are you deliberately missing that point? I think everyone's just annoyed how you're fiercely defending an idea that has a single advantage (terseness - I consider hashes unique in practice), but a whole slew of disadvantages, Terseness is not at all the only advantage. As I've said before, you can reason about them, compare them, and get a general idea of where they are in the history. I don't think merging or changing the past conflict with that. And I'm really not seeing any non-trivial disadvantages. and then criticizing Git co. for being horrid because they don't use your idea. What? Are you actually trying to claim that defending/promoting one's own idea when another idea exists is a *bad* thing? Seriously? If we're going to go that absurd route, I can just make up the claim people are ganging up on me for having an idea that just happens to be different from Git's world-view. If Git does something one way then that *must* be the best way, right? Anything else is obviously just heresy, right? Bring on the stakes and torches, we're going to Salem!! LOL. I think that part of what it comes down to is that you're making a big deal out of what other people don't consider to be a big deal at all. Heh, fair enough :) Personally, I don't care much about the revision number. Having incrementally increasing ones might be nice, but if you don't have them, oh well. Obviously, you feel much more strongly about it. I tend to be really bothered by steps backwards that I don't see as being necessary. Seems to be a common theme with me.
Re: const/immutable member functions
foobar Wrote:
This problem happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams - outputParams { body }
ReturnType funcAttributes funcName(params) { body }
BTW the problem is in separation of function attributes from return type
attributes. I'm afraid, your example doesn't solve it.
Re: const/immutable member functions
On 01/26/2011 11:02 AM, Kagamin wrote:
This problem happens because D belongs to the C-family of languages which
puts the return type_before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams - outputParams { body }
ReturnType funcAttributes funcName(params) { body }
So what?
BTW the problem is in separation of function attributes from return type
attributes. I'm afraid, your example doesn't solve it.
??? what do you /actually/ mean?
attribute funcName inputParams - attribute outputParams { body }
Denis
--
_
vita es estrany
spir.wikidot.com
(OCa)ML for Trading [OT]
This post is OT, yet I think knowing why and how other languages are used is not bad for D developers and users. The Jane Street programmers write software for trading. Originally they have used Excel and VisualBasic, then have tried C# and failed (too verbose and complex, they say). They have found OCaML a good language for their purposes. They don't need a system language, so maybe D is not fit for them. They need a language that's safe (because they are managing large amounts of money), that allows to write very fast programs (because today trading software is meant to work very quickly. OCaML programs are usually no more than 1.5-3 times slower than C ones), and such safety needs to be kept despite very frequent changes in lot of code, as commercial situations keep shifting all the time. OCaML has many disadvantages they recognize and explain, but they have appreciated OCaML because of: - Its readability and its terseness and because it allows to avoid duplicate code. - Immutability on default most of the times (but there is some mutability too when necessary). - Pattern Matching, because many programs of their program perform case analysis. For them an important feature of OCaML pattern matching is that it forces at compile-time the programmer to handle all possible cases. This is very useful to keep the code correct as other parts of the program change quickly in time. - Labeled Arguments, because they make the code safer and more readable (this feature is near the top of my desired enhancements for future D). - Polymorphic Variants - Modularity - Phantom Types (http://en.wikipedia.org/wiki/Generalized_algebraic_data_type ). But above many other things they appreciate a lot the strict type system of OCaML that often allows to make illegal states unrepresentable (this is somewhat related to the idea of typestates). The video on Vimeo shows this too. Videos and articles: http://vimeo.com/14313378 http://www.janestcapital.com/technology/articles.php http://www.janestreetcapital.com/minsky_weeks-jfp_18.pdf http://www.janestcapital.com/yaron_minsky-cufp_2006.pdf Bye, bearophile
More Phobos testing
Now and then I try to use the std.algorithm/std.range parts of Phobos2 to see
how they are going and developing.
Here I have found Python3 code to compute the Pascal triangle:
http://code.activestate.com/recipes/577542-pascals-triangle/
---
Code adapted for Python2:
def pascal_triangle(n):
r = [[1]]
for _ in xrange(n - 1):
r.append(map(sum, zip([0]+r[-1], r[-1]+[0])))
return r
print pascal_triangle(5)
---
A similar algorithm translated to D2:
import std.array, std.stdio, std.algorithm, std.range;
auto pascalTriangle(int n) {
auto r = [[1]];
foreach (_; 0 .. n-1)
r ~= array(map!q{a[0] + a[1]}(zip([0]~r[$-1], r[$-1]~[0])));
return r;
}
void main() {
writeln(pascalTriangle(5));
}
---
Some notes on the D2 version:
1) In Python I am used to think of higher order functions like map, filter, and
zip as similar things. But in Phobos zip is in std.range while map is in
std.algorithm. I think this different placement is bad.
---
2) The Python version performs a sum() on tuples. But in D2 tuples, even ones
that have an uniform type, aren't iterable, this doesn't work:
import std.stdio, std.typecons;
void main() {
auto t1 = tuple(1, 2, 3, 4);
foreach (x; t1)
writeln(x);
}
Once tuples of uniform type are iterable, and sum()
(http://d.puremagic.com/issues/show_bug.cgi?id=4725 ) is implemented, the
middle line of code becomes simpler to read:
r ~= array(map!sum(zip([0]~r[$-1], r[$-1]~[0])));
I am aware that this works, but this is static foreach, so this is something
different:
foreach (x; t.tupleof)
This is closer to what I'm asking for, but it's not good enough yet:
foreach (x; [t.tupleof])
I have added an enhancement request on this:
http://d.puremagic.com/issues/show_bug.cgi?id=5489
---
3) I like API orthogonality because it allows you to write code like this, that
creates a linked list instead of an array out of the lazy map iterable:
linkedList(map!(...)(...))
But in my Python3 and D2 code I write often enough:
array(map!(...)(...))
So I may suggest an amap() the returns an array, it helps remove some
parenthesys clutter:
r ~= amap!q{a[0] + a[1]}(zip([0]~r[$-1], r[$-1]~[0]));
r ~= amap!sum(zip([0] ~ r[$-1], r[$-1] ~ [0]));
---
4) In the Python2 version if I print using the pretty print module:
from pprint import pprint
pprint(pascal_triangle(5), width=20)
The triangle gets visualized like this:
[[1],
[1, 1],
[1, 2, 1],
[1, 3, 3, 1],
[1, 4, 6, 4, 1]]
A function like pprint() will be useful in std.string of Phobos2 too, to give a
more readable printing. It's useful to print 2D arrays, arrays of dicts, etc,
in a more readable way.
Bye,
bearophile
destructor order
Hi! I've been trying out D recently but I'm a little confused about the order
in which destructors are called:
class A {
this() { writeln(ctor); }
~this() { writeln(dtor); }
static this() { writeln(static ctor); }
static ~this() { writeln(static dtor); }
}
void main() {
auto a = new A;
}
This will output:
static ctor
ctor
static dtor
dtor
I would have thought that the static destructor should be the last one (in case
there are static dependencies). Have I missed something?
/Albin
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Walter Bright Wrote: Dmitry Olshansky wrote: Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com. Any news here?
Re: destructor order
On Wed, 26 Jan 2011 10:53:29 -0500, Albin Breen abr...@ea.com wrote:
Steven Schveighoffer Wrote:
See here: http://www.digitalmars.com/d/2.0/class.html#destructors
The garbage collector is not guaranteed to run the destructor for all
unreferenced objects. Furthermore, the order in which the garbage
collector calls destructors for unreference objects is not specified.
This
means that when the garbage collector calls a destructor for an object
of
a class that has members that are references to garbage collected
objects,
those references may no longer be valid. This means that destructors
cannot reference sub objects.
Thanks! This means that the GC cannot be trusted to call destructors. I
interpret that as class destructors must be called manually.
Furthermore, The D Programming Language book states that: ...there is
no delete operator. (D used to have a delete operator, but it was depre-
cated.) so you can't use that either.
In other words you are left with:
clear(a);
to manually call the destructor, which will also call the constructor
again (this time with no parameters), and possibly (but not certainly)
the destructor once more.
To be able to use clear() you will have to enforce RAII using structs
(not garbage collected) or finally{} or scope constructs all the way
from main in parallel with all your garbage collected code.
That is a misdesign in clear. It should destroy an object and not
initialize it again. Furthermore, the destructor should only be called
once.
Andrei agreed to make that change, but it hasn't gone in yet.
-Steve
Re: destructor order
On Wed, 26 Jan 2011 11:09:45 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I think I glanced over a recent svn commit that fixed this, though I'm not sure. No, it hasn't been fixed. The fix is *really* simple, just have clear call rt_finalize (as Sean pointed out on the mailing list) -Steve
Re: More Phobos testing
On 01/26/2011 01:56 PM, bearophile wrote:
Now and then I try to use the std.algorithm/std.range parts of Phobos2 to see
how they are going and developing.
Here I have found Python3 code to compute the Pascal triangle:
[...]
Some notes on the D2 version:
1) In Python I am used to think of higher order functions like map, filter, and
zip as similar things. But in Phobos zip is in std.range while map is in
std.algorithm. I think this different placement is bad.
Why? zip is imo clearly a sequential function; belongs where it is.
An alternative may be to have a more type-oriented organisation of Phobos:
then, all algorithms oerating on ranges (many) would be placed in std.range.
4) In the Python2 version if I print using the pretty print module:
from pprint import pprint
pprint(pascal_triangle(5), width=20)
The triangle gets visualized like this:
[[1],
[1, 1],
[1, 2, 1],
[1, 3, 3, 1],
[1, 4, 6, 4, 1]]
A function like pprint() will be useful in std.string of Phobos2 too, to give a
more readable printing. It's useful to print 2D arrays, arrays of dicts, etc,
in a more readable way.
Agreed. I very often write and use tree-like output.
As an alternative, I would even like a recursive treeView func/method on all
aggregate types (arrays, AAs, strucs classes). Producing eg:
aPoint:
tag: foo
color:
r: 11
g: 22
b: 33
position:
x: 1
y: 2
with optional separators ',' delimitors () [] {}.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: destructor order
On Wed, 26 Jan 2011 12:26:22 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/26/11 10:17 AM, Steven Schveighoffer wrote:
On Wed, 26 Jan 2011 11:09:45 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I think I glanced over a recent svn commit that fixed this, though I'm
not sure.
No, it hasn't been fixed.
The fix is *really* simple, just have clear call rt_finalize (as Sean
pointed out on the mailing list)
-Steve
Steve, if you could point out what I need to do I'll be glad to do it
right now. Better yet, feel free to try your hand at a git commit. It's
fun!
*sweats nervously* I don't know, I'd like to read about how git works
before doing a commit. I don't really understand it at all, I had the
same problem with subversion when I started using it.
The fix is really easy, just change clear to this:
void clear(T)(T obj) if (is(T == class))
{
rt_finalize(cast(void*)obj);
}
Here is the body of the current clear:
if (!obj) return;
auto ci = obj.classinfo;
auto defaultCtor =
cast(void function(Object)) ci.defaultConstructor;
version(none) // enforce isn't available in druntime
_enforce(defaultCtor || (ci.flags 8) == 0);
immutable size = ci.init.length;
auto ci2 = ci;
do
{
auto dtor = cast(void function(Object))ci2.destructor;
if (dtor)
dtor(obj);
ci2 = ci2.base;
} while (ci2)
auto buf = (cast(void*) obj)[0 .. size];
buf[] = ci.init;
if (defaultCtor)
defaultCtor(obj);
And the body of rt_finalize
if (p) // not necessary if called from gc
{
ClassInfo** pc = cast(ClassInfo**)p;
if (*pc)
{
ClassInfo c = **pc;
byte[] w = c.init;
try
{
if (det || collectHandler is null ||
collectHandler(cast(Object)p))
{
do
{
if (c.destructor)
{
fp_t fp = cast(fp_t)c.destructor;
(*fp)(cast(Object)p); // call destructor
}
c = c.base;
} while (c);
}
if ((cast(void**)p)[1]) // if monitor is not null
_d_monitordelete(cast(Object)p, det);
(cast(byte*) p)[0 .. w.length] = w[];
}
catch (Throwable e)
{
onFinalizeError(**pc, e);
}
finally
{
*pc = null; // zero vptr
}
}
}
Note the eerie similarities :)
-Steve
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Trass3r wrote: Walter Bright Wrote: Dmitry Olshansky wrote: Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com. Any news here? No, I have not heard anything.
Re: destructor order
On Jan 26, 2011, at 4:55 AM, Albin Breen wrote:
Hi! I've been trying out D recently but I'm a little confused about the order
in which destructors are called:
class A {
this() { writeln(ctor); }
~this() { writeln(dtor); }
static this() { writeln(static ctor); }
static ~this() { writeln(static dtor); }
}
void main() {
auto a = new A;
}
This will output:
static ctor
ctor
static dtor
dtor
I would have thought that the static destructor should be the last one (in
case there are static dependencies). Have I missed something?
The static dtors are run when main exits and then the GC terminates, which may
trigger a final collection. In this case, the last dtor is when this
collection occurs.
Re: destructor order
On Wednesday, January 26, 2011 07:53:29 Albin Breen wrote:
Steven Schveighoffer Wrote:
See here: http://www.digitalmars.com/d/2.0/class.html#destructors
The garbage collector is not guaranteed to run the destructor for all
unreferenced objects. Furthermore, the order in which the garbage
collector calls destructors for unreference objects is not specified.
This means that when the garbage collector calls a destructor for an
object of a class that has members that are references to garbage
collected objects, those references may no longer be valid. This means
that destructors cannot reference sub objects.
Thanks! This means that the GC cannot be trusted to call destructors. I
interpret that as class destructors must be called manually.
Furthermore, The D Programming Language book states that: ...there is no
delete operator. (D used to have a delete operator, but it was depre-
cated.) so you can't use that either.
In other words you are left with:
clear(a);
to manually call the destructor, which will also call the constructor again
(this time with no parameters), and possibly (but not certainly) the
destructor once more.
To be able to use clear() you will have to enforce RAII using structs (not
garbage collected) or finally{} or scope constructs all the way from main
in parallel with all your garbage collected code.
All in all, if class destructors cannot be guaranteed to execute by other
means than the manual approach then should they be considered a liability?
In Phobos std.socket a destructor is used to close() the socket.
Personally, I don't think that using class destructors is currently a good
idea.
Certainly, if you _need_ the destructor to run, then you probably need to
rethink your design, since there's no guarantee that it's going to run. You can
call clear(), but relying on your code doing that in the general case seems
like
a bad idea. Already, class destructors can't deal with other GC-allocated
objects, so they're restricted to cleaning up other types of resources. If
anything, I question that classes should even _have_ destructors. For structs,
it makes great sense, but for classes... not so much. At best, they seem
useable
for stuff like file descriptors where you'd like them to be cleaned up when the
object is destroyed if you forgot to do so by calling the appropriate close
function or whatnot. But generally, it would be a bug in your code if you
didn't
release the file descriptor yourself (via the close function or whatever)
So, I'd argue that in the general case, you shouldn't be using class
destructors. If your object really needs a destructor, then perhaps it should
be
a struct (on the stack, since structs on the heap _never_ get their destructors
called IIRC).
- Jonathan M Davis
Is D still alive?
Dear D community, My name is Fabian and I used to code C++ and Delphi. But a few month ago I've got a book about D as a present. All in all D sounds very interesting ... but - the big but - is D still alive? Are there usable and stable GUI-Toolkits which are actually under development? Are there any continued database projects? So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's to expensive - so: is D as precious as its pretend to be? Greetings Fabian PS: I hope you can understand my bad English.
Re: Is D still alive?
On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Dear D community, My name is Fabian and I used to code C++ and Delphi. But a few month ago I've got a book about D as a present. All in all D sounds very interesting ... but - the big but - is D still alive? Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1). Are there usable and stable GUI-Toolkits which are actually under development? I don't have personal experience with any of the current GUI projects, but from what I've read, many of them are usable. Whether they are actively developed, I'm not sure. See many of them here: http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's to expensive - so: is D as precious as its pretend to be? I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. -Steve
Re: Is D still alive?
On Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Dear D community, My name is Fabian and I used to code C++ and Delphi. But a few month ago I've got a book about D as a present. All in all D sounds very interesting ... but - the big but - is D still alive? Very much so. D2 is being actively developed. D1 is not, but Tango is being actively developed (which works with D1). I should clarify, D1 is not getting any new features, but it is getting bug fixes. -Steve
Re: Is D still alive?
Thank you for your answer. But is there also a productive IDE for 'the daily use'? I'm used to code Delphi and there is also everything in the IDE I need to code full featured applications. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) but a IDE which supports graphical debugging is vital for me.
Re: Is D still alive?
In addition you have to know for what I want to use D. I want to code little games (2D: Jump'n'Run) and I want to use D for scholastic use - drawing plots, calculating functions, ... and so on. You see: I want to use D for private and for scholastic purposes.
Re: Is D still alive?
On Wed, 26 Jan 2011 14:54:06 -0500, Fab fab-cod...@web.de wrote: Thank you for your answer. But is there also a productive IDE for 'the daily use'? I'm used to code Delphi and there is also everything in the IDE I need to code full featured applications. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) but a IDE which supports graphical debugging is vital for me. There are several projects in progress for D IDEs, at various levels of maturity, including one that integrates D into visual studio. http://prowiki.org/wiki4d/wiki.cgi?EditorSupport Note, you may be able to find answers to other questions on the D wiki. -Steve
Re: Is D still alive?
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vpxkvij9eav7ka@steve-laptop... On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread Can your programming language do this? So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's to expensive - so: is D as precious as its pretend to be? I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. So very true :) I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages.
Re: Is D still alive?
Fab fab-cod...@web.de wrote in message news:ihpu4u$24bp$1...@digitalmars.com... Thank you for your answer. But is there also a productive IDE for 'the daily use'? I'm used to code Delphi and there is also everything in the IDE I need to code full featured applications. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) but a IDE which supports graphical debugging is vital for me. I use Programmer's Notepad 2 which does everything I care about and is very nicely lean and responsive. I'm not sure if it does debugging though, I've never tried. If you prefer the bigger (bloated, IMO) IDE's then there are two D pulgins for Eclipse (Descent is the older more advanced one, and there's another, I forget the name, that's newer and being actively developed). There is also stuff out there to make D work well with Visual Studio (see the D.announcements newsgroup).
immutable
Hello, I have just recently started programming in D (a very pleasant experience so far I must say), but when experimenting with the the immutable attribute I discovered that the following code does not generate a compile time nor a runtime error: //Decalare immutable string immutable char[] buf = hello; //Print the value of buf writefln(buf = %s,buf); //Change buf by using standard input stdin.readln(buf); //Print buf again writefln(buf = %s,buf); This is a bit confusing to be because I had assumed that immutable data really would be immutable (without casting). Why does the code above work? Cheers Nilew
Re: Is D still alive?
Fab fab-cod...@web.de wrote in message news:ihpv7r$272q$1...@digitalmars.com... In addition you have to know for what I want to use D. I want to code little games (2D: Jump'n'Run) and I want to use D for scholastic use - drawing plots, calculating functions, ... and so on. You see: I want to use D for private and for scholastic purposes. For games, there are SDL and SFML bindings for D. You may also want to look at the Derelict project which includes bindings for a bunch of useful libraries. For plots/charts/graphs/etc, you should look at the humorously-named Plot2Kill library. Personally, I think D would be great for small games, private uses and scholastic uses. In fact, even *way* back *before* D1, Kenta Cho made some very good freeware games in D, like Torus Trooper and TUMIKI Fighters (ie, the original version of Blast Works). The areas where D is still a little behind are: If you *need* to be able to compile *native* 64-bit code (32-bit will still work on a 64-bit machine/OS, of course). If you need to create shared dynamic libraries (ie, .dll and .so). If you need to link with Windows C .obj and .lib files that were compiled with anything other than DMC. If you need to use a graphical GUI-builder tool. Or if you want to use something similar to Rails or Django to create web apps.
Re: Is D still alive?
On Wed, 26 Jan 2011 15:11:06 -0500, Nick Sabalausky a@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vpxkvij9eav7ka@steve-laptop... On Wed, 26 Jan 2011 14:25:10 -0500, Fab fab-cod...@web.de wrote: Are there any continued database projects? AFAIK, there is very little DB support (which will definitely need to be addressed before D is considered a complete language) for D2. However, you *always* have support via C bindings. D has zero-overhead binding to C functions, all you need to do is port the declarations to D. If you are using D1, there are several projects, I don't think many of them are up to date: http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread Can your programming language do this? I have ignored that thread (I sometimes just ignore threads because they start out uninteresting, or become uninteresting, and then I miss out on some good stuff!) I'll have to take a look, D2 really does need a DB interface -- badly. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages. It all seems really good until you hit an issue that cannot be worked around -- like a compiler error or a misdesigned feature. I call these 'mercy' problems, because you are then at the complete mercy of someone else. If you have a deadline, or have a complete stoppage in work, you really have little choice but to move onto another language or abandon the project. Dcollections sat idle for about a year because of a problem like this. That would scare the crap out of me if I was a project manager trying to decide whether to use D or not. I've had first hand experience with using a product (from Microsoft) that failed so badly that we needed to have them fix it (which of course took about 3 months). A year later, they discontinued the product, and we had even more problems. I wrote my own system to replace it from scratch, and everything works so much better now (and uses less memory!). Not to mention, we have all source, so it's always possible to fix. A small part of it is written in D1/Tango and performs beautifully :) But I'd probably not rewrite the server in D (currently in C#) because it's lacking too much support for a lot of the things I do with it. I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. There are also really scary possibilities that I've seen happen to a few poor souls -- like hard-to-solve OPTLINK bugs. Those may creep up at any time. Really, I just feel that D2's tools are not mature enough, or have enough support to trust a professional product on it -- yet. I'm sure this will change in the future. BTW, I plan to write a semi-professional project in D2 in the near future, but I'm 1) willing to take the risks 2) have no deadline and 3) not depending on this project for a living. -Steve
Re: immutable
On Wed, 26 Jan 2011 15:32:58 -0500, Robert robert.we...@hotmail.com wrote: Hello, I have just recently started programming in D (a very pleasant experience so far I must say), but when experimenting with the the immutable attribute I discovered that the following code does not generate a compile time nor a runtime error: //Decalare immutable string immutable char[] buf = hello; //Print the value of buf writefln(buf = %s,buf); //Change buf by using standard input stdin.readln(buf); //Print buf again writefln(buf = %s,buf); This is a bit confusing to be because I had assumed that immutable data really would be immutable (without casting). Why does the code above work? It shouldn't. I don't know where the bug is. Please file a bug with a complete program (with a main() function) here: http://d.puremagic.com/issues/enter_bug.cgi BTW, this has a segfault in Linux, so it's definitely trying to overwrite immutable data. -Steve
Re: immutable
BTW, this has a segfault in Linux, so it's definitely trying to overwrite immutable data. Does it also segfault with string buf?
Re: immutable
On Wed, 26 Jan 2011 15:47:23 -0500, Trass3r u...@known.com wrote: BTW, this has a segfault in Linux, so it's definitely trying to overwrite immutable data. Does it also segfault with string buf? No. Now I'm confused :) -Steve
Re: immutable
BTW, this has a segfault in Linux, so it's definitely trying to overwrite immutable data. Does it also segfault with string buf? No. Now I'm confused :) On Linux strings are put into some read-only space. I guess an immutable(char[]) also puts the pointer and length into that storage.
Re: immutable
On 01/26/2011 02:40 PM, Steven Schveighoffer wrote:
On Wed, 26 Jan 2011 15:32:58 -0500, Robert robert.we...@hotmail.com
wrote:
Hello,
I have just recently started programming in D (a very pleasant
experience so
far I must say), but when experimenting with the the immutable
attribute I
discovered that the following code does not generate a compile time nor a
runtime error:
//Decalare immutable string
immutable char[] buf = hello;
//Print the value of buf
writefln(buf = %s,buf);
//Change buf by using standard input
stdin.readln(buf);
//Print buf again
writefln(buf = %s,buf);
This is a bit confusing to be because I had assumed that immutable
data really
would be immutable (without casting). Why does the code above work?
It shouldn't. I don't know where the bug is. Please file a bug with a
complete program (with a main() function) here:
http://d.puremagic.com/issues/enter_bug.cgi
BTW, this has a segfault in Linux, so it's definitely trying to
overwrite immutable data.
-Steve
I'd guess this is the problem:
void badurk(C,E)(ref C[] x, E y){
x ~= y;
}
void main(string[] args){
immutable char[] buf = hello;
static assert(is(typeof(buf) == immutable(char[])));
badurk(buf,'a'); //compiler: la la, this is okay!
}
OT: this function confuses me:
size_t readln(C)(ref C[] buf, dchar terminator = '\n') if (isSomeChar!C)
{
static if (is(C == char))
{
enforce(p p.handle, Attempt to read from an unopened
file.);
return readlnImpl(p.handle, buf, terminator);
}
else
{
// TODO: optimize this
string s = readln(terminator);
if (!s.length) return 0;
buf.length = 0;
foreach (wchar c; s) - (?!)
{
buf ~= c;
}
return buf.length;
}
}
Re: immutable
(readln only uses ~= on buf, it doesn't change the original string)
Re: immutable
This is a serious bug. http://d.puremagic.com/issues/show_bug.cgi?id=5492
Re: Is D still alive?
and I want to use D for scholastic use - drawing plots, calculating functions, ... and so on. Well nothing can beat Matlab for quick plots n stuff. (Speaking of which, of course you can write plugins for it with D: https://bitbucket.org/trass3r/matd) You see: I want to use D for private and for scholastic purposes. D's just fine for private stuff :)
Re: immutable
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message news:ihq1pm$2d2v$1...@digitalmars.com... OT: this function confuses me: string s = readln(terminator); foreach (wchar c; s) - (?!) Automatically converts s from string to wstring and iterates over the wchars. It should be dchar, though, not wchar.
Re: immutable
On Wed, 26 Jan 2011 15:52:25 -0500, Trass3r u...@known.com wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. readln needs a serious redesign it looks like. -Steve
Re: Is D still alive?
But is there also a productive IDE for 'the daily use'? I still use Descent for Eclipse. It isn't maintained anymore but it's the only one with a copy of the dmd frontend with some semantic analysis. VisualD on Windows provides some basic auto-completion and goto definition etc via compiler generated json files. I don't need a GUI-Designer (but it would be nice - maybe something like the QT-Designer) I think QtD supports the Qt GUI Designer. but a IDE which supports graphical debugging is vital for me Then you should use VisualD on Windows. It includes cv2pdb which makes it possible to debug D apps with VisualStudio without much pain.
Re: immutable
On Wed, 26 Jan 2011 16:12:58 -0500, Robert robert.we...@hotmail.com wrote: I didn't expect the code to run, hence my question. I tried it on OSX first which might have been the reason. Ran it on Ubuntu too and got the expected segmentation fault. The code shouldn't even compile. But the segfault is OS dependent (as you discovered). Windows also will not segfault. -Steve
Re: immutable
(readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. No I meant it doesn't alter buf's original content, i.e. hello Of course it modifies the array itself via ~= and thus takes it as a ref. Though it should use 'out' instead I think.
Re: immutable
I didn't expect the code to run, hence my question. I tried it on OSX first which might have been the reason. Ran it on Ubuntu too and got the expected segmentation fault. But thank you for the answer, I have filed the bug. Robert
Re: immutable
But thank you for the answer, I have filed the bug. Rats, I've filed one too ;) http://d.puremagic.com/issues/show_bug.cgi?id=5492
Re: immutable
Hopefully they will give it double the attention then ;)
Re: immutable
On Wed, 26 Jan 2011 16:13:41 -0500, Trass3r u...@known.com wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. No I meant it doesn't alter buf's original content, i.e. hello Of course it modifies the array itself via ~= and thus takes it as a ref. Though it should use 'out' instead I think. Then why not return the newly-created buffer? Why alter the buffer via a parameter? It makes no sense to me. Better API: char[] readln(); or if you want different char types: C[] readln(C = char)(); I think the original intent was for the code to overwrite the buffer, but it doesn't take into account the append improvements circa 2.041. -Steve
Re: Is D still alive?
But a few month ago I've got a book about D as a present Nice, the word is spreading. So - is there any reason to change to D? I would ... I really would change if there were more points than a nice language. I don't buy a good car if it's too expensive But once you had a test drive, you just can't get out anymore.
Re: Is D still alive?
Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it.
Re: Is D still alive?
On 1/26/11 4:09 PM, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei
Re: Is D still alive?
On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... I dream of the day that I'll be able to use D all of the time and not have to worry about C++ anymore. - Jonathan M Davis
Re: Is D still alive?
Walter Bright newshou...@digitalmars.com wrote in message news:ihq66j$2llc$1...@digitalmars.com... Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. Heh, D is programmer crack :) I use Haxe a lot and it's by no means a bad langauge overall, as far as languages go. Beats the snot out of PHP and ActionScript. But I frequently find myself cursing at it for not being able to handle things that I take for granted in D. Heck, just the other day I was going nuts because I had 5 objects that I needed to do some common trivial setup to, and there was *no* way to do it in a loop. No change I made ever stuck - it was as if the objects forgot they were reference types. Nothing worked. At least a full half-hour later, maybe a full hour, I ended up just copy-pasting the same damn code 5 times, once for each object. In D, I would have stuck them all in an array, typed foreach..., and been done in under a minute.
Git Contributors Guide (Was: Re: destructor order)
2011/1/26 Steven Schveighoffer schvei...@yahoo.com: Steve, if you could point out what I need to do I'll be glad to do it right now. Better yet, feel free to try your hand at a git commit. It's fun! *sweats nervously* I don't know, I'd like to read about how git works before doing a commit. I don't really understand it at all, I had the same problem with subversion when I started using it. This seems like a good time for a quick git-contributors guide. There are plenty of guides in other places, but anyways; (this is for Linux and the native Git). I do not know about how to work with other versions such as Tortoise, or on other platforms, but it should be very similar. One-time thing for first-time git; tell git who you are: $ git config --global user.name John Doe $ git config --global user.email john@server.com 1. Clone out a fresh copy of the project from github, i.e. $ git clone git://github.com/D-Programming-Language/druntime.git 2. Do your thing. Change whatever file you need. 3. Stage your changes with git add file for any added or changed file. $ git add path/myfile 4. Commit with git commit. Your editor will pop up asking for a commit-message. $ git commit ** Short-path **: If there are no _new_ files in the commit, you can skip step 3, and git commit -a without the git add-stage. This will make the commit-command work like in Subversion. ** GUI-alternative **: For step 3 and 4, please try out the excellent git gui command, which let's you pick individual lines in files to commit. Great for splitting up work into logical patches. Also has support for amending the last patch in line, fixing typos and such. Your commit is now done. You can examine it with the command git log which will show you the commit-history, and git show, which will show you the last commit in detail. ** GUI-alternative **: I find gitk to be immensely useful to review things before submitting or publishing them. It allows all sorts of niceties, reviewing both changes and snapshotted trees from history, comparing revisions and following changes to a single file. There are now many ways to now submit the patch. The BEST way is probably publishing your branch in some public place like github, and send a notification to the respective mailing-list, or bug-tracker. It is described at github itself. Another way is of course generating a plain old git diff, but that does not retain authorship or time. Nor is it practical for series of patches. The way I will show here is to gather up your changes in a so-called bundle, which can then be sent by mail or attached in a bug-tracker. First, some terms that might need explaining. :origin: A repository usually has neighboring repositories, friend whom you often communicate with. origin is the default-name of the repository you originally cloned. upstream so to speak. :master: In each repository, there can be many branches. master is by default the name of the trunk, in SVN-terms. So, when one speaks about origin/master, one is basically saying trunk of upstream. Now, creating your bundle is as simple as: $ git bundle create mypatch.gitbundle origin/master.. # Dont forget the double-dots. This tells git to bundle up all revisions on my current branch, that aren't in upstream. This will generate the file mypatch.gitbundle, which can be sent to for review. The reviewer then pulls from it by: $ git checkout -b review# Create new review-branch. $ git pull path/to/bundle HEAD # Import from bundle. The changes will now be merged into the reviewers tree, in a special review-branch, where verification can be made, tests can be run and, possibly small fixes to the patch can be appended. When done, change to master-branch and merge the changes (if they are acceptable). $ git checkout master # Checkout the master-branch (or some other branch if integration should happen there instead) $ git merge review # Merge in the review-branch $ git branch -d review # And drop it Hope this helps. For more advanced, and continual work, you should probably setup a private fork, described at http://help.github.com/forking/. Happy Git:ing!
Re: Is D still alive?
Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. Yep, like being thrown back to the Stone Age.
Re: Is D still alive?
On 1/26/11 4:09 PM, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. As much as I cringe when I see http://d.puremagic.com/issues/show_bug.cgi?id=5493 Andrei Well, coding in D is like being Indiana: you might run into nasty traps here and there but you just can't be a vanilla guy anymore ;)
Re: Is D still alive?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.973.1296080233.4748.digitalmar...@puremagic.com... On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that.
Re: Is D still alive?
For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list.
Re: Is D still alive?
Nick Sabalausky a@a.a wrote in message news:ihq7a3$2o05$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.973.1296080233.4748.digitalmar...@puremagic.com... On Wednesday, January 26, 2011 14:09:25 Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. LOL. Yeah. There's just so many little things that D improves on that when you're stuck in C++ land, you're constantly running into little things that you miss having or are annoyed to have to deal with. auto has probably been the biggest one for me, though slicing isn't far behind. At least auto will be in C++ 0x... For me, D's killer features were string handling (slicing, appending/concatenation, ***and .length instead of null-termination***) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Fixed. ^^^
Re: Git Contributors Guide (Was: Re: destructor order)
Ulrik Mikaelsson: This seems like a good time for a quick git-contributors guide. Thank you for your explanation :-) Bye, bearophile
More on the necessity and difficulty of a package management system
Seems to be unduly difficult in Python: http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps We need to have a good solution for D. Andrei
Re: More on the necessity and difficulty of a package management system
On 26/01/11 22:45, Andrei Alexandrescu wrote: Seems to be unduly difficult in Python: http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps We need to have a good solution for D. Andrei It's on my todo list for Serenity, which is almost able to power a complete blog now! (It already can if you don't mind guests being able to add blog posts). The exact workflow is unknown, I'm thinking a maximum of one command (or one click) to deploy development or stable versions, and switch between though. Now if only I had some clones so I could get it working faster... -- Robert http://octarineparrot.com/
Re: More on the necessity and difficulty of a package management system
D's deployment is helped a lot by being compiled. We could just use native package systems (deb, rpm; whatever works for C works for D too) and/or static linking to ease the case of pushing something to a live server with zero* outside dependencies. * Well, one: libc I guess. But that's pretty easy to manage. Of course, compiling is another story. I said my piece in a recent thread, so I won't argue that again :)
Re: Is D still alive?
Steven Schveighoffer napisał: Adam Ruppe and Piotr Szturmaj have recently been working on some database stuff. See the recent thread Can your programming language do this? I have ignored that thread (I sometimes just ignore threads because they start out uninteresting, or become uninteresting, and then I miss out on some good stuff!) I'll have to take a look, D2 really does need a DB interface -- badly. That and networking. I can help with the latter as I had done a bit of network devving, but I don't know what's the current state of affairs (sb working on it already?) and whether Phobos needs another soul on-board. I would say it is not ready for prime-time yet. It has a way to go, but some have managed to build pretty impressive applications from it. So it would depend on your application. Personally, I think that even though D still has some things to be worked out, I think it's *still* far better than any of the other more mature languages. It all seems really good until you hit an issue that cannot be worked around -- like a compiler error or a misdesigned feature. I call these 'mercy' problems, because you are then at the complete mercy of someone else. If you have a deadline, or have a complete stoppage in work, you really have little choice but to move onto another language or abandon the project. Dcollections sat idle for about a year because of a problem like this. Yeah, ditto for QuantLibD. I just spent too much time on a test project trying to isolate dmd and phobos bugs to submit something meaningful to bugzilla and too little time coding. Not to mention that sometimes it was really hard to know what the language *should* do because of outdated documentation. But maybe the storm has passed and I should try serious work in D again? [snip] BTW, I plan to write a semi-professional project in D2 in the near future, but I'm 1) willing to take the risks 2) have no deadline and 3) not depending on this project for a living. Sheer curiosity: what will the project be about? -- Tomek
dlist for phobos
Are there plans for including a double linked list in phobos? Maybe one backed by an array like .NET's ListT or Java's ArrayList. If so, when? Thanks
Re: Is D still alive?
Yeah, ditto for QuantLibD. I just spent too much time on a test project trying to isolate dmd and phobos bugs to submit something meaningful to bugzilla and too little time coding. Not to mention that sometimes it was really hard to know what the language *should* do because of outdated documentation. But maybe the storm has passed and I should try serious work in D again? I also ran into serious issues with cl4d that forced me to leave it alone several times. There even was a nasty bug with a corrupt stack frame, luckily it disappeared after some more coding and refactoring. But all in all I have the feeling that the situation has improved. Some serious forward reference bugs were fixed and I could more or less finish my work by now.
Re: dlist for phobos
On Wednesday, January 26, 2011 15:34:05 %u wrote: Are there plans for including a double linked list in phobos? Maybe one backed by an array like .NET's ListT or Java's ArrayList. If so, when? Array is the equivalent of Java's ArrayList. It's Java's LinkedList which is a doubly-linked list. You don't normally use arrays to implement linked lists. We do have a _singly_-linked list - SList - but not doubly-linked list at the moment. I'd be stunned if Andrei doesn't intend to add one at some point though. However, std.container was slow in coming, and it's been slow in growing. - Jonathan M Davis
Re: immutable
On 01/26/2011 10:21 PM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 16:13:41 -0500, Trass3r u...@known.com wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. No I meant it doesn't alter buf's original content, i.e. hello Of course it modifies the array itself via ~= and thus takes it as a ref. Though it should use 'out' instead I think. Then why not return the newly-created buffer? Why alter the buffer via a parameter? It makes no sense to me. Better API: char[] readln(); or if you want different char types: C[] readln(C = char)(); Yes, that's how I think readln's API should be. Is a buf version for repeated use? (I guess no, since input comes from a user?) Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis -- _ vita es estrany spir.wikidot.com
Re: More on the necessity and difficulty of a package management system
On 01/26/2011 11:45 PM, Andrei Alexandrescu wrote: Seems to be unduly difficult in Python: http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps Yes, experienced. Related, but distinct, difficulty with intra-package import (inter-module references) (looks like in D as well). Denis -- _ vita es estrany spir.wikidot.com
Re: immutable
On 1/26/11 6:24 PM, spir wrote: On 01/26/2011 10:21 PM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 16:13:41 -0500, Trass3r u...@known.com wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. No I meant it doesn't alter buf's original content, i.e. hello Of course it modifies the array itself via ~= and thus takes it as a ref. Though it should use 'out' instead I think. Then why not return the newly-created buffer? Why alter the buffer via a parameter? It makes no sense to me. Better API: char[] readln(); or if you want different char types: C[] readln(C = char)(); Yes, that's how I think readln's API should be. Is a buf version for repeated use? (I guess no, since input comes from a user?) Denis There is an overload of readln that looks like that. Andrei
Re: dlist for phobos
On 1/26/11 6:20 PM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 15:34:05 %u wrote: Are there plans for including a double linked list in phobos? Maybe one backed by an array like .NET's ListT or Java's ArrayList. If so, when? Array is the equivalent of Java's ArrayList. It's Java's LinkedList which is a doubly-linked list. You don't normally use arrays to implement linked lists. We do have a _singly_-linked list - SList - but not doubly-linked list at the moment. I'd be stunned if Andrei doesn't intend to add one at some point though. However, std.container was slow in coming, and it's been slow in growing. - Jonathan M Davis One big issue with std.container is that the absence of unified function call syntax forces the implementation to add a lot of aliases. I'm sort of stalling in hope that language improvements will prompt terser container implementations. I'm also undecided on what to do about sealing, and again language improvements (preventing escapes of references) could lead to improved designs. That being said, a doubly-linked list is an obvious candidate as the next significant container to put in std.container. Andrei
Re: Is D still alive?
On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. And if for some reason you really want to be able to just have it use $ if the index is too large, it's easy to write a wrapper function which does that. - Jonathan M Davis
Re: Is D still alive?
On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio s = abc print(string.sub(s, 1, 123456789)) abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: immutable
On Wed, 26 Jan 2011 19:46:43 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/26/11 6:24 PM, spir wrote: On 01/26/2011 10:21 PM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 16:13:41 -0500, Trass3r u...@known.com wrote: (readln only uses ~= on buf, it doesn't change the original string) What? Why does it take a ref argument then? If it doesn't overwrite the buffer passed in, there is no point in giving it a buffer. No I meant it doesn't alter buf's original content, i.e. hello Of course it modifies the array itself via ~= and thus takes it as a ref. Though it should use 'out' instead I think. Then why not return the newly-created buffer? Why alter the buffer via a parameter? It makes no sense to me. Better API: char[] readln(); or if you want different char types: C[] readln(C = char)(); Yes, that's how I think readln's API should be. Is a buf version for repeated use? (I guess no, since input comes from a user?) Denis There is an overload of readln that looks like that. Then is my hypothesis correct that readln is *supposed* to overwrite the buffer? It currently doesn't. -Steve
Re: dlist for phobos
On Wed, 26 Jan 2011 18:34:05 -0500, %u e...@ee.com wrote: Are there plans for including a double linked list in phobos? Maybe one backed by an array like .NET's ListT or Java's ArrayList. If so, when? http://www.dsource.org/projects/dcollections LinkList there is doubly-linked. Sorry, I don't have online docs yet for the d2 version... *kicks self* -Steve
Re: Is D still alive?
On Wednesday 26 January 2011 17:52:19 spir wrote: On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio s = abc print(string.sub(s, 1, 123456789)) abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want the rest of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. - Jonathan M Davis
Re: Is D still alive?
On Wednesday 26 January 2011 19:06:37 Jonathan M Davis wrote: On Wednesday 26 January 2011 17:52:19 spir wrote: On 01/27/2011 02:11 AM, Jonathan M Davis wrote: On Wednesday, January 26, 2011 16:41:10 spir wrote: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. spir@d:~$ python Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type help, copyright, credits or license for more information. s = 'abc' s[0:123456789] 'abc' spir@d:~$ lua Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio requireio s = abc print(string.sub(s, 1, 123456789)) abc I'm constantly annoyed by D's behaviour. For instance, often have to write out the end of a string from a given point, but only at most n chars (to avoid cluttering the output, indeed): writeln(s[i..i+n]); which fails if there are less than n remaining chars ;-) I _rarely_ see cases where I would consider it okay to give an index for the end of an array and having that index be too large is a good thing. It invariably means that your algorithm is wrong. In my experience, if you really need to know what the size of your array is and handle it properly. There _are_ cases where you say that you want the rest of the array or collection and don't care how much that is, but in cases where you're actually looking to specify the index, if the index is wrong, then the code is wrong. Now, I suppose that there are cases where you could simplify an algorithm where you effectively be n or less (if there aren't n elements left). But that's definitely atypical in my experience, and writing a wrapper function for such a case is trivial. Generally speaking, I'd be very worried about code which was lax enough about indices to not care whether it was indexing passed the end of the array or not. Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. I should probably add that it's more efficient to have the built-in slicing facilities be exact and build inexact ones on top of that then it is to make them inexact and the build exact ones on top. When you get down to it, you _have_ to slice _exactly_ when you get down deep enough in the code. So, making the slicing then be exact on top of that doesn't really cost anything. But adding the extra checks to make the inexact one work adds extra cost. So, while that's fine if the inexact behavior is what you want, it's _not_ fine if it's the exact behavior that you want, since then unnecessary checks are happening in the middle. For efficiency reasons, the exact behavior _needs_ to be the default. exact - low level exact and inexact - exact - low level exact works as efficiently as is possible. Whereas having inexact - low level exact and exact - inexact - low level exact is _not_ efficient. - Jonathan M Davis
