www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Visual D 0.3.32 maintenance release

reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

A new version of Visual D has just been released. It does not include 
major new features, but it addresses a number of issues and 
improvements. A reduced list of changes:

2012-05-01 Version 0.3.32

   * new version of cv2pdb with better handling of unicode characters in 
path names and better support for local variables in DWARF debug info
   * new version of mago with string literal support for associative 
array keys and easier stepping into main
   * some changes to reduce memory leaks due to false pointers
   * fixed some issues in the parser and lexer, added support for 
__vector(T)
   * goto definition: if executed on an import statement, now searching 
file through import paths
   * project properties: added output type DLL and subsystem option
   * fixed underlining syntax errors showing only first error
   * version highlighting now supports versions DigitalMars/GNU and 
Win32/Win64

The full list of changes is at 
http://www.dsource.org/projects/visuald/wiki/VersionHistory

Visual D is a Visual Studio package providing both project management 
and language services for the D programming language. It works with 
Visual Studio 2005-11 as well as the free Visual Studio Shells.

The Visual D installer can be downloaded from its website at 
http://www.dsource.org/projects/visuald

Rainer
May 01 2012
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 1 May 2012 at 16:46:36 UTC, Rainer Schuetze wrote:
   * goto definition: if executed on an import statement, now 
 searching file through import paths

Thanks, I remember trying this before, good to know it now does the intuitive thing :)
May 01 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?
May 11 2012
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I considered that aswell recently, but I'm not yet convinced. I see the increase in contributions to dmd after the move to github, but my own experience with it has not been too positive: making patches for dmd is rather time consuming, I always have to struggle to get the simple stuff done (while it was just adding a diff to the bugzilla in the subversion times). As a result, the number of patches that I have provided has dropped considerably. My feeling is that git allows a lot of complex things at the cost of making standard operations much more complicated than necessary. Using git/github is probably less work for you compared to svn, but this also depends on a rather large infrastructure like the auto tester. I'm not sure it does actually help for a project with very few contributors. There haven't been a lot of community contributions to Visual D so far. To everybody interested: Would a move to github change that? Rainer
May 13 2012
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
resending due to NNTP error, sorry if it causes duplicates.

On 5/13/2012 2:01 PM, Jonathan M Davis wrote:
 On Sunday, May 13, 2012 13:48:39 Rainer Schuetze wrote:
 On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I considered that aswell recently, but I'm not yet convinced. I see the increase in contributions to dmd after the move to github, but my own experience with it has not been too positive: making patches for dmd is rather time consuming, I always have to struggle to get the simple stuff done (while it was just adding a diff to the bugzilla in the subversion times). As a result, the number of patches that I have provided has dropped considerably. My feeling is that git allows a lot of complex things at the cost of making standard operations much more complicated than necessary. Using git/github is probably less work for you compared to svn, but this also depends on a rather large infrastructure like the auto tester. I'm not sure it does actually help for a project with very few contributors. There haven't been a lot of community contributions to Visual D so far. To everybody interested: Would a move to github change that?

You actually find patches to be easier than using github? That strikes me as odd. I've always found patches to be a pain to deal with and git and github have been really easy overall. You just make your changes on another branch, push them up to github, and then create a pull request. If you're the one merging in the changes, it's as easy as pushing the "merge" button the pull request, and it's in the main repository. Now, I don't deal with Visual D at all (I'm always on Linux, if nothing else), so I wouldn't be a contributor, and I have no idea if very many more people would be contribute if it were on github, but I'd definitely expect it to be easier for people to contribute if it were up on github than it would be for them to create patches and send those to you. - Jonathan M Davis

The problem is that I need/want to use a branch of dmd that incorporates a number of patches, and that is where I start making additional changes. To send a pull request, I have to create a new branch, copy the changes into it, push it and make the pull request. I have created a batch to do that, but every other pull request something breaks and I start cursing... With the workflow of bugzilla/svn it was just copy and pasting the diff into the bug report. I understand it is easier on Walter's side, though.
May 13 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 5/13/12 7:31 PM, Rainer Schuetze wrote:
 resending due to NNTP error, sorry if it causes duplicates.

 On 5/13/2012 2:01 PM, Jonathan M Davis wrote:
 On Sunday, May 13, 2012 13:48:39 Rainer Schuetze wrote:
 On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I considered that aswell recently, but I'm not yet convinced. I see the increase in contributions to dmd after the move to github, but my own experience with it has not been too positive: making patches for dmd is rather time consuming, I always have to struggle to get the simple stuff done (while it was just adding a diff to the bugzilla in the subversion times). As a result, the number of patches that I have provided has dropped considerably. My feeling is that git allows a lot of complex things at the cost of making standard operations much more complicated than necessary. Using git/github is probably less work for you compared to svn, but this also depends on a rather large infrastructure like the auto tester. I'm not sure it does actually help for a project with very few contributors. There haven't been a lot of community contributions to Visual D so far. To everybody interested: Would a move to github change that?

You actually find patches to be easier than using github? That strikes me as odd. I've always found patches to be a pain to deal with and git and github have been really easy overall. You just make your changes on another branch, push them up to github, and then create a pull request. If you're the one merging in the changes, it's as easy as pushing the "merge" button the pull request, and it's in the main repository. Now, I don't deal with Visual D at all (I'm always on Linux, if nothing else), so I wouldn't be a contributor, and I have no idea if very many more people would be contribute if it were on github, but I'd definitely expect it to be easier for people to contribute if it were up on github than it would be for them to create patches and send those to you. - Jonathan M Davis

The problem is that I need/want to use a branch of dmd that incorporates a number of patches, and that is where I start making additional changes. To send a pull request, I have to create a new branch, copy the changes into it, push it and make the pull request. I have created a batch to do that, but every other pull request something breaks and I start cursing... With the workflow of bugzilla/svn it was just copy and pasting the diff into the bug report. I understand it is easier on Walter's side, though.

But where did you get the diff from? I'm sure you checked out the project and made the changes on it. If that's the case, then it's the same as forking and cloning. I *do* expect contributions to appear in Visual D. Since it's so easy to contribute in github, and it is standarized: people know how to do it: fork, work, make a pull request (as opposed to making a patch, sending it... mmm... is that the author's email? I hope it does work. And I hope it checks emails and mine doesn't go to the spam folder! Um, maybe I should post in the forums... but does he read them? Ah, maybe I will leave the patch for another day).
May 13 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 5/13/2012 3:25 PM, Ary Manzana wrote:
 On 5/13/12 7:31 PM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side, though.

But where did you get the diff from? I'm sure you checked out the project and made the changes on it. If that's the case, then it's the same as forking and cloning.

With small patches to a single file (which is what most patches are), it was just the diff to the svn working base that you could copy and paste from a shell context menu command. You could even adjust the diff manually to filter out other unrelated changes. With pull requests you have to redo the patch on a clean branch of the full source tree. Maintaining larger patches did get messy, though.
 I *do* expect contributions to appear in Visual D. Since it's so easy to
 contribute in github, and it is standarized: people know how to do it:
 fork, work, make a pull request (as opposed to making a patch, sending
 it... mmm... is that the author's email? I hope it does work. And I hope
 it checks emails and mine doesn't go to the spam folder! Um, maybe I
 should post in the forums... but does he read them? Ah, maybe I will
 leave the patch for another day).

Well, the bug-tracking system is/was probably the right place. But I agree, the infrastructure provided by github is very impressive and might be more attractive to contributors.
May 13 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side, though.

Yes, it is definitely easier on my side. But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.
May 13 2012
parent reply Don Clugston <dac nospam.com> writes:
On 13/05/12 21:28, Walter Bright wrote:
 On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side, though.

Yes, it is definitely easier on my side. But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.

As I've said before -- that is true for DMD but not for Phobos. Rate of contributions to Phobos is basically the same as when it was in svn. Would be good to know why.
May 24 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 5/24/12 20:30 , Don Clugston wrote:
 On 13/05/12 21:28, Walter Bright wrote:
 On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side, though.

Yes, it is definitely easier on my side. But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.

As I've said before -- that is true for DMD but not for Phobos. Rate of contributions to Phobos is basically the same as when it was in svn. Would be good to know why.

Maybe they are afraid to contribute.
May 24 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2012 10:41 AM, Brad Roberts wrote:
 Also, for what it's worth, a project with
 multiple contributors are is much more likely to survive for the long haul
than a one man project.

A number of great projects still "die on the vine". The problem is, it's not enough to create a great project. You've got to flog it. All successful businesses know this - they have huge marketing & promotion efforts. Consider the ipad. Is it so great that Apple doesn't need to do any marketing or promotion? Maybe, but there's no way in hell Apple is going to take such a risk. I see Apple promotion for it everywhere. Flogging it would be things like: 1. Writing articles about it. 2. Doing presentations on it. 3. Keeping an eye on the forums, newsgroups, reddit, etc., for opportunities to mention it. 4. Google has a feature where they'll email you links to any new hits on a search topic. It's a great way to find other articles on your products, or related ones. 5. Writing tutorials about it. 6. Having some decent web site for it. For example, coming to the D Conference in September and doing a presentation/workshop on it! Fortunately, the above doesn't cost money, but it does cost significant time. But look at it this way - if you aren't willing to flog it, then the time you invest in developing it is likely wasted, unless you're lucky enough that another champion emerges to do it for you.
May 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, May 13, 2012 13:48:39 Rainer Schuetze wrote:
 On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I considered that aswell recently, but I'm not yet convinced. I see the increase in contributions to dmd after the move to github, but my own experience with it has not been too positive: making patches for dmd is rather time consuming, I always have to struggle to get the simple stuff done (while it was just adding a diff to the bugzilla in the subversion times). As a result, the number of patches that I have provided has dropped considerably. My feeling is that git allows a lot of complex things at the cost of making standard operations much more complicated than necessary. Using git/github is probably less work for you compared to svn, but this also depends on a rather large infrastructure like the auto tester. I'm not sure it does actually help for a project with very few contributors. There haven't been a lot of community contributions to Visual D so far. To everybody interested: Would a move to github change that?

You actually find patches to be easier than using github? That strikes me as odd. I've always found patches to be a pain to deal with and git and github have been really easy overall. You just make your changes on another branch, push them up to github, and then create a pull request. If you're the one merging in the changes, it's as easy as pushing the "merge" button the pull request, and it's in the main repository. Now, I don't deal with Visual D at all (I'm always on Linux, if nothing else), so I wouldn't be a contributor, and I have no idea if very many more people would be contribute if it were on github, but I'd definitely expect it to be easier for people to contribute if it were up on github than it would be for them to create patches and send those to you. - Jonathan M Davis
May 13 2012
prev sibling next sibling parent "alex" <info alexanderbothe.com> writes:
 There haven't been a lot of community contributions to Visual D 
 so far. To everybody interested: Would a move to github change 
 that?

Sending pull requests to the project owner is made significantly easier, but my experience was that there won't be an enormous increase of contributions - nevertheless it's made easier if there are some willed contributors. The issue board is also great for community interaction, if you haven't noticed it already. :)
May 13 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 5/13/2012 4:48 AM, Rainer Schuetze wrote:
 Using git/github is probably less work for you compared to svn, but this also
depends on a rather large infrastructure
 like the auto tester. I'm not sure it does actually help for a project with
very few contributors.

Neither github nor git made the auto-tester necessary. The volume of contributions did. With SVN they came in via bugzilla and github via pull requests. The ease of automation via the github apis and the dramatic increase in volume of contributions lead to implementing the tester. I likely would have written it (or found one to install) for svn/bugzilla eventually too, but it would have been a bigger job. Anyway, the choice of where you host your project very much is yours. But I can agree with the others, evidence from both dmd/druntime/phobos as well as other projects I'm a part of clearly shows that you'll get more with github than dsource, regardless of svn vs git. And you'll get more with git than svn. Also, for what it's worth, a project with multiple contributors are is much more likely to survive for the long haul than a one man project. My 2 cents, Brad
May 13 2012
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I will give it a try...
May 13 2012
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 5/14/2012 8:40 AM, Rainer Schuetze wrote:
 On 5/11/2012 9:49 PM, Walter Bright wrote:
 On 5/1/2012 9:46 AM, Rainer Schuetze wrote:
 The Visual D installer can be downloaded from its website at
 http://www.dsource.org/projects/visuald

Can you please move it to github?

I will give it a try...

After a number of WTF moments, it's finally available: https://github.com/rainers/visuald Let them pull requests keep comin'! (But please be patient, I will have to learn the procedures). Rainer
Jun 05 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 6/27/2012 8:39 PM, Roman D. Boiko wrote:
 On Wednesday, 6 June 2012 at 05:52:00 UTC, Rainer Schuetze wrote:
 After a number of WTF moments, it's finally available:

 https://github.com/rainers/visuald

 Let them pull requests keep comin'! (But please be patient, I will
 have to learn the procedures).

 Rainer

You might be interested in https://github.com/blog/1178-collaborating-on-github-with-subversion if you also plan to preserve subversion for some time.

