Move VisualD to github/d-programming-language ? (page 9)

On 09/09/13 16:06, Ramon wrote: > Wow. So many people turning so many circles around so little as "ze" instead of > "ws". Why is a little "ze" as opposed to a "ws" so important to you that you choose to persist in using it even though lots of people have suggested to you that it's impolite?

On 9 September 2013 23:53, Walter Bright <newshound2@digitalmars.com> wrote: > On 9/8/2013 10:05 PM, Andrei Alexandrescu wrote: > >> I think we should use the D mainline bug flow for VisualD, effectively >> vaulting >> VisualD into a first-class component of the D language. >> >> This opens the door to other projects as well - e.g. emacs and vim >> integration >> helpers. >> > > VisualD is now a component on Bugzilla, so Manu can start reporting bugs there! > Another thought... what do you reckon about including Visual-D as an optional component in the windows DMD installer? One-click install that includes an environment for windows users would probably kick-start a lot of users. It can also simplify the Visual-D installation, which expects you to have pre-installed DMD, and prompts for the path to the exe. Since this is known during the DMD installer, it removes a few steps from the install process.

On 9/9/2013 7:55 AM, Manu wrote: > Another thought... what do you reckon about including Visual-D as an optional > component in the windows DMD installer? > One-click install that includes an environment for windows users would probably > kick-start a lot of users. > It can also simplify the Visual-D installation, which expects you to have > pre-installed DMD, and prompts for the path to the exe. Since this is known > during the DMD installer, it removes a few steps from the install process. Yes, we can start working towards that.

On Sunday, 8 September 2013 at 11:48:06 UTC, Paulo Pinto wrote: > Am 08.09.2013 13:24, schrieb Russel Winder: >> On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote: >> […] >> >> And why is the target audience for D only C and C++ people? Surely the >> target audience for D is any programmer wanting a native code >> executable. >> > > Because many of us are actually aware of compilers that produce native code for our languages, even if they are not the default way to use them. If you're used to using an IDE, let's say IntelliJ for Java, and you may also want to develop in D, why shouldn't you be able to use that IDE, and not context switch? There may be more of a market for Java/Python/whatever programmers interested in D than you think. > To make it more clear, the ML family of languages, Pascal family of > languages, even JVM and .NET environments have native compilers available. You just have to look for them. IMO, D has more potential as a native code compilation target than Java, C#, and ML, at least in theory, because I should be able to control and even disable garbage collection. So, even users of managed languages may want to examine D. -- Brian

Am 09.09.2013 10:29, schrieb Russel Winder: > On Sun, 2013-09-08 at 23:00 +0200, Ramon wrote: >> Just for the sake of completeness: >> >> mono is *detested* and considered even more inacceptable than >> java by many linux and (even more) *BSD users. > > It also appears that Microsoft are beginning to think the whole CLR > thing is on it's last legs. > > The whole "all non-Windows users have to hate C#" thing has some basis > in fact but also had a lot of FUD associated with it. The "Mono hatred" > stemmed from that. So will Microsoft go after Mono with patent suits if > they are not themselves using C# and CLR? They possibly might as an > income stream, but it is unlikely to be profitable and so may be not. > > Without solid support from Microsoft the C#F#/CLR culture is unlikely to > remain strong, despite the serious success F# has had in making people > interested in CLR. And C# is not a bad language, in many ways much > better than Java. But Java has staying power in ways C#/F# do not. > ... I wonder where you got this idea from. .NET is pretty strong at Microsoft conferences, even this year BUILD had lots of new goodies announced. They can decide to target the WinRT runtime instead of the CLR, go fully native instead of generating MSIL bytecodes, or keep using CLR. There are lots of options still open and as someone that is active in both JVM and .NET worlds, I don't see .NET slowing down in the enterprise space. Pretty much the contrary actually, looking at the requests for proposals my employer receives. -- Paulo

On 9/9/13 2:13 AM, Russel Winder wrote: > On Mon, 2013-09-09 at 01:43 -0700, Andrei Alexandrescu wrote: > […] >> I see no problem with making it a repo under the D-programming-language org. > > As long as 1 of the 21 members of the organization will take on the > responsibility for it then fine, go with it. Then we can delete the > Emacs-D-Mode-Maintainers group. > > We'll need to update the MELPA entry so the pulls come from the new > repository. > > We'll also have to amend Launchpad stuff as well. OK, so what's the next step? To whom should we talk? Could you carry the message? Andrei

September 09, 2013

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

Posted by Russel Winder

Permalink

Russel Winder

Attachments:

signature.asc (This is a digitally signed message part)

Permalink

On Mon, 2013-09-09 at 11:38 +0200, Joseph Rushton Wakeling wrote: […]
> If it's Emacs stuff, shouldn't it be versioned in bzr? :-)

It used to be, but a decision was made that it should be in the VCS of D rather than the VCS of Emacs. Given MELPA copes with Git and Bazaar, this turned into a free-choice.

[…]
> I don't see that necessarily needs to be so.  Different projects should be able to have different gatekeepers/maintainers.  If that's problematic, if GitHub won't support separate maintainer groups for different repositories of D-Programming-Language, there are probably other ways round it -- e.g. the maintainers could have a separate project branch, and the D-Programming-Language repo could auto-pull from it (and never be pushed to directly).

As far as I am aware there is no concept of distinct and separately managed "sub-organization". So if a repository is owned by an organization only members of that organization have write permission. Or can the write permissions be managed per repository so that additional individual write members are allowed per repository. If the latter is possible it solves all the problems I am concerned over.

I think we need to keep the repositories simple with branches only for feature work and maintenance work. Having branches for internal management would just indicate an inability of GitHub to handle the workflow.

> Also, so long as everyone is trustworthy and limits their activity to their sphere of responsibility, there's no reason why you shouldn't just have a large maintainer group.  If you can't trust maintainer-of-project-X to only use admin powers for project X, and not for project Y as well, then why is he/she maintainer of project X in the first place?

There is that :-)

-- 
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@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 09/09/13 19:29, Russel Winder wrote: > On Mon, 2013-09-09 at 11:38 +0200, Joseph Rushton Wakeling wrote: > […] >> If it's Emacs stuff, shouldn't it be versioned in bzr? :-) > > It used to be, but a decision was made that it should be in the VCS of D > rather than the VCS of Emacs. Given MELPA copes with Git and Bazaar, > this turned into a free-choice. Actually this was just a shout-out to a few years back when we were both fairly active members of the bzr mailing list :-) I do still follow it, but I think sadly you are now one of the few remaining active list members ... ?

Forums