January 08, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:jecuno$18e6$1@digitalmars.com...
>
> Something possibly releated I've been meaning to bring up: I've been thinking that DVM's commands and options should work more like, say, git or svn. By that I mean: Right now DVM has a set of commands, and a set of "global" DVM options. Problem is, some of the options only apply to some of the commands. This sugegsts a few changes:
>
> 1. "dvm --help" should only show globally-applicable options. (--verbose and --help are probably only ones right now.)
>
> 2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should show a command-specific help screen.
>

3. Use of inapplicable options, like "dvm --default fetch 2.057", should be an error.

> This isn't a *huge* need right now, but I think it'll only become more and more important as DVM progresses. I don't know if this is something that should be taken into account in the refactoring, or just left until after.
>


January 09, 2012
On 2012-01-08 21:34, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jec1j6$2rbu$1@digitalmars.com...
>>
>> Ideally it should come before other new features. I mean, the more stuff
>> we put in there the more mess it will be. The point of the refactoring is
>> of course to make it easier to add new features and to understand the
>> code.
>
> Yea, that makes sense. I guess I just wasn't sure how "deep" the refactoring
> you were envisioning was going to be.

Quite deep. I want to have it look more like Orbit: https://github.com/jacob-carlborg/orbit

Instead of having all code in the commands I want to have a single class for a single task. The commands would then basically just create a new instance of the needed classes.

> Something possibly releated I've been meaning to bring up: I've been
> thinking that DVM's commands and options should work more like, say, git or
> svn. By that I mean: Right now DVM has a set of commands, and a set of
> "global" DVM options. Problem is, some of the options only apply to some of
> the commands. This sugegsts a few changes:
>
> 1. "dvm --help" should only show globally-applicable options. (--verbose
> and --help are probably only ones right now.)
>
> 2. "dvm [command] --help" (and maybe "dvm --help [command]", too) should
> show a command-specific help screen.
>
> This isn't a *huge* need right now, but I think it'll only become more and
> more important as DVM progresses. I don't know if this is something that
> should be taken into account in the refactoring, or just left until after.

Yeah, I know. That would be another reason to do the refactoring.

> Another thing that might need to be considered in the refactoring: On Linux,
> DVM doesn't currently work inside a shell script. It's just not recognized.
> I'm sure it probably has something to do with the "dvm" shell-function.
> Maybe it's because it's set to only be defined on interactive prompts? I
> don't really know for certain what the problem or the solution is, so
> depending on whatever the "right" solution is, this might be a "take into
> account in the refactoring" matter.

I didn't know about that. I'll take a look at that.

>> About the refactoring, what to you think about these:
>>
>> * Move to git
>
> I don't have a really strong opinion on that. While I kind of like Hg a
> little better, I normally use the Tortoise tools, and I like TortoiseGit
> much better than TortoiseHg. Also branching is built into Git rather than
> being a grafted-on extra, which is nice. (And of course, DVM goes
> hand-in-hand with DMD and DMD is Git). So I guess I would lean more towards
> Git, but either way works.

I've moved all my projects to git, use it at work, so I prefer it over mercurial.

>> * Move to github
>
> It's ultimately up to you, but personally I can't stand Github. My vote
> would be to stick with Bitbucket.
>
> Granted, I haven't actually tried Bitbucket's Git support yet. But just
> yesterday I started the process of converting a couple of my projects from
> SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
> know.

I'm asking you since you're the main contributor next to me. I prefer Github, many D project are moving to Github, DMD, Phobos and druntime are already there. But certainly don't want to push you away, that wouldn't be good for the Windows port :)

>> * Port to D2, still using Tango
>>
>
> I'm definitely in favor of switching to D2. In fact, I took the leap from
> D1/Tango straight to D2/Phobos on my own projects about a year or so ago, so
> I have some experience in that (and D2's only gotten better since), and I'd
> be happy to take the lead converting it to D2. I found that the vast
> majority of changes I needed to make were Tango->Phobos because, while there
> are some breaking changes from D1->D2, most of the changes are additive, and
> D1-style code works fine in D2 with only very little change.
>
> As far as Tango: I have no idea what the state of D2's Tango is, and
> personally I'd prefer Phobos. But if you have reason to believe D2's Tango
> is ready to use and you'd prefer that, then I'm perfectly fine with it.
> Actually, heck, if we're going to switch to D2, we may as well at least give
> D2's Tango a try along the way. If it works, it works, if it doesn't we can
> help out D2's Tango or just do Phobos (especially since 2.058 will have that
> new curl module).

