On Tuesday, September 10, 2013 11:54:10 Andrei Alexandrescu wrote:
> Maybe the time has come to discuss that. Should we make dub the official package manager for D?

Fine with me, though we should probably create a new thread for that as a lot of people wouldn't notice it in this thread, which is already fairly long.

- Jonathan M Davis

On 9/9/2013 11:35 AM, Russel Winder wrote:
> C++11 has revitalized C++ in ways that are only just showing themselves.

That's true.

> This is a threat to D gaining traction.

I'm less sure about that. I think it presents an opportunity for us. Driving the C++ resurgence is:

1. demand for high performance computing

2. turning back towards native languages

3. recognition of the value of functional-style programming techniques

4. recognition of the value of safety, encapsulation, etc.

But regarding the latter two points, I don't buy that the new C++ delivers. The classic is a oneliner Andrei wrote:

    void fun() noexcept { throw "so sue me"; }

noexcept means the function doesn't throw any exceptions. But it doesn't check! The above code compiles, and then fails at runtime. The opportunity for D is to deliver what C++ has promised.

On 9/10/2013 11:54 AM, Andrei Alexandrescu wrote:
> Maybe the time has come to discuss that. Should we make dub the official package
> manager for D?

Akk, please start a new thread for that!

On 10.09.2013 20:03, Andrei Alexandrescu wrote:
> On 9/10/13 9:31 AM, Brad Anderson wrote:
>> On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote:
>>> Recent threads here have made it pretty clear that VisualD is a
>>> critical piece of D infrastructure. (VisualD integrated D usage into
>>> Microsoft Visual Studio.)
>>>
>>> Andrei, myself and Rainer (VisualD's champion) are all in agreement on
>>> this.
>>>
>>> What do you think?
>>
>> Since it's official I think it'd be nice to add to the Windows
>> Installer.  I'll get started adding it if you or Andrei give me the go
>> ahead.
>
> Yes please. Make it an opt-out choice.

Alternatively, I could add dmd to the Visual D installer. If the files are actually inside the package, I guess it is a bit easier this way because the Visual D installer does quite a bit of registration and patching.

But both installers use NSIS, so it shouldn't be a big deal to merge them either way.


>
>> Once dub is a bit more mature I think it too should be added to the
>> installer.
>
> That should probably be in all installers.
>
>
> Andrei
>

On Tuesday, 10 September 2013 at 21:25:41 UTC, Walter Bright wrote:
> On 9/9/2013 11:35 AM, Russel Winder wrote:
>> C++11 has revitalized C++ in ways that are only just showing themselves.
>
> That's true.
>
>> This is a threat to D gaining traction.
>
> I'm less sure about that. I think it presents an opportunity for us. Driving the C++ resurgence is:
>
> 1. demand for high performance computing
>
> 2. turning back towards native languages
>
> 3. recognition of the value of functional-style programming techniques
>
> 4. recognition of the value of safety, encapsulation, etc.
>
> But regarding the latter two points, I don't buy that the new C++ delivers. The classic is a oneliner Andrei wrote:
>
>     void fun() noexcept { throw "so sue me"; }
>
> noexcept means the function doesn't throw any exceptions. But it doesn't check! The above code compiles, and then fails at runtime. The opportunity for D is to deliver what C++ has promised.


I think it is better to sell D's capabilities in terms of systems programming scenarios.

Your 1-4 points are already covered by existing languages for traditional line of business applications, specially given the fact that even current VM based languages have native compilers available.

Putted another way, how well do the 1 - 4 bullet points stand against Java/C#/Scala/Clojure native compilers ?

This is why I think the best selling point is systems programming.

--
Paulo

On Wednesday, 11 September 2013 at 06:58:03 UTC, PauloPinto wrote:
> I think it is better to sell D's capabilities in terms of systems programming scenarios.
>
> Your 1-4 points are already covered by existing languages for traditional line of business applications, specially given the fact that even current VM based languages have native compilers available.
>
> Putted another way, how well do the 1 - 4 bullet points stand against Java/C#/Scala/Clojure native compilers ?
>
> This is why I think the best selling point is systems programming.

Music to my ears.

On Wednesday, 11 September 2013 at 06:31:50 UTC, Rainer Schuetze wrote:
>
>
> On 10.09.2013 20:03, Andrei Alexandrescu wrote:
>> On 9/10/13 9:31 AM, Brad Anderson wrote:
>>> On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote:
>>>> Recent threads here have made it pretty clear that VisualD is a
>>>> critical piece of D infrastructure. (VisualD integrated D usage into
>>>> Microsoft Visual Studio.)
>>>>
>>>> Andrei, myself and Rainer (VisualD's champion) are all in agreement on
>>>> this.
>>>>
>>>> What do you think?
>>>
>>> Since it's official I think it'd be nice to add to the Windows
>>> Installer.  I'll get started adding it if you or Andrei give me the go
>>> ahead.
>>
>> Yes please. Make it an opt-out choice.
>
> Alternatively, I could add dmd to the Visual D installer. If the files are actually inside the package, I guess it is a bit easier this way because the Visual D installer does quite a bit of registration and patching.
>
> But both installers use NSIS, so it shouldn't be a big deal to merge them either way.
>
>
>>
>>> Once dub is a bit more mature I think it too should be added to the
>>> installer.
>>
>> That should probably be in all installers.
>>
>>
>> Andrei

I was just going to have the DMD installer download Visual-D's installer and run it.  Seemed like the easiest approach.  This would make it so Visual-D's releases aren't tied to DMD's and people could upgrade Visual-D independently if a new release comes out.  Every release of DMD we'd just update the Visual-D installer URL to match the current release.

On 11.09.2013 18:06, Brad Anderson wrote:
> On Wednesday, 11 September 2013 at 06:31:50 UTC, Rainer Schuetze wrote:
>>
>>
>> Alternatively, I could add dmd to the Visual D installer. If the files
>> are actually inside the package, I guess it is a bit easier this way
>> because the Visual D installer does quite a bit of registration and
>> patching.
>>
>
> I was just going to have the DMD installer download Visual-D's installer
> and run it.  Seemed like the easiest approach.  This would make it so
> Visual-D's releases aren't tied to DMD's and people could upgrade
> Visual-D independently if a new release comes out.  Every release of DMD
> we'd just update the Visual-D installer URL to match the current release.

Ok, that should be fine, too. Does the Installer store the path to the installed DMD somewhere, so that it doesn't need to be entered again in the Visual D installer?

On 10.09.2013 08:49, Rainer Schuetze wrote:
> I'm planning to move the issues from the dsource bug database to
> bugzilla. Does anyone have experience with converting trac issues to
> bugzilla? There are currently 60 open reports (half of them enhancement
> requests), so it should also be possible to do this manually.

I have downloaded the tickets from trac by just getting the html pages and extracted the reports and comments as text. Here is the result of the oldest bug entry when added to bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=11014

Is this format ok? If yes, I can transfer the other 50+ reports in the same way.

On Wednesday, 11 September 2013 at 20:27:57 UTC, Rainer Schuetze wrote:
>
>
> On 11.09.2013 18:06, Brad Anderson wrote:
>> On Wednesday, 11 September 2013 at 06:31:50 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> Alternatively, I could add dmd to the Visual D installer. If the files
>>> are actually inside the package, I guess it is a bit easier this way
>>> because the Visual D installer does quite a bit of registration and
>>> patching.
>>>
>>
>> I was just going to have the DMD installer download Visual-D's installer
>> and run it.  Seemed like the easiest approach.  This would make it so
>> Visual-D's releases aren't tied to DMD's and people could upgrade
>> Visual-D independently if a new release comes out.  Every release of DMD
>> we'd just update the Visual-D installer URL to match the current release.
>
> Ok, that should be fine, too. Does the Installer store the path to the installed DMD somewhere, so that it doesn't need to be entered again in the Visual D installer?

In the registry, yeah. HKEY_LOCAL_MACHINE\SOFTWARE\D\Install_Dir