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 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 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
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
next sibling parent reply "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
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
prev sibling next sibling 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 "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 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 parent reply 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
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 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 reply "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
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