 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/13/2014 07:28 AM, clipka wrote:
> Am 13.08.2014 12:11, schrieb James Holsenback:
>
>>>> narrowed a bit further ... this hash works fine:
>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>
>>>>
>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>> think that's considerable less territory to cover.
>>
>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>> commit (compiles and runs OTOTest.pov properly)
>>
>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>> compile ./base/safemath.h is belching errors all over the place
>
> Ah, yes, that one... that's part of GitHub issue #29. It'll need
> replacing of "numeric_limits" with "std::numeric_limits" (and then
> probably some more fixes).
have you been able to (or are you even going to) look into why the
implementation (re-factoring???) of this construct isn't compatible with
my compiler (that's what appears to be happening) since you can't
confirm on your end.
it /really/ appears that this (OTOTest file) got broken @
cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
just cleaned up the implementation so i could at least compile.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/16/2014 06:49 AM, James Holsenback wrote:
> On 08/13/2014 07:28 AM, clipka wrote:
>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>
>>>>> narrowed a bit further ... this hash works fine:
>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>
>>>>>
>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>> think that's considerable less territory to cover.
>>>
>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>> commit (compiles and runs OTOTest.pov properly)
>>>
>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>> compile ./base/safemath.h is belching errors all over the place
>>
>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>> probably some more fixes).
>
> have you been able to (or are you even going to) look into why the
> implementation (re-factoring???) of this construct isn't compatible with
> my compiler (that's what appears to be happening) since you can't
> confirm on your end.
>
> it /really/ appears that this (OTOTest file) got broken @
> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
> just cleaned up the implementation so i could at least compile.
>
following up on the notion that it's compiler/configure related, I did a
comparison of configure output the buildbot server and my system!
This 1st output is from the buildbot server ...
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1:
Just a few entries of interest here /not/ all of them ... compare them
with below output!
Language constructs and functions
---------------------------------
checking size of int... 4
checking size of long int... 8
checking size of size_t... 8
checking size of float... 4
Floating Point Features
-----------------------
checking limits usability... yes
checking limits presence... yes
checking for limits... yes
checking whether NaNs are supported... yes
checking cmath usability... yes
checking cmath presence... yes
checking for cmath... yes
checking whether NaNs can be identified using std::isnan()... no
checking whether NaNs can be identified using global isnan()... no
checking whether NaNs can be identified by comparison to themselves... no
checking whether infinite values are supported... yes
checking for cmath... (cached) yes
checking whether infinities can be identified using std::isinf()... no
checking whether infinities can be identified using global isinf()... no
checking whether infinities can be identified by comparison to the
maximum value... yes
------
This output is from my system ...
gcc (SUSE Linux) 4.6.2:
Compare to above buildbot output ...
Language constructs and functions
---------------------------------
checking size of int... 4
checking size of long int... 4
checking size of size_t... 4
checking size of float... 4
Did /not/ even have "Floating Point Features" section on my system!!!
The plot thickens? mkl?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2014 12:49, schrieb James Holsenback:
> On 08/13/2014 07:28 AM, clipka wrote:
>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>
>>>>> narrowed a bit further ... this hash works fine:
>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>
>>>>>
>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>> think that's considerable less territory to cover.
>>>
>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>> commit (compiles and runs OTOTest.pov properly)
>>>
>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>> compile ./base/safemath.h is belching errors all over the place
>>
>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>> probably some more fixes).
>
> have you been able to (or are you even going to) look into why the
> implementation (re-factoring???) of this construct isn't compatible with
> my compiler (that's what appears to be happening) since you can't
> confirm on your end.
The "numeric_limits" in the global namespace (i.e. without "std::")
isn't compatible with your compiler because it's not ISO C++. MS Visual
C++ does support it, but other compilers (or, more precisely, the
respective <limits> header file) may not.
Prior to that change, there was a statement "using namespace std;" which
effectively says, "everything in namespace std should also be available
in the current namespace", or, in other words, "std:: can be omitted
everywhere". It had to be dropped because with some compilers it caused
name conflicts between implementations of the shared_ptr class from
different sources (boost, tr1 and C++11).
> it /really/ appears that this (OTOTest file) got broken @
> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
> just cleaned up the implementation so i could at least compile.
I wouldn't expect the issue #29 commits to do anything else. They're
just there to use less ambiguous language constructs to satisfy some
compilers that are less forgiving than MS Visual C++.
If I understand you correctly, you're saying that with issue #29 fixes
in place commit 7502593 works while cf1c3fb doesn't. Is that right?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2014 14:00, schrieb James Holsenback:
> following up on the notion that it's compiler/configure related, I did a
> comparison of configure output the buildbot server and my system!
Does the buildbot-generated binary render the scene ok?
> This 1st output is from the buildbot server ...
>
> gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1:
>
> Just a few entries of interest here /not/ all of them ... compare them
> with below output!
>
> Language constructs and functions
> ---------------------------------
> checking size of int... 4
> checking size of long int... 8
> checking size of size_t... 8
> checking size of float... 4
That's typical for a 64-bit machine.
> Floating Point Features
> -----------------------
> checking limits usability... yes
> checking limits presence... yes
> checking for limits... yes
> checking whether NaNs are supported... yes
> checking cmath usability... yes
> checking cmath presence... yes
> checking for cmath... yes
> checking whether NaNs can be identified using std::isnan()... no
> checking whether NaNs can be identified using global isnan()... no
> checking whether NaNs can be identified by comparison to themselves... no
> checking whether infinite values are supported... yes
> checking for cmath... (cached) yes
> checking whether infinities can be identified using std::isinf()... no
> checking whether infinities can be identified using global isinf()... no
> checking whether infinities can be identified by comparison to the
> maximum value... yes
That's typical for g++ with floating-point optimizations enabled.
> ------
>
> This output is from my system ...
>
> gcc (SUSE Linux) 4.6.2:
>
> Compare to above buildbot output ...
>
> Language constructs and functions
> ---------------------------------
> checking size of int... 4
> checking size of long int... 4
> checking size of size_t... 4
> checking size of float... 4
That's typical for a 32-bit machine.
> Did /not/ even have "Floating Point Features" section on my system!!!
That's perfectly normal for any version prior to commit f1699ea.
> The plot thickens? mkl?
No plot-thickening yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/16/2014 10:17 AM, clipka wrote:
> Am 16.08.2014 12:49, schrieb James Holsenback:
>> On 08/13/2014 07:28 AM, clipka wrote:
>>> Am 13.08.2014 12:11, schrieb James Holsenback:
>>>
>>>>>> narrowed a bit further ... this hash works fine:
>>>>>> 9a278c7f02003b7e6d6d0665c37695351cb23a27 so something after that!!!!
>>>>>>
>>>>>>
>>>>> ok so at hash 54b283a0d39c637ce9d4ab16512a364e993c58c5 its busted so I
>>>>> think that's considerable less territory to cover.
>>>>
>>>> this hash ac564f7231f2b05b461a3a03fe6b9ed21b845c5a is the last working
>>>> commit (compiles and runs OTOTest.pov properly)
>>>>
>>>> broken @ cf1c3fbedb33802bd431acac43ce41db55fa87b8 ... doesn't even
>>>> compile ./base/safemath.h is belching errors all over the place
>>>
>>> Ah, yes, that one... that's part of GitHub issue #29. It'll need
>>> replacing of "numeric_limits" with "std::numeric_limits" (and then
>>> probably some more fixes).
>>
>> have you been able to (or are you even going to) look into why the
>> implementation (re-factoring???) of this construct isn't compatible with
>> my compiler (that's what appears to be happening) since you can't
>> confirm on your end.
>
> The "numeric_limits" in the global namespace (i.e. without "std::")
> isn't compatible with your compiler because it's not ISO C++. MS Visual
> C++ does support it, but other compilers (or, more precisely, the
> respective <limits> header file) may not.
>
> Prior to that change, there was a statement "using namespace std;" which
> effectively says, "everything in namespace std should also be available
> in the current namespace", or, in other words, "std:: can be omitted
> everywhere". It had to be dropped because with some compilers it caused
> name conflicts between implementations of the shared_ptr class from
> different sources (boost, tr1 and C++11).
>
>> it /really/ appears that this (OTOTest file) got broken @
>> cf1c3fbedb33802bd431acac43ce41db55fa87b8 and that the issue #29 commits
>> just cleaned up the implementation so i could at least compile.
>
> I wouldn't expect the issue #29 commits to do anything else. They're
> just there to use less ambiguous language constructs to satisfy some
> compilers that are less forgiving than MS Visual C++.
>
> If I understand you correctly, you're saying that with issue #29 fixes
> in place commit 7502593 works while cf1c3fb doesn't. Is that right?
ac564f7 was the last time I was able to compile and run OTOTest file
correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last
issue #29) commit and it compiled fine but OTOTest file problem showed
up again
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.08.2014 10:47, schrieb James Holsenback:
>> If I understand you correctly, you're saying that with issue #29 fixes
>> in place commit 7502593 works while cf1c3fb doesn't. Is that right?
>
> ac564f7 was the last time I was able to compile and run OTOTest file
> correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last
> issue #29) commit and it compiled fine but OTOTest file problem showed
> up again
Please note that the Git version history isn't linear: It has different
branches that split and merge; and while ac564f7 is the last commit
before cf1c3fb, it was done on a different branch, and so the immediate
predecessor of cf1c3fb is the earlier commit 7502593. (Likewise, the
later commit 914fff1 is a direct successor of ac564f7 but not of
cf1c3fb, and is therefore likely to both compile and run OTOTest file.)
The following commits are still suspects for having broken OTOTest (in
reverse chronological order):
cf1c3fb
7502593
2a2d1a8
2a41f04
7502593 is comparatively unlikely to be the culprit, as it just merges
bugfix cc24c62, which was also merged into the other branch leading to
ac564f7 and apparently didn't do any damage there.
2a2d1a8 is about as hot a candidate as cf1c3fb - probably even more so,
as it is all about vectors and therefore relative position of items,
while cf1c3fb is about blend maps (colour maps, pigment maps, normal
maps etc.), which do not have any intrinsic relative positional
component to them.
2a41f04 is a hot candidate for having caused GitHub issue #29, but
shouldn't have brought about any functional changes, so I suspect it
will run fine with the issue #29 fixes applied.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2014 16:24, schrieb clipka:
> Am 16.08.2014 14:00, schrieb James Holsenback:
>
>> following up on the notion that it's compiler/configure related, I did a
>> comparison of configure output the buildbot server and my system!
>
> Does the buildbot-generated binary render the scene ok?
Did you have time to test this by now?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/18/2014 08:20 AM, clipka wrote:
> Am 16.08.2014 16:24, schrieb clipka:
>> Am 16.08.2014 14:00, schrieb James Holsenback:
>>
>>> following up on the notion that it's compiler/configure related, I did a
>>> comparison of configure output the buildbot server and my system!
>>
>> Does the buildbot-generated binary render the scene ok?
>
> Did you have time to test this by now?
>
no I haven't ... didn't catch that previously. probably not today ...
maybe tomorrow.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/18/2014 08:18 AM, clipka wrote:
> Am 17.08.2014 10:47, schrieb James Holsenback:
>
>>> If I understand you correctly, you're saying that with issue #29 fixes
>>> in place commit 7502593 works while cf1c3fb doesn't. Is that right?
>>
>> ac564f7 was the last time I was able to compile and run OTOTest file
>> correctly ... cf1c3fb wouldn't even compile. jumped to af80da4 (the last
>> issue #29) commit and it compiled fine but OTOTest file problem showed
>> up again
>
> Please note that the Git version history isn't linear: It has different
> branches that split and merge; and while ac564f7 is the last commit
> before cf1c3fb, it was done on a different branch, and so the immediate
> predecessor of cf1c3fb is the earlier commit 7502593. (Likewise, the
> later commit 914fff1 is a direct successor of ac564f7 but not of
> cf1c3fb, and is therefore likely to both compile and run OTOTest file.)
>
> The following commits are still suspects for having broken OTOTest (in
> reverse chronological order):
>
> cf1c3fb
> 7502593
> 2a2d1a8
> 2a41f04
>
> 7502593 is comparatively unlikely to be the culprit, as it just merges
> bugfix cc24c62, which was also merged into the other branch leading to
> ac564f7 and apparently didn't do any damage there.
>
> 2a2d1a8 is about as hot a candidate as cf1c3fb - probably even more so,
> as it is all about vectors and therefore relative position of items,
> while cf1c3fb is about blend maps (colour maps, pigment maps, normal
> maps etc.), which do not have any intrinsic relative positional
> component to them.
>
> 2a41f04 is a hot candidate for having caused GitHub issue #29, but
> shouldn't have brought about any functional changes, so I suspect it
> will run fine with the issue #29 fixes applied.
>
OK ... this goes to some of my confusion. I'd suspected as much. Thanks
for the sanity check!
When I downloaded source(s) I used the "clone" url, so I was pulling a
snapshot of the entire branch (not just individual changes) at that
commit, then doing separate builds for each. Give me some time to
further narrow it down.
Appreciate your indulgence.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.08.2014 19:08, schrieb James Holsenback:
>>> The Sam's test scene (OTOTest.pov) renders fine here with the latest
>>> POV-Ray and UberPOV stuff (Windows versions).
>>
>> here's what I'm doing:
>>
>> #declare Floor =
>> union {
>> object {
>> OTO( <-2.5,-2.5,0>, <2.5,2.5,1>, 0.075, texture { BaseTexture
>> scale 1 } )
>> }
>> box { <-2.5,-2.5,0.075>, <2.5,2.5,0.075> pigment { srgb 1 } finish
>> {diffuse 0.6 specular 0.15 roughness 1e-5} }
>> rotate x*90
>> rotate y*0
>> }
>>
>> kind of funny that it works with some versions (perforce/git 3.7 stable)
>> but not other git repos ... 32 vs 64 bit? compiler?? configure changes???
>
> found OTOTest.pov file laying around in some obscure corner ... here's
> results
I've got some good news: While I'm still unable to reproduce the error,
I /am/ now able to exactly reproduce the output you're seeing (see
attached image), by changing the OTO_FMask function
#local OTO_FMask = function{ pattern{ pigment_pattern{
checker 0, 1 warp{planar} } } }
to something that never returns 1; so it would seem that the error
scrambles one of the statements in this function definition.
Can you please dig further in this direction to figure out exactly what
part of this is broken? (I guess this will lead us much faster to the
root cause than knowing exactly which commit introduced it.)
Post a reply to this message
Attachments:
Download 'ototest.png' (275 KB)
Preview of image 'ototest.png'
|
|
| |
| |
|
|
|
|
| |
|
|
