On 08/11/2010 04:15 PM, Walter Bright wrote:
>
> This is probably the last FreeBSD 7 release for D1. The next will be for
> FreeBSD 8!
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.063.zip
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.048.zip

Hi,

  Congratulations for this release! This time it really made a difference when i switched from 2.0.46. The framerate of my app used to degenerate with time very quickly and now it remains fast and stable!

  Maybe some of the many fixes helped the garbage collector?

  Congratulations again.

j.

== Quote from Jordi (jordi@rovira.cat)'s article
> On 08/11/2010 04:15 PM, Walter Bright wrote:
> >
> > This is probably the last FreeBSD 7 release for D1. The next will be for FreeBSD 8!
> >
> > http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.063.zip
> >
> > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.048.zip
> Hi,
>    Congratulations for this release! This time it really made a
> difference when i switched from 2.0.46. The framerate of my app used to
> degenerate with time very quickly and now it remains fast and stable!
>    Maybe some of the many fixes helped the garbage collector?
>    Congratulations again.
> j.

Probably the GC.minimize() patch.  Previously the GC would **never** give memory back to the OS.  In addition to the obvious reason, this is bad because the GC is currently not well optimized and slows down a lot when the heap gets large, even if most of it doesn't contain pointers and isn't scanned.

On 08/15/2010 01:50 PM, dsimcha wrote:
> == Quote from Jordi (jordi@rovira.cat)'s article
>> On 08/11/2010 04:15 PM, Walter Bright wrote:
>>>
>>> This is probably the last FreeBSD 7 release for D1. The next will be for
>>> FreeBSD 8!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.063.zip
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.048.zip
>> Hi,
>>     Congratulations for this release! This time it really made a
>> difference when i switched from 2.0.46. The framerate of my app used to
>> degenerate with time very quickly and now it remains fast and stable!
>>     Maybe some of the many fixes helped the garbage collector?
>>     Congratulations again.
>> j.
>
> Probably the GC.minimize() patch.  Previously the GC would **never** give memory
> back to the OS.  In addition to the obvious reason, this is bad because the GC is
> currently not well optimized and slows down a lot when the heap gets large, even
> if most of it doesn't contain pointers and isn't scanned.

Great. I always thought i was missing some important point about garbage collection, and i was doing everything wrong. I am used to manage my own memory in C++...

Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 some behaviour has changed in my program. I cannot really make a small reproduction case, because it involves dragging objects around the 3d scene: since 2.0.47 they follow weird curved paths instead of moving correctly on the camera plane.

The code that calculate that (which is not new) just uses matrix and vector operations to project and unproject positions, but i cannot really find where do the numbers start to go wrong.

j.

"Jordi" <jordi@rovira.cat> wrote in message news:i48n8t$1jv$1@digitalmars.com...
> On 08/15/2010 01:50 PM, dsimcha wrote:
>> == Quote from Jordi (jordi@rovira.cat)'s article
>>> On 08/11/2010 04:15 PM, Walter Bright wrote:
>>>>
>>>> This is probably the last FreeBSD 7 release for D1. The next will be
>>>> for
>>>> FreeBSD 8!
>>>>
>>>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.063.zip
>>>>
>>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.048.zip
>>> Hi,
>>>     Congratulations for this release! This time it really made a
>>> difference when i switched from 2.0.46. The framerate of my app used to
>>> degenerate with time very quickly and now it remains fast and stable!
>>>     Maybe some of the many fixes helped the garbage collector?
>>>     Congratulations again.
>>> j.
>>
>> Probably the GC.minimize() patch.  Previously the GC would **never** give
>> memory
>> back to the OS.  In addition to the obvious reason, this is bad because
>> the GC is
>> currently not well optimized and slows down a lot when the heap gets
>> large, even
>> if most of it doesn't contain pointers and isn't scanned.
>
> Great. I always thought i was missing some important point about garbage collection, and i was doing everything wrong. I am used to manage my own memory in C++...
>
> Anyway, i had to roll back to 2.0.46 as i have seen that from 2.0.47 some behaviour has changed in my program. I cannot really make a small reproduction case, because it involves dragging objects around the 3d scene: since 2.0.47 they follow weird curved paths instead of moving correctly on the camera plane.
>
> The code that calculate that (which is not new) just uses matrix and vector operations to project and unproject positions, but i cannot really find where do the numbers start to go wrong.
>

This may be a pain to do, but you could narrow it down from the other direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 and see which actual commit created the problem.

Nick Sabalausky wrote:
> This may be a pain to do, but you could narrow it down from the other direction: recompile DMD from varius trunk revisions between 2.046 and 2.047 and see which actual commit created the problem.

Try mixing/matching the compiler & Phobos to see which one of those caused the issue.

