www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - denv - D version of rbenv

reply "Masahiro Nakagawa" <repeatedly gmail.com> writes:
I use rbenv to manage multiple versions of Ruby.
So, I ported rbenv to D.

https://github.com/repeatedly/denv

I tested dmd on Linux and Mac.
(Sorry, I am not GDC and LDC user)

I will port ruby-build If necessary.


Regards,
Masahiro
May 04 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa  
<repeatedly gmail.com> wrote:

 I use rbenv to manage multiple versions of Ruby.
 So, I ported rbenv to D.

 https://github.com/repeatedly/denv

 I tested dmd on Linux and Mac.
 (Sorry, I am not GDC and LDC user)

 I will port ruby-build If necessary.


 Regards,
 Masahiro
Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm
May 04 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-04 19:54, simendsjo wrote:
 On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa
 <repeatedly gmail.com> wrote:

 I use rbenv to manage multiple versions of Ruby.
 So, I ported rbenv to D.

 https://github.com/repeatedly/denv

 I tested dmd on Linux and Mac.
 (Sorry, I am not GDC and LDC user)

 I will port ruby-build If necessary.


 Regards,
 Masahiro
Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm
Seems a lot more complicated as well. A big part of DVM is to easily install a compiler, which is done manually with denv. Oh, my. Everything is written in shell script. DVM works on Windows as well, thanks to Nick :) -- /Jacob Carlborg
May 04 2012
parent "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Friday, 4 May 2012 at 19:09:01 UTC, Jacob Carlborg wrote:
 On 2012-05-04 19:54, simendsjo wrote:
 On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa
 <repeatedly gmail.com> wrote:

 I use rbenv to manage multiple versions of Ruby.
 So, I ported rbenv to D.

 https://github.com/repeatedly/denv

 I tested dmd on Linux and Mac.
 (Sorry, I am not GDC and LDC user)

 I will port ruby-build If necessary.


 Regards,
 Masahiro
Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm
Seems a lot more complicated as well. A big part of DVM is to easily install a compiler, which is done manually with denv.
I will port ruby-install to D if needed.
 Oh, my. Everything is written in shell script. DVM works on 
 Windows as well, thanks to Nick :)
Yeah. denv does not directly support Windows same as other xxenv.
May 04 2012
prev sibling parent reply "Masahiro Nakagawa" <repeatedly gmail.com> writes:
On Friday, 4 May 2012 at 17:54:35 UTC, simendsjo wrote:
 On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa 
 <repeatedly gmail.com> wrote:

 I use rbenv to manage multiple versions of Ruby.
 So, I ported rbenv to D.

 https://github.com/repeatedly/denv

 I tested dmd on Linux and Mac.
 (Sorry, I am not GDC and LDC user)

 I will port ruby-build If necessary.


 Regards,
 Masahiro
Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm
Yes. But I don't know the detail of dvm implementation. rbenv is a small and compact version manager than rvm. (If you want to know more comparison of rbenv and rvm, See https://github.com/sstephenson/rbenv ) I like rbenv, so I ported.
May 04 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Masahiro Nakagawa" <repeatedly gmail.com> wrote in message 
news:niagensidmjugqbxrtlq forum.dlang.org...
 On Friday, 4 May 2012 at 17:54:35 UTC, simendsjo wrote:
 On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa 
 <repeatedly gmail.com> wrote:

 I use rbenv to manage multiple versions of Ruby.
 So, I ported rbenv to D.

 https://github.com/repeatedly/denv

 I tested dmd on Linux and Mac.
 (Sorry, I am not GDC and LDC user)

 I will port ruby-build If necessary.


 Regards,
 Masahiro
