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