On 8/15/2010 12:54 PM, Walter Bright wrote:
> Nick Sabalausky wrote:
>> This may be a pain to do, but you could narrow it down from the other direction: recompile DMD from various trunk revisions between 2.046 and 2.047 and see which actual commit created the problem.
> 
> Try mixing/matching the compiler & Phobos to see which one of those caused the issue.

While I agree that it's worth trying a bisection -- it's generally really quick
and easy to do (the compiler and libraries build rather fast -- about a minute
for me).  It can be a very useful technique for finding where bugs were introduced.

That said, it's likely to be rather difficult for this release due to the number of fixes in the compiler that the library requires and for the periods during which the two didn't work together.

Do try it.. worst case is you've wasted a little bit of time.  Best case you've found the cause of the bug.

Later,
Brad

Brad Roberts wrote:
> On 8/15/2010 12:54 PM, Walter Bright wrote:
>> Nick Sabalausky wrote:
>>> This may be a pain to do, but you could narrow it down from the other
>>> direction: recompile DMD from various trunk revisions between 2.046 and 2.047
>>> and see which actual commit created the problem.
>> Try mixing/matching the compiler & Phobos to see which one of those caused the
>> issue.
> 
> While I agree that it's worth trying a bisection -- it's generally really quick
> and easy to do (the compiler and libraries build rather fast -- about a minute
> for me).  It can be a very useful technique for finding where bugs were introduced.
> 
> That said, it's likely to be rather difficult for this release due to the number
> of fixes in the compiler that the library requires and for the periods during
> which the two didn't work together.
> 
> Do try it.. worst case is you've wasted a little bit of time.  Best case you've
> found the cause of the bug.
> 
> Later,
> Brad

The latest compiler should work with the old Phobos, except that it will complain about the a&b==c bugs. That's simple to do, it just involves copying the 2.048 compiler onto the 2.047 release. Knowing if it is the compiler or Phobos/druntime would be an enormous help.

On 08/16/2010 04:11 PM, Don wrote:
> Brad Roberts wrote:
>> On 8/15/2010 12:54 PM, Walter Bright wrote:
>>> Nick Sabalausky wrote:
>>>> This may be a pain to do, but you could narrow it down from the other
>>>> direction: recompile DMD from various trunk revisions between 2.046
>>>> and 2.047
>>>> and see which actual commit created the problem.
>>> Try mixing/matching the compiler & Phobos to see which one of those
>>> caused the
>>> issue.
>>
>> While I agree that it's worth trying a bisection -- it's generally
>> really quick
>> and easy to do (the compiler and libraries build rather fast -- about
>> a minute
>> for me). It can be a very useful technique for finding where bugs were
>> introduced.
>>
>> That said, it's likely to be rather difficult for this release due to
>> the number
>> of fixes in the compiler that the library requires and for the periods
>> during
>> which the two didn't work together.
>>
>> Do try it.. worst case is you've wasted a little bit of time. Best
>> case you've
>> found the cause of the bug.
>>
>> Later,
>> Brad
>
> The latest compiler should work with the old Phobos, except that it will
> complain about the a&b==c bugs. That's simple to do, it just involves
> copying the 2.048 compiler onto the 2.047 release. Knowing if it is the
> compiler or Phobos/druntime would be an enormous help.

Found it. It took me 7 iterations of binary search across the svn repositories for dmd, druntime and phobos. The commit causing the issue is 505 in dmd. It is related to structs returning *this, which indeed i do in my maths structs.

Now, i don't know if the bug is in dmd or in my code, but i suspect that something is being treated as a reference when it shouldn't. Should i add an issue even if i am not sure?

j.

Michal Minich wrote:
> On Wed, 11 Aug 2010 17:34:20 -0400, Sean Kelly wrote:
> 
>> Michal Minich Wrote:
>>
>>> On Wed, 11 Aug 2010 16:29:40 +0000, Michal Minich wrote:
>>>
>>>> Module constructor is not called when it is placed in imported
>>>> module, and WinMain is used.
>>> Are there some changes to runtime initialization, or it is a bug? (in
>>> that case I will submit it).
>> There were some changes and I must have missed updating rt_init(). Please submit a bug.  What you'll likely see is shared static ctors
>> being called but not thread-specific (ie. non-shared) static ctors
>> called for the main thread.
> 
> bug report:
> http://d.puremagic.com/issues/show_bug.cgi?id=4622

Fixed:

http://www.dsource.org/projects/druntime/changeset/368

Jordi wrote:
> Found it. It took me 7 iterations of binary search across the svn repositories for dmd, druntime and phobos. The commit causing the issue is 505 in dmd. It is related to structs returning *this, which indeed i do in my maths structs.
> 
> Now, i don't know if the bug is in dmd or in my code, but i suspect that something is being treated as a reference when it shouldn't. Should i add an issue even if i am not sure?

Try to reduce it to the smallest possible reproducible test case, and then post it to bugzilla.