I'm pretty sure Tango for D2 is ready enough. I got help porting my package manager, Orbit, to D2 using Tango. Everything compiles but not everything works, probably something D2 and Ruby related (TLS or something like that). But it was surprisingly few changes that needed to be done and that is all to Tango working with D2. The biggest problem would be to port the tool to use Phobos instead of Tango.

I guess it would be best to start by adding some high level tests to DVM. You probably won't like this but there's a great Ruby tool for testing these kind of things called Cucumber. I'm already using it in Orbit: https://github.com/jacob-carlborg/orbit/tree/master/features

-- 
/Jacob Carlborg
January 09, 2012
"Jacob Carlborg" <doob@me.com> wrote in message news:jee58o$54v$1@digitalmars.com...
> On 2012-01-08 21:34, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message news:jec1j6$2rbu$1@digitalmars.com...
>>> * Move to github
>>
>> It's ultimately up to you, but personally I can't stand Github. My vote would be to stick with Bitbucket.
>>
>> Granted, I haven't actually tried Bitbucket's Git support yet. But just
>> yesterday I started the process of converting a couple of my projects
>> from
>> SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
>> know.
>
> I'm asking you since you're the main contributor next to me. I prefer Github, many D project are moving to Github, DMD, Phobos and druntime are already there. But certainly don't want to push you away, that wouldn't be good for the Windows port :)
>

While I would find github more painful, it wouldn't make me decrease my contributions to DVM. DVM's too important a tool, IMO (Much like RDMD, which I also contribute too).

Heck, maybe if we're lucky that OSX desktop interface to github will someday get ported to Lin or Win :)

I'm on my way to bed so I'll check out those links later. (FWIW, I don't think Ruby's all that bad as far as dynamic langauges go. Probably one of the best, actually. It's just no D ;) )


January 09, 2012
On 06/01/12 22:29, Jacob Carlborg wrote:
> I just released a new version of DVM, 0.4.0. The only thing new in this
> release in the "compile" command. This allows to compile DMD, druntime
> and Phobos from github. Create a folder, clone DMD, druntime and Phobos
> in the newly create folder, run "dvm compile folder" to compile
> everything. The compiler is placed in the DMD directory.
>
> For installation instructions see: https://bitbucket.org/doob/dvm
>
> Changelog:
>
> Version 0.4.0
> New/Change Features
> * Added a "compile" command for compiling DMD, druntime and Phobos from
> github
>
I found that I needed to do:
cd .dvm
mkdir bin
before dvm install would work.
January 09, 2012
On 2012-01-09 10:30, Don Clugston wrote:
> On 06/01/12 22:29, Jacob Carlborg wrote:
>> I just released a new version of DVM, 0.4.0. The only thing new in this
>> release in the "compile" command. This allows to compile DMD, druntime
>> and Phobos from github. Create a folder, clone DMD, druntime and Phobos
>> in the newly create folder, run "dvm compile folder" to compile
>> everything. The compiler is placed in the DMD directory.
>>
>> For installation instructions see: https://bitbucket.org/doob/dvm
>>
>> Changelog:
>>
>> Version 0.4.0
>> New/Change Features
>> * Added a "compile" command for compiling DMD, druntime and Phobos from
>> github
>>
> I found that I needed to do:
> cd .dvm
> mkdir bin
> before dvm install would work.

Hmm, that's strange. On which platform? Is it when installing DVM itself or compilers?

-- 
/Jacob Carlborg
January 09, 2012
On 2012-01-09 10:14, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jee58o$54v$1@digitalmars.com...
>> On 2012-01-08 21:34, Nick Sabalausky wrote:
>>> "Jacob Carlborg"<doob@me.com>   wrote in message
>>> news:jec1j6$2rbu$1@digitalmars.com...
>>>> * Move to github
>>>
>>> It's ultimately up to you, but personally I can't stand Github. My vote
>>> would be to stick with Bitbucket.
>>>
>>> Granted, I haven't actually tried Bitbucket's Git support yet. But just
>>> yesterday I started the process of converting a couple of my projects
>>> from
>>> SVN/Dsource to Git/Bitbucket, so we'll see how it goes, and I'll let you
>>> know.
>>
>> I'm asking you since you're the main contributor next to me. I prefer
>> Github, many D project are moving to Github, DMD, Phobos and druntime are
>> already there. But certainly don't want to push you away, that wouldn't be
>> good for the Windows port :)
>>
>
> While I would find github more painful, it wouldn't make me decrease my
> contributions to DVM. DVM's too important a tool, IMO (Much like RDMD, which
> I also contribute too).

