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 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 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 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
On Tue, 2011-01-25 at 21:24 -0500, Nick Sabalausky wrote: [ . . . ] > Ulrick mentioned that history rewriting is "encouraged under some particular > circumstances". What circumstances would those be? Rebasing/rewriting of private, never published repositories is absolutely fine, and is encouraged for preparing a repository for creation of changesets/patches where it is not possible to simply publish the repository and issue a pull request. In all other circumstances rebasing/rewriting is discouraged. Well actually as close to being banned as it is possible to get. Rebasing/rewriting an already published repository is a catastrophic event that ruins relationships with clones (due to the history rewriting!). Git repositories used as writing clients to Subversion repositories (using git-svn) have to do rebasing as an integral part of the writing to the Subversion repository. This means they have to be personal clients only. Read-only is a way of bridging of course since there is no rebasing. -- 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: DVM - D Version Manager
On Wed, 26 Jan 2011 10:50:20 -0500, Russel Winder wrote: 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. On my ubuntu system too -- to my surprise ;) On my fedora system I think it was symlinked to bash. Either way, the actual "bourne shell" is rarely installed on Linux, it's usually another shell that mimics the features. -Steve
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
Am 26.01.2011 09:36, schrieb Jacob Carlborg: > 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. > Debian (and probably ubuntu as well) has a package called "devscripts" which contains a handy tool called "checkbashisms". This tool tells you if your script uses bash-specific stuff and often even suggests a more portable alternative. I haven't checked DVM yet, but if you want to have stuff done one login, put it into ~/.profile instead of ~/.bashrc - this should be executed by all POSIX compliant shells I think. Cheers, - Daniel
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 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: DVM - D Version Manager
On 2011-01-26 19:12, Daniel Gibson wrote: Am 26.01.2011 09:36, schrieb Jacob Carlborg: 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. Debian (and probably ubuntu as well) has a package called "devscripts" which contains a handy tool called "checkbashisms". This tool tells you if your script uses bash-specific stuff and often even suggests a more portable alternative. That sounds like something I could use. I haven't checked DVM yet, but if you want to have stuff done one login, put it into ~/.profile instead of ~/.bashrc - this should be executed by all POSIX compliant shells I think. On Mac OS X I use .bash_profile, I don't know if .profile and/or .bashrc works. The bash man page (http://linux.die.net/man/1/bash) says: "When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable." And: "When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists." I'm not sure I know the difference between "an interactive login shell" and one that isn't. I'm not 100% sure in what file to put the script in. But what I want is to run a script when a new shell is started, like when you open the Terminal in Ubuntu/Mac OS X or opens a new tab in the terminal. Cheers, - Daniel -- /Jacob Carlborg
Re: DVM - D Version Manager
On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, 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. 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. 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 A good reference (if you don't have it) is Unix in a nutshell, probably my most used textbook. Ok, I'll have a look. -Steve -- /Jacob Carlborg
Re: DVM - D Version Manager
On 2011-01-26 21:04, "Jérôme M. Berger" wrote: 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; Is it possible to detect what shell is running and then load the correct version? - 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. The contents of $dvm_result_path will only export one variable. 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! OK, how else can I do the same thing? BTW this is how RVM (Ruby Version Manager) works, where I got the idea from. The whole RVM is written in shell script and it's sourced in .bashrc. -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
"Kagamin" 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 wrote: On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, 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. 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" 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" 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 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 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 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 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 Carlborg" 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 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: DVM - D Version Manager
On 2011-01-26 21:47, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 15:24:56 -0500, Jacob Carlborg wrote: On 2011-01-26 14:58, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 03:36:24 -0500, 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. 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 Ok, thanks. -- /Jacob Carlborg
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
"Vladimir Panteleev" wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky 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. 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).
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky wrote: "Vladimir Panteleev" wrote in message news:op.vpxo9jz4tuz...@cybershadow.mshome.net... On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky 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 wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don 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" wrote in message news:op.vpxphnlmtuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky 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" wrote in message news:op.vpxqfimjtuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 23:36:03 +0200, Nick Sabalausky wrote: > >> "Vladimir Panteleev" wrote in message >> news:op.vpxo9jz4tuz...@cybershadow.mshome.net... >>> On Wed, 26 Jan 2011 22:43:11 +0200, Nick Sabalausky 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" wrote in message news:op.vpxqmbpftuz...@cybershadow.mshome.net... > On Wed, 26 Jan 2011 23:22:34 +0200, Don wrote: > >> Vladimir Panteleev wrote: >>> On Wed, 26 Jan 2011 06:33:35 +0200, Don 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" wrote in message > news:op.vpxphnlmtuz...@cybershadow.mshome.net... > > > On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky 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" 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" wrote in message >> news:op.vpxphnlmtuz...@cybershadow.mshome.net... >> >> > On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky 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 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 wrote: > > "Jonathan M Davis" 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" wrote in message > >> news:op.vpxphnlmtuz...@cybershadow.mshome.net... > >> > >> > On Wed, 26 Jan 2011 22:46:44 +0200, Nick Sabalausky 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. > > >