Sounds very similar to, but more complete than, dvm: https://github.com/jacob-carlborg/dvm
Yes. But I don't know the detail of dvm implementation. rbenv is a small and compact version manager than rvm. (If you want to know more comparison of rbenv and rvm, See https://github.com/sstephenson/rbenv ) I like rbenv, so I ported.
No harm having both. I'm sure denv will be great for people coming from Ruby.
May 04 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-04 21:38, Masahiro Nakagawa wrote:

 Yes. But I don't know the detail of dvm implementation.
 rbenv is a small and compact version manager than rvm.
 (If you want to know more comparison of rbenv and rvm,
 See https://github.com/sstephenson/rbenv )
DVM can't even do half of the things RVM can. DVM can basically only install compilers and switch between installed compilers. It can build DMD as well, always forgets that.
 I like rbenv, so I ported.
Fair enough. That's why I ported RVM :) -- /Jacob Carlborg
May 04 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jo1gri$1prf$1 digitalmars.com...
 On 2012-05-04 21:38, Masahiro Nakagawa wrote:

 Yes. But I don't know the detail of dvm implementation.
 rbenv is a small and compact version manager than rvm.
 (If you want to know more comparison of rbenv and rvm,
 See https://github.com/sstephenson/rbenv )
DVM can't even do half of the things RVM can. DVM can basically only install compilers and switch between installed compilers. It can build DMD as well, always forgets that.
There's a little more work could probably be done on DVM's dmd-compiling. It doesn't support passing options to the makefiles. And IIRC it always does a full clean rebuild, it really should have "clean" separate, so you don't have to recompile *everything* every time. Speaking of, although I haven't had time to do anything on DVM lately (and probably won't anytime soon :( ), I have been thinking about what you said a while back about it needing some refactoring: Last time it was brought up, I was unsure of quite what you had in mind. I was under the impression that you wanted to redesign the whole way the command system *worked*. It's occurred to me that's maybe not what you meant? Were you thinking that the *system* of commands would work the same way as now, but just some commands/subcommands need to be moved around, the stuff that's kind of an ugly "internal psuedo-command" should be promoted to a true command/subcommand, etc?
 I like rbenv, so I ported.
Fair enough. That's why I ported RVM :)
I had no idea it was ported from anything! :) (I've used Ruby, but mostly just for writing rakefiles.)
May 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-04 23:31, Nick Sabalausky wrote:

 There's a little more work could probably be done on DVM's dmd-compiling. It
 doesn't support passing options to the makefiles. And IIRC it always does a
 full clean rebuild, it really should have "clean" separate, so you don't
 have to recompile *everything* every time.
It doesn't a full rebuild of DMD at least. It seems to just invoke "make" which will notice that no files have changed and not compile anything.
 Speaking of, although I haven't had time to do anything on DVM lately (and
 probably won't anytime soon :( ), I have been thinking about what you said a
 while back about it needing some refactoring:
I neither haven't had time, or rather, I focused my time on other projects.
 Last time it was brought up, I was unsure of quite what you had in mind. I
 was under the impression that you wanted to redesign the whole way the
 command system *worked*. It's occurred to me that's maybe not what you
 meant? Were you thinking that the *system* of commands would work the same
 way as now, but just some commands/subcommands need to be moved around, the
 stuff that's kind of an ugly "internal psuedo-command" should be promoted to
 a true command/subcommand, etc?
I was mostly thinking of how the code is structured internally. Basically nothing would be changed from a user's point of view. What I don't like is that all functionality is implemented in the command classes. The command classes should only handle the actual command and the flags for that given command. Then it should delegate to other classes for functions. The "install" command is a perfect example of this. Currently the Install class inherits from Fetch, which is so wrong. It just does that to inherit the implementation, it's not an actual subtype. What should have been done is something like this (in some kind of pseudo code) : class FetchCommand { void execute () { auto fetcher = new Fetcher; auto result = fetcher.fetch(args ...); store(result); } } class InstallCommand { void execute () { auto fetcher = new Fetcher; auto result = fetcher.fetch(args ...); auto installer = new Installer; installer.install(result); } } You can have a look at how Orbit it's structured as well. Structuring the code like this will also make it usable as a library (don't know if that would be useful in this case). What should be changed from a user's point of view is that flags specific to a command should only be available to that command and not globally. I was also hoping to factor out any compiler specific code in it's own classes/functions. This would make it possible handle other compilers like GDC, LDC and SDC. Although I don't think they provide pre-compiled binaries in the same way as DMD does. -- /Jacob Carlborg
May 04 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:jo1jnt$1vfl$1 digitalmars.com...
 Last time it was brought up, I was unsure of quite what you had in mind. 
 I
 was under the impression that you wanted to redesign the whole way the
 command system *worked*. It's occurred to me that's maybe not what you
 meant? Were you thinking that the *system* of commands would work the 
 same
 way as now, but just some commands/subcommands need to be moved around, 
 the
 stuff that's kind of an ugly "internal psuedo-command" should be promoted 
 to
 a true command/subcommand, etc?
I was mostly thinking of how the code is structured internally. Basically nothing would be changed from a user's point of view. What I don't like is that all functionality is implemented in the command classes. The command classes should only handle the actual command and the flags for that given command. Then it should delegate to other classes for functions. The "install" command is a perfect example of this. Currently the Install class inherits from Fetch, which is so wrong. It just does that to inherit the implementation, it's not an actual subtype. What should have been done is something like this (in some kind of pseudo code) : class FetchCommand { void execute () { auto fetcher = new Fetcher; auto result = fetcher.fetch(args ...); store(result); } } class InstallCommand { void execute () { auto fetcher = new Fetcher; auto result = fetcher.fetch(args ...); auto installer = new Installer; installer.install(result); } } You can have a look at how Orbit it's structured as well. Structuring the code like this will also make it usable as a library (don't know if that would be useful in this case).
Ah, ok, I see now.
 What should be changed from a user's point of view is that flags specific 
 to a command should only be available to that command and not globally.
Totally agree.
 I was also hoping to factor out any compiler specific code in it's own 
 classes/functions. This would make it possible handle other compilers like 
 GDC, LDC and SDC. Although I don't think they provide pre-compiled 
 binaries in the same way as DMD does.
Probably a good idea. Having support for those other compilers would be fantastic.
May 04 2012