I'm glad to hear to. I'll have to think about it then.

> Heck, maybe if we're lucky that OSX desktop interface to github will someday
> get ported to Lin or Win :)
>
> I'm on my way to bed so I'll check out those links later. (FWIW, I don't
> think Ruby's all that bad as far as dynamic langauges go. Probably one of
> the best, actually. It's just no D ;) )

Hehe, ok.

-- 
/Jacob Carlborg
January 13, 2012
Nick,

'scuse me butting in...

On Mon, 2012-01-09 at 04:14 -0500, Nick Sabalausky wrote: [...]
> Heck, maybe if we're lucky that OSX desktop interface to github will someday get ported to Lin or Win :)
[...]

Is there any need for a GUI to GitHub?  Isn't having a GUI for the local clone all you need along with the browser UI to GitHub?  Using remote tracking branches allows almost all activity other than pull requests to be done locally with gitg or somesuch.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


January 13, 2012
On 2012-01-13 10:58, Russel Winder wrote:
> Nick,
>
> 'scuse me butting in...
>
> On Mon, 2012-01-09 at 04:14 -0500, Nick Sabalausky wrote:
> [...]
>> Heck, maybe if we're lucky that OSX desktop interface to github will someday
>> get ported to Lin or Win :)
> [...]
>
> Is there any need for a GUI to GitHub?  Isn't having a GUI for the local
> clone all you need along with the browser UI to GitHub?  Using remote
> tracking branches allows almost all activity other than pull requests to
> be done locally with gitg or somesuch.
>

I have never had a use for a GUI for git.

-- 
/Jacob Carlborg
January 13, 2012
On 09/01/12 13:09, Jacob Carlborg wrote:
> On 2012-01-09 10:30, Don Clugston wrote:
>> On 06/01/12 22:29, Jacob Carlborg wrote:
>>> I just released a new version of DVM, 0.4.0. The only thing new in this
>>> release in the "compile" command. This allows to compile DMD, druntime
>>> and Phobos from github. Create a folder, clone DMD, druntime and Phobos
>>> in the newly create folder, run "dvm compile folder" to compile
>>> everything. The compiler is placed in the DMD directory.
>>>
>>> For installation instructions see: https://bitbucket.org/doob/dvm
>>>
>>> Changelog:
>>>
>>> Version 0.4.0
>>> New/Change Features
>>> * Added a "compile" command for compiling DMD, druntime and Phobos from
>>> github
>>>
>> I found that I needed to do:
>> cd .dvm
>> mkdir bin
>> before dvm install would work.
>
> Hmm, that's strange. On which platform? Is it when installing DVM itself
> or compilers?

Linux64 (Ubuntu). When installing compilers.


January 13, 2012
On 2012-01-13 16:53, Don Clugston wrote:
> On 09/01/12 13:09, Jacob Carlborg wrote:
>> On 2012-01-09 10:30, Don Clugston wrote:
>>> On 06/01/12 22:29, Jacob Carlborg wrote:
>>>> I just released a new version of DVM, 0.4.0. The only thing new in this
>>>> release in the "compile" command. This allows to compile DMD, druntime
>>>> and Phobos from github. Create a folder, clone DMD, druntime and Phobos
>>>> in the newly create folder, run "dvm compile folder" to compile
>>>> everything. The compiler is placed in the DMD directory.
>>>>
>>>> For installation instructions see: https://bitbucket.org/doob/dvm
>>>>
>>>> Changelog:
>>>>
>>>> Version 0.4.0
>>>> New/Change Features
>>>> * Added a "compile" command for compiling DMD, druntime and Phobos from
>>>> github
>>>>
>>> I found that I needed to do:
>>> cd .dvm
>>> mkdir bin
>>> before dvm install would work.
>>
>> Hmm, that's strange. On which platform? Is it when installing DVM itself
>> or compilers?
>
> Linux64 (Ubuntu). When installing compilers.

Thanks, I'll take care of it.

-- 
/Jacob Carlborg