phobos commit, revision 2028


user: SHOO

msg:
std.datetime: Added benchmark

This function came from std.date.
But now, benchmark returns Ticks[N] and don't use result argument.
I removed need to use GC for by doing it in this way.

http://www.dsource.org/projects/phobos/changeset/2028

On 9/18/2010 4:04 AM, dsource.org wrote:
> phobos commit, revision 2028
> 
> 
> user: SHOO
> 
> msg:
> std.datetime: Added benchmark
> 
> This function came from std.date.
> But now, benchmark returns Ticks[N] and don't use result argument.
> I removed need to use GC for by doing it in this way.
> 
> http://www.dsource.org/projects/phobos/changeset/2028

The win32 phobos tests started failing after this submit.. with an access violation.

http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525

Brad Roberts <braddr at puremagic.com> wrote:
> The win32 phobos tests started failing after this submit.. with an access violation.
> 
> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525

Probably it's related to the executable size.

With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
----------
struct Tuple(Specs...)
{
    pragma(msg, "@@@");
...
----------
Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.

Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!


My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...


Shin

  Yeh, I had experimentally added std.parallelism to my DMD directory
and compiled Phobos and encountered similar things.  When I ran the
unittests for std.parallelism by itself, they passed.  Whenever I ran
them along with the rest of Phobos, there was an access violation
somewhere (I don't know where).  I didn't say anything because I wasn't
sure where the bug was at the time, and didn't have a clue where to
start tracking it down.

On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
> Brad Roberts<braddr at puremagic.com>  wrote:
>> The win32 phobos tests started failing after this submit.. with an access violation.
>>
>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
> Probably it's related to the executable size.
>
> With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
> ----------
> struct Tuple(Specs...)
> {
>      pragma(msg, "@@@");
> ...
> ----------
> Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.
>
> Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!
>
>
> My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...
>
>
> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

I just tried building with link upgraded to the 8.00.7 beta.. no better.

Guys, it's really important that all of these packages continue to build and pass their respective tests.  It seems like we can't go more than a day or so without something new being introduced that breaks something.

I recognize that we're all volunteers here, but please be responsible for making sure your changes don't cause any platform to stop building and passing tests. It might well be that there's a lurking problem that's just surfaced somehow, but the bottom line is that being unable to build and run the tests successfully is a blocker for everyone.

I also recognize that not everyone has access to more than one platform.  That's exactly one of the reasons I setup the auto build/test system.  Hopefully we'll get os/x and freebsd added soon.  Use it.. watch the results.

In case your head has been in the sand, the url:
    http://d.puremagic.com/test-results/

Fix or revert.. file bugs.. figure out work arounds.. but don't leave broken.

Please?

Thanks,
Brad

On 9/18/2010 5:49 PM, David Simcha wrote:
>  Yeh, I had experimentally added std.parallelism to my DMD directory and
> compiled Phobos and encountered similar things.  When I ran the unittests for
> std.parallelism by itself, they passed.  Whenever I ran them along with the rest
> of Phobos, there was an access violation somewhere (I don't know where).  I
> didn't say anything because I wasn't sure where the bug was at the time, and
> didn't have a clue where to start tracking it down.
> 
> On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
>> Brad Roberts<braddr at puremagic.com>  wrote:
>>> The win32 phobos tests started failing after this submit.. with an access violation.
>>>
>>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
>> Probably it's related to the executable size.
>>
>> With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
>> ----------
>> struct Tuple(Specs...)
>> {
>>      pragma(msg, "@@@");
>> ...
>> ----------
>> Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.
>>
>> Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!
>>
>>
>> My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...
>>
>>
>> Shin

  Yea, I'm guilty of breaking the Linux builds.  I think a good
enhancement to your auto testing system would be to have it
automatically nag the Phobos list whenever something breaks (instead of
you doing it manually).  The reasons why things slip through the cracks
seem to be:

1.  Breaking platform-specific code for a platform you don't develop on.

2.  Bits of code in your tree that you never committed that you forgot about, that change the results.

Realistically, these things will always slip through the cracks once in a while, but when they do quick and automatic feedback is a Good Thing (TM).

On 9/18/2010 9:45 PM, Brad Roberts wrote:
> I just tried building with link upgraded to the 8.00.7 beta.. no better.
>
> Guys, it's really important that all of these packages continue to build and pass their respective tests.  It seems like we can't go more than a day or so without something new being introduced that breaks something.
>
> I recognize that we're all volunteers here, but please be responsible for making sure your changes don't cause any platform to stop building and passing tests. It might well be that there's a lurking problem that's just surfaced somehow, but the bottom line is that being unable to build and run the tests successfully is a blocker for everyone.
>
> I also recognize that not everyone has access to more than one platform.  That's exactly one of the reasons I setup the auto build/test system.  Hopefully we'll get os/x and freebsd added soon.  Use it.. watch the results.
>
> In case your head has been in the sand, the url:
>      http://d.puremagic.com/test-results/
>
> Fix or revert.. file bugs.. figure out work arounds.. but don't leave broken.
>
> Please?
>
> Thanks,
> Brad
>
> On 9/18/2010 5:49 PM, David Simcha wrote:
>>   Yeh, I had experimentally added std.parallelism to my DMD directory and
>> compiled Phobos and encountered similar things.  When I ran the unittests for
>> std.parallelism by itself, they passed.  Whenever I ran them along with the rest
>> of Phobos, there was an access violation somewhere (I don't know where).  I
>> didn't say anything because I wasn't sure where the bug was at the time, and
>> didn't have a clue where to start tracking it down.
>>
>> On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
>>> Brad Roberts<braddr at puremagic.com>   wrote:
>>>> The win32 phobos tests started failing after this submit.. with an access violation.
>>>>
>>>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
>>> Probably it's related to the executable size.
>>>
>>> With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
>>> ----------
>>> struct Tuple(Specs...)
>>> {
>>>       pragma(msg, "@@@");
>>> ...
>>> ----------
>>> Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.
>>>
>>> Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!
>>>
>>>
>>> My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...
>>>
>>>
>>> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Emails are on my todo list.  My top plans:

1) track svn revision id's

2) change the build rate to be reactive to submissions (ie, potentially much faster than once an hour, but also not at all when no changes have been submitted)

3) send breakage emails

Maybe I should move #3 to be #1.  I can add the changes that caused the brokenness later.  Would everyone be ok with receiving one mail every time anything breaks in any build?  Right now that'd mean roughly 2 emails per hour while things are broken.. potentially 4 per hour when osx/freebsd are added.

Another thought I had was to have each build cycle contain one and only one change.  If multiple changes come in between runs, still just increment through them with a couple back-to-back builds.  It'd make it a lot easier to see exactly which change introduced breakage.

Some thoughts on your list..

1) I've noticed that most of the breakages have been platform specific.
Interestingly, most of them have NOT been in platform specific code.  So... why?
 (Yes, yours was in posix path handling, but that's not typical for the last
couple weeks).

2) I find this one easy enough to work around by using two trees.. one being my do lots of development stuff, all over the place as the fancy suits me.  The second being the 'carve off a set to be checked in'.  I use the latter to avoid exactly the problem you mention, allowing the testing of the set to submit in isolation.  The cost of moving changes over adds overhead, but usually isn't nearly as hard as writing the code in the first place and is something you get better at with just a little practice.

But, yes, absolutely, things happen and that's ok.  Reacting and resolving when they do is as important as any other step of the development process.

Later,
Brad

On 9/18/2010 7:00 PM, David Simcha wrote:
>  Yea, I'm guilty of breaking the Linux builds.  I think a good enhancement to
> your auto testing system would be to have it automatically nag the Phobos list
> whenever something breaks (instead of you doing it manually).  The reasons why
> things slip through the cracks seem to be:
> 
> 1.  Breaking platform-specific code for a platform you don't develop on.
> 
> 2.  Bits of code in your tree that you never committed that you forgot about, that change the results.
> 
> Realistically, these things will always slip through the cracks once in a while, but when they do quick and automatic feedback is a Good Thing (TM).
> 
> On 9/18/2010 9:45 PM, Brad Roberts wrote:
>> I just tried building with link upgraded to the 8.00.7 beta.. no better.
>>
>> Guys, it's really important that all of these packages continue to build and pass their respective tests.  It seems like we can't go more than a day or so without something new being introduced that breaks something.
>>
>> I recognize that we're all volunteers here, but please be responsible for making sure your changes don't cause any platform to stop building and passing tests. It might well be that there's a lurking problem that's just surfaced somehow, but the bottom line is that being unable to build and run the tests successfully is a blocker for everyone.
>>
>> I also recognize that not everyone has access to more than one platform.  That's exactly one of the reasons I setup the auto build/test system.  Hopefully we'll get os/x and freebsd added soon.  Use it.. watch the results.
>>
>> In case your head has been in the sand, the url:
>>      http://d.puremagic.com/test-results/
>>
>> Fix or revert.. file bugs.. figure out work arounds.. but don't leave broken.
>>
>> Please?
>>
>> Thanks,
>> Brad
>>
>> On 9/18/2010 5:49 PM, David Simcha wrote:
>>>   Yeh, I had experimentally added std.parallelism to my DMD directory and
>>> compiled Phobos and encountered similar things.  When I ran the unittests for
>>> std.parallelism by itself, they passed.  Whenever I ran them along with the rest
>>> of Phobos, there was an access violation somewhere (I don't know where).  I
>>> didn't say anything because I wasn't sure where the bug was at the time, and
>>> didn't have a clue where to start tracking it down.
>>>
>>> On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
>>>> Brad Roberts<braddr at puremagic.com>   wrote:
>>>>> The win32 phobos tests started failing after this submit.. with an access violation.
>>>>>
>>>>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
>>>> Probably it's related to the executable size.
>>>>
>>>> With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
>>>> ----------
>>>> struct Tuple(Specs...)
>>>> {
>>>>       pragma(msg, "@@@");
>>>> ...
>>>> ----------
>>>> Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.
>>>>
>>>> Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!
>>>>
>>>>
>>>> My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...
>>>>
>>>>
>>>> Shin

On Saturday 18 September 2010 19:14:27 Brad Roberts wrote:
> Emails are on my todo list.  My top plans:
> 
> 1) track svn revision id's
> 
> 2) change the build rate to be reactive to submissions (ie, potentially much faster than once an hour, but also not at all when no changes have been submitted)

These both sound good.

> 3) send breakage emails
> 
> Maybe I should move #3 to be #1.  I can add the changes that caused the brokenness later.  Would everyone be ok with receiving one mail every time anything breaks in any build?  Right now that'd mean roughly 2 emails per hour while things are broken.. potentially 4 per hour when osx/freebsd are added.

That might be a bit excessive. If #2 were done, this wouldn't be a problem, but without it, that could be a bit much. Of course, since it only happens while the things are broken, and it would only be temporary that so many e-mails would be sent, it might be okay. But it also might be better to wait until #2 is done. That's a hard one. I suppose which would be better would depend on how often things are likely to be broken between now and when you get #2 done. If it's daily, that's probably too much. If it's weekly, then it's probably okay. So, I really don't know whether you should wait to do #3 before having done #2. I don't like the idea of the list being flooded with breakage e-mails, but we do want the list to be notified of breakages.

> Another thought I had was to have each build cycle contain one and only one change.  If multiple changes come in between runs, still just increment through them with a couple back-to-back builds.  It'd make it a lot easier to see exactly which change introduced breakage.

Also an excellent idea.

- Jonathan M Davis

(2010/09/19 4:27), Brad Roberts wrote:
> On 9/18/2010 4:04 AM, dsource.org wrote:
>> phobos commit, revision 2028
>>
>>
>> user: SHOO
>>
>> msg:
>> std.datetime: Added benchmark
>>
>> This function came from std.date.
>> But now, benchmark returns Ticks[N] and don't use result argument.
>> I removed need to use GC for by doing it in this way.
>>
>> http://www.dsource.org/projects/phobos/changeset/2028
>
> The win32 phobos tests started failing after this submit.. with an access violation.
>
> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525

Actually, I had found the access violation, too. But I could not
discover origin of this issue.
Since unittest succeeded when I cut out some unittest, I guessed the
origin of issue is not based on mine. Probably it seems to be based on
compiler or linker.

All great initiatives. But the point is to verify that stuff builds _before_, not _after_, the commit. Until we have Unix, Windows, and OSX machines that we can all ssh into, that won't be possible.

As unpleasant as that is to some of us, I think we need to impose anyone who commits to use some Unix as their development platform. (There are many reasons. One is, it wouldn't be reasonable to develop on Windows or OSX as one needs to pay to get them.) Linux has wine, which is stable enough to be a good test bed for Windows code. That means any of us can build and unittest for at least two operating systems.

Just a reminder: with the current posix.mak running on Linux, to unittest, type:

make unittest

and to unittest under wine, type:

make OS=win32wine unittest

If somebody wants to develop on Windows and build on cygwin, that's fine too, but cygwin support is not currently in our makefile. It would be a great addition.


Andrei

On 09/18/2010 09:14 PM, Brad Roberts wrote:
> Emails are on my todo list.  My top plans:
>
> 1) track svn revision id's
>
> 2) change the build rate to be reactive to submissions (ie, potentially much faster than once an hour, but also not at all when no changes have been submitted)
>
> 3) send breakage emails
>
> Maybe I should move #3 to be #1.  I can add the changes that caused the brokenness later.  Would everyone be ok with receiving one mail every time anything breaks in any build?  Right now that'd mean roughly 2 emails per hour while things are broken.. potentially 4 per hour when osx/freebsd are added.
>
> Another thought I had was to have each build cycle contain one and only one change.  If multiple changes come in between runs, still just increment through them with a couple back-to-back builds.  It'd make it a lot easier to see exactly which change introduced breakage.
>
> Some thoughts on your list..
>
> 1) I've noticed that most of the breakages have been platform specific.
> Interestingly, most of them have NOT been in platform specific code.  So... why?
>   (Yes, yours was in posix path handling, but that's not typical for the last
> couple weeks).
>
> 2) I find this one easy enough to work around by using two trees.. one being my do lots of development stuff, all over the place as the fancy suits me.  The second being the 'carve off a set to be checked in'.  I use the latter to avoid exactly the problem you mention, allowing the testing of the set to submit in isolation.  The cost of moving changes over adds overhead, but usually isn't nearly as hard as writing the code in the first place and is something you get better at with just a little practice.
>
> But, yes, absolutely, things happen and that's ok.  Reacting and resolving when they do is as important as any other step of the development process.
>
> Later,
> Brad
>
> On 9/18/2010 7:00 PM, David Simcha wrote:
>>   Yea, I'm guilty of breaking the Linux builds.  I think a good enhancement to
>> your auto testing system would be to have it automatically nag the Phobos list
>> whenever something breaks (instead of you doing it manually).  The reasons why
>> things slip through the cracks seem to be:
>>
>> 1.  Breaking platform-specific code for a platform you don't develop on.
>>
>> 2.  Bits of code in your tree that you never committed that you forgot about, that change the results.
>>
>> Realistically, these things will always slip through the cracks once in a while, but when they do quick and automatic feedback is a Good Thing (TM).
>>
>> On 9/18/2010 9:45 PM, Brad Roberts wrote:
>>> I just tried building with link upgraded to the 8.00.7 beta.. no better.
>>>
>>> Guys, it's really important that all of these packages continue to build and pass their respective tests.  It seems like we can't go more than a day or so without something new being introduced that breaks something.
>>>
>>> I recognize that we're all volunteers here, but please be responsible for making sure your changes don't cause any platform to stop building and passing tests. It might well be that there's a lurking problem that's just surfaced somehow, but the bottom line is that being unable to build and run the tests successfully is a blocker for everyone.
>>>
>>> I also recognize that not everyone has access to more than one platform.  That's exactly one of the reasons I setup the auto build/test system.  Hopefully we'll get os/x and freebsd added soon.  Use it.. watch the results.
>>>
>>> In case your head has been in the sand, the url:
>>>       http://d.puremagic.com/test-results/
>>>
>>> Fix or revert.. file bugs.. figure out work arounds.. but don't leave broken.
>>>
>>> Please?
>>>
>>> Thanks,
>>> Brad
>>>
>>> On 9/18/2010 5:49 PM, David Simcha wrote:
>>>>    Yeh, I had experimentally added std.parallelism to my DMD directory and
>>>> compiled Phobos and encountered similar things.  When I ran the unittests for
>>>> std.parallelism by itself, they passed.  Whenever I ran them along with the rest
>>>> of Phobos, there was an access violation somewhere (I don't know where).  I
>>>> didn't say anything because I wasn't sure where the bug was at the time, and
>>>> didn't have a clue where to start tracking it down.
>>>>
>>>> On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
>>>>> Brad Roberts<braddr at puremagic.com>    wrote:
>>>>>> The win32 phobos tests started failing after this submit.. with an access violation.
>>>>>>
>>>>>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
>>>>> Probably it's related to the executable size.
>>>>>
>>>>> With the following pragma, I found that the access violation starts from about 82 instantiations of std.typecons.Tuple.
>>>>> ----------
>>>>> struct Tuple(Specs...)
>>>>> {
>>>>>        pragma(msg, "@@@");
>>>>> ...
>>>>> ----------
>>>>> Removing some Tuple instantiations in Tuple's unittests suppressed the access violation.  Try removing first two blocks in Tuple's unittests; phobos tests should succeed with no access violation.
>>>>>
>>>>> Or, run the tests without a random module.  For instance, inserting __EOF__ at the beginning of std/json.d fixes the access violation!
>>>>>
>>>>>
>>>>> My commit r2025 erased the body of a dummy function in Tuple.  I reckon that changeset could suppress the access violation thanks to smaller executable.  Now, another commit increased the size, and...
>>>>>
>>>>>
>>>>> Shin
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos