DMD 1.038/1.039 slowness is still there in DMD 1.040.

A 1 minute build with 1.037 turns into
a >12 minute build with 1.040 (not sure how long exactly, I got bored
waiting to send this email)

Also this change:
* Separated bin and lib directories into windows, linux, and osx.

while probably for the better, is likely to break a lot of installers and install instructions that people have written for DMD.

It broke the post-install scripts I always run after installing a new DMD, and means I will need to update the path to DMD in various places.

--bb

Bill Baxter wrote:
> DMD 1.038/1.039 slowness is still there in DMD 1.040.
> 
> A 1 minute build with 1.037 turns into
> a >12 minute build with 1.040 (not sure how long exactly, I got bored
> waiting to send this email)

I don't know why that might be, so I need an example.


> Also this change:
> * Separated bin and lib directories into windows, linux, and osx.
> 
> while probably for the better, is likely to break a lot of installers
> and install instructions that people have written for DMD.
> 
> It broke the post-install scripts I always run after installing a new
> DMD, and means I will need to update the path to DMD in various
> places.

I know and I'm sorry about that, but I don't see a better way moving forward.

On Mon, Feb 16, 2009 at 10:32 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> DMD 1.038/1.039 slowness is still there in DMD 1.040.
>>
>> A 1 minute build with 1.037 turns into
>> a >12 minute build with 1.040 (not sure how long exactly, I got bored
>> waiting to send this email)
>
> I don't know why that might be, so I need an example.

It's still chugging after more than an hour here, but mem use is steady at 143,828K.  So it may just be caught in an infinite loop.

I have a little more time now then when this first came up, so I'll see if I can come up with some kind of repro.

>> Also this change:
>> * Separated bin and lib directories into windows, linux, and osx.
>>
>> while probably for the better, is likely to break a lot of installers and install instructions that people have written for DMD.
>>
>> It broke the post-install scripts I always run after installing a new DMD, and means I will need to update the path to DMD in various places.
>
> I know and I'm sorry about that, but I don't see a better way moving forward.

Maybe just put it in bold or something in the change log? Or put "WARNING:" in front of it?   I saw it there, but it totally did not jump out at me as something meant my normal operating procedures would all be broken.

--bb

On Mon, Feb 16, 2009 at 10:43 AM, Bill Baxter <wbaxter@gmail.com> wrote:
>
> I have a little more time now then when this first came up, so I'll see if I can come up with some kind of repro.

Damnit.  I gotta stop reading the internet.
That should be "a little more time now *than* when this first came up".

--bb

On Mon, Feb 16, 2009 at 10:32 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> DMD 1.038/1.039 slowness is still there in DMD 1.040.
>>
>> A 1 minute build with 1.037 turns into
>> a >12 minute build with 1.040 (not sure how long exactly, I got bored
>> waiting to send this email)
>
> I don't know why that might be, so I need an example.

Was this report no help?

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

--bb

Bill Baxter wrote:
> On Mon, Feb 16, 2009 at 10:32 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> DMD 1.038/1.039 slowness is still there in DMD 1.040.
>>>
>>> A 1 minute build with 1.037 turns into
>>> a >12 minute build with 1.040 (not sure how long exactly, I got bored
>>> waiting to send this email)
>> I don't know why that might be, so I need an example.
> 
> Was this report no help?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=2582

A smaller one would be much better.

On Mon, Feb 16, 2009 at 11:37 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> On Mon, Feb 16, 2009 at 10:32 AM, Walter Bright <newshound1@digitalmars.com> wrote:
>>>
>>> Bill Baxter wrote:
>>>>
>>>> DMD 1.038/1.039 slowness is still there in DMD 1.040.
>>>>
>>>> A 1 minute build with 1.037 turns into
>>>> a >12 minute build with 1.040 (not sure how long exactly, I got bored
>>>> waiting to send this email)
>>>
>>> I don't know why that might be, so I need an example.
>>
>> Was this report no help?
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=2582
>
> A smaller one would be much better.

Do you have a way to build dmd with debugging symbols that MSVC can read, and if so would it help to get a stack trace of the place where it's stuck?

--bb

>> Also this change:
>> * Separated bin and lib directories into windows, linux, and osx.
>>
>> while probably for the better, is likely to break a lot of installers
>> and install instructions that people have written for DMD.
>>
>> It broke the post-install scripts I always run after installing a new
>> DMD, and means I will need to update the path to DMD in various
>> places.
>
> I know and I'm sorry about that, but I don't see a better way moving forward.

I think you should have left the bin and lib folders, and instead make the OS folders subfolders of bin and lib. It seems odd to me mixing OS-names with the other categories.

L. 

On 16.02.2009 05:39, Lionello Lunesu wrote:
>>>  Also this change:
>>>  * Separated bin and lib directories into windows, linux, and osx.
>>>
>>>  while probably for the better, is likely to break a lot of installers
>>>  and install instructions that people have written for DMD.
>>>
>>>  It broke the post-install scripts I always run after installing a new
>>>  DMD, and means I will need to update the path to DMD in various
>>>  places.
>>
>>  I know and I'm sorry about that, but I don't see a better way moving
>>  forward.
>
> I think you should have left the bin and lib folders, and instead make the
> OS folders subfolders of bin and lib. It seems odd to me mixing OS-names
> with the other categories.
>

I like the layout, makes it easier to know and delete what you don't need on your system.

Bill Baxter wrote:
> Do you have a way to build dmd with debugging symbols that MSVC can
> read, and if so would it help to get a stack trace of the place where
> it's stuck?

I emailed one to you. You can use windbg.exe on it (I do).