On Wednesday, 6 November 2013 at 14:43:35 UTC, Dicebot wrote:
> Regarding project files - I like Mono-D attempt to support dub package.json as project description file.
>
> Regarding semantical analysis - both Mono-D and VisualD should just merged efforts with DCD, problem solved :)

I dunno, there's probably just a small read method required in order to read .visualdproj files..gonna have a look at it.

On 06/11/2013 14:39, Manu wrote:
> For instance, it seems a shame to have .visualdproj, and .dproj files
> separate and incompatible. .csproj files are the same between VS and MD,
> I wonder if the same is possible for D with collaboration?

The best approach here is to support an IDE-independent project configuration standard. And Dub is a good choice to go with this approach.

-- 
Bruno Medeiros - Software Engineer

On 7 November 2013 02:05, Bruno Medeiros <brunodomedeiros+dng@gmail.com>wrote:

> On 06/11/2013 14:39, Manu wrote:
>
>> For instance, it seems a shame to have .visualdproj, and .dproj files separate and incompatible. .csproj files are the same between VS and MD, I wonder if the same is possible for D with collaboration?
>>
>
> The best approach here is to support an IDE-independent project configuration standard. And Dub is a good choice to go with this approach.


I use premake, but that's not the point.
The point here is that MonoDevelop is a blatant VisualStudio clone, and it
supports VS .sln and .csproj files, it would seem nice to continue that
compatibility between VS and MD for D too. The compilers are the same with
the same features and options, so there's no good reason for the project's
to differ, which are both just xml files, but structured slightly
differently while containing the same settings.

Picking common standard for all possible IDE's scales better than cloning approach of a single one (especially if this one is closed and known of forcing closed ecosystems)

On Wednesday, 6 November 2013 at 17:49:57 UTC, Dicebot wrote:
> Picking common standard for all possible IDE's scales better than cloning approach of a single one (especially if this one is closed and known of forcing closed ecosystems)

Essentially, dub.

I'm okay with that decision :-P

On 06.11.2013 09:25, Alexander Bothe wrote:
> On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote:
>> Note: I saw Alexander Bothe released an update to the parser one day
>> after
>> your release... ;)
>
> Sure, there have been a couple of critical regression bugs in the parser
> engine.
> Furthermore, I re-enabled the ufcs completion.
>
> Rainer, I somehow really recommend to provide a more frequent way to
> update the D_Parser.dll - just to provide a way to fix e.g. completion
> issues without having to recompile/package/upload the entire VisualD setup.
>
> An automated build system which simply calls
> git pull
> and
> xbuild DParser2/DParser2.csproj
> already suffices. I could insert a push hook into the repo which is
> executed then in order to inform the build system to do a rebuild.
>
> It also was possible to execute Unittests first, so in the case that
> there are some regression bugs (as it happened just recently), it simply
> won't be distributed.
>
> Finally, a small webserver providing the built dll (or a zip of it) and
> a check whether there's an update available will passively distribute
> the dll to all clients. Not to forget some security things like hash
> check or encryption etc.

Yeah, being able to get releases out more often, and having bug fixes being tested in the field would be nice. But I think we should not over-engineer things here.
Do you have a web-server that could do the compilation?


>
> Also, the D_Parser.dll could be put into the AppData/Roaming folder, so
> no admin rights are needed for a parser update.

The component being used by Visual D is a local COM server, I'm not sure if it is good to have that in a user folder.


>
> What do you think about this?

On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze wrote:
>
>
> On 06.11.2013 09:25, Alexander Bothe wrote:
>> On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote:
>>> Note: I saw Alexander Bothe released an update to the parser one day
>>> after
>>> your release... ;)
>>
>> Sure, there have been a couple of critical regression bugs in the parser
>> engine.
>> Furthermore, I re-enabled the ufcs completion.
>>
>> Rainer, I somehow really recommend to provide a more frequent way to
>> update the D_Parser.dll - just to provide a way to fix e.g. completion
>> issues without having to recompile/package/upload the entire VisualD setup.
>>
>> An automated build system which simply calls
>> git pull
>> and
>> xbuild DParser2/DParser2.csproj
>> already suffices. I could insert a push hook into the repo which is
>> executed then in order to inform the build system to do a rebuild.
>>
>> It also was possible to execute Unittests first, so in the case that
>> there are some regression bugs (as it happened just recently), it simply
>> won't be distributed.
>>
>> Finally, a small webserver providing the built dll (or a zip of it) and
>> a check whether there's an update available will passively distribute
>> the dll to all clients. Not to forget some security things like hash
>> check or encryption etc.
>
> Yeah, being able to get releases out more often, and having bug fixes being tested in the field would be nice. But I think we should not over-engineer things here.
> Do you have a web-server that could do the compilation?
>
No - I just have got a normal dedicated web-server thingy for php&mysql ^_^

But well, just a very small infrastructure that allows us to update software more often - a couple of hours ago I implemented this new eponymous template syntax..and now you had to release another VisualD to have it in there, right?

>
>>
>> Also, the D_Parser.dll could be put into the AppData/Roaming folder, so
>> no admin rights are needed for a parser update.
>
> The component being used by Visual D is a local COM server, I'm not sure if it is good to have that in a user folder.

Okay, it's probably safer to let the user decide when to update only.

On Saturday, 2 November 2013 at 14:40:56 UTC, Rainer Schuetze wrote:
>
>   * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8, fixes x64 debugger in VS 2012 Shell
>

unfortuantely it doesn't works with VS 2013, it installs and registers with visual studio, but whenever i hit the build or debug it instantly reports "build error" with no info.

Have a look at this and see if that helps. I think I got it working in vs2013 because it was the announcement that it should be working that prompted me to find out why it wasn't.

http://d.puremagic.com/issues/show_bug.cgi?id=11457

On Sunday, 10 November 2013 at 07:13:26 UTC, Nicholas Londey wrote:
> Have a look at this and see if that helps. I think I got it working in vs2013 because it was the announcement that it should be working that prompted me to find out why it wasn't.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11457

i see sc.ini points to x64 vc\bin path, replaced with path to x86 bin and still not works.

p.s. also please fix custom type coloring depending on visual studio style, with dark color scheme custom types(string, object, etc.) is unreadable even on good ips display. i think it would be better to set it to something like light blue as VC does with basic types.