denv - D version of rbenv
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
Re: denv - D version of rbenv
On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa repeate...@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
Re: denv - D version of rbenv
On 2012-05-04 19:54, simendsjo wrote: On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa repeate...@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
Re: denv - D version of rbenv
On Friday, 4 May 2012 at 17:54:35 UTC, simendsjo wrote: On Fri, 04 May 2012 17:54:11 +0200, Masahiro Nakagawa repeate...@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.
Re: denv - D version of rbenv
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 repeate...@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.
Re: denv - D version of rbenv
Masahiro Nakagawa repeate...@gmail.com wrote in message news:niagensidmjugqbxr...@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 repeate...@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.
Re: denv - D version of rbenv
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
dvm (Was: denv - D version of rbenv)
Jacob Carlborg d...@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.)
Re: dvm (Was: denv - D version of rbenv)
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
Re: dvm (Was: denv - D version of rbenv)
Jacob Carlborg d...@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.