I tried the migration with keeping svn in sync, but it seemed overkill to me and left to much junk in the github repository. My impression is that git is not the best solution to keeping a history of binary files, so the github repo only covers the trunk containing the sources, no downloads and no pictures used by the website on dsource. I'm just committing manually to both repositories for now, that seems simple enough.
Jul 03 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 24 May 2012 09:30:01 -0400, Don Clugston <dac nospam.com> wrote:

 On 13/05/12 21:28, Walter Bright wrote:
 On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side,  
 though.

Yes, it is definitely easier on my side. But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.

As I've said before -- that is true for DMD but not for Phobos. Rate of contributions to Phobos is basically the same as when it was in svn. Would be good to know why.

Phobos is perfect. :) -Steve
May 24 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 24 May 2012 at 13:30:03 UTC, Don Clugston wrote:
 Would be good to know why.

Probably (warning: unverified hypothesis ahead) because Phobos has much less »clear-cut« bugs – often, it's missing/restricted/clumsy functionality instead of obvious bugs. Also, Bugzilla has something like 4x the number of bugs for DMD compared to Phobos. David
May 24 2012
prev sibling parent "Roman D. Boiko" <rb d-coding.com> writes:
On Wednesday, 6 June 2012 at 05:52:00 UTC, Rainer Schuetze wrote:
 After a number of WTF moments, it's finally available:

 https://github.com/rainers/visuald

 Let them pull requests keep comin'! (But please be patient, I 
 will have to learn the procedures).

 Rainer

You might be interested in https://github.com/blog/1178-collaborating-on-github-with-subversion if you also plan to preserve subversion for some time.
Jun 27 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 05/24/12 15:52, Steven Schveighoffer wrote:
 On Thu, 24 May 2012 09:30:01 -0400, Don Clugston <dac nospam.com> wrote:
 
 On 13/05/12 21:28, Walter Bright wrote:
 On 5/13/2012 5:31 AM, Rainer Schuetze wrote:
 With the workflow of bugzilla/svn it was just copy and pasting the diff
 into the bug report. I understand it is easier on Walter's side, though.

Yes, it is definitely easier on my side. But consider that the number of contributions to dmd has increased by at least a factor of 10 since we moved to github means that, in general, contributors find it easier, too.

As I've said before -- that is true for DMD but not for Phobos. Rate of contributions to Phobos is basically the same as when it was in svn. Would be good to know why.

Phobos is perfect. :)

It's simple - if something doesn't work right in phobos, it gets redone properly in user code, and then that phobos part is not needed anymore, and it's almost never referred to anymore. Compare with compiler problems - the user usually cannot work around bugs or deficiencies, and even when it is possible - it usually carries some kind of cost. So most compiler issues get reported and even sometimes fixed, but this happens much less with the library; there it's easier to just fix/rewrite the broken thing and be done with it. The fact that D's std lib is so tiny, and practically every part of it has several serious design problems (never mind implementation bugs) means it gets used for learning and toy/example "programs". Once you start "real" coding, the std lib might get a chance for some simple noncritical low-pri tasks, such as debugging logs (and note that even that will often backfire), but will rarely, if ever, be used for anything else. When you know you can code a working solution in a few minutes, why risk spending time checking if it exists in phobos, then learning how to use it from usually not very helpful docs, fully realizing that most likely the library implementation will be unusable, either because of a design flaw, bugs or a prohibitively expensive implementation? So paradoxically the low quality and tiny scope of phobos means that it gets less contributions. There are also other issues, like process, that hinder contributions, but those aren't specific to phobos. And the mythical backward compatibility, which - for a niche language with not a single mainstream compiler, not one alternative compiler (backends don't count), no specification and (statistically) no users, that constantly evolves, requiring adjusting code for almost every compiler and library release - is not nearly as important as it is made out to be. IOW it's a chicken-and-egg problem - phobos needs to improve in order to receive a larger amount of improvements. Which is why things like a sane (and open, but that should go w/o saying) development process would make the most difference. But, realistically, even if all such issues would be fixed today, it would still take at least several years before a solid std library would start taking form. [1] artur [1] And what if GDC is merged into GCC during that time? It's not an unlikely scenario and one everyone should hope for. But, in practice, this will mean that DMD is no longer the reference compiler and the std library and runtime are effectively forked. I'd much prefer that as much as possible of the necessary language and stdlib changes to be done while Walter is still in some kind of control. And there are a lot changes left to be done.
May 24 2012