Am 01.07.2014 09:41, schrieb Thomas de Groot:
> On 1-7-2014 1:43, clipka wrote:
>> Ready for the next round.
>>
>
> Keep it going!
>
> While this is all gobbledegook to me, I love to read your exchange of
> thoughts :-) It shows the brain at work... or is this play for you guys?
>
> Thomas

Geeks' variation of Mornington Crescent ;-)

Post a reply to this message

Le 01/07/2014 01:43, clipka nous fit lire :

> 
> Ready for the next round.
> 

Seems the only error that remains (in many place) for gcc is about
shared_ptr with NULL. (it might be enough, if you want to keep NULL, to
have a C-old cast in void*, such as

return GenericNormalBlendMapPtr((void*)NULL);

) (as long as to be ugly with C NULL, a C-cast seems not that more to
the vessel; Of course, a default empty constructor is fine.. but we know
theses lines are not to be executed)

icpc (intel compiler) has additional issues:

backend/texture/texture.cpp(2324): error: no default constructor exists
for class "pov::BlendMap<pov::TexturePtr>"
  TextureBlendMap::TextureBlendMap() : BlendMap(TEXTURE_TYPE) {}

It also happens in normal.cpp; (it might be tied to the previous error
about shared_ptr, well, I hope so)

Clang has the same issue with a long as parameters of shared_ptr than
the two others.



-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Attachments:
Download 'errorcl4.txt' (42 KB) Download 'errorgcc4.txt' (175 KB) Download 'erroricpc4.txt' (12 KB)

Am 01.07.2014 18:31, schrieb Le_Forgeron:

> Seems the only error that remains (in many place) for gcc is about
> shared_ptr with NULL. (it might be enough, if you want to keep NULL, to
> have a C-old cast in void*, such as
>
> return GenericNormalBlendMapPtr((void*)NULL);
>
> ) (as long as to be ugly with C NULL, a C-cast seems not that more to
> the vessel; Of course, a default empty constructor is fine.. but we know
> theses lines are not to be executed)

I've decided to go for a parameterless shared_ptr constructor with a 
comment.

Let me know what ca65fc523763201fde29dffd89c63788d81bdd16 does.

Post a reply to this message

Le 01/07/2014 21:19, clipka nous fit lire :
> Am 01.07.2014 18:31, schrieb Le_Forgeron:
> 
>> Seems the only error that remains (in many place) for gcc is about
>> shared_ptr with NULL. (it might be enough, if you want to keep NULL, to
>> have a C-old cast in void*, such as
>>
>> return GenericNormalBlendMapPtr((void*)NULL);
>>
>> ) (as long as to be ugly with C NULL, a C-cast seems not that more to
>> the vessel; Of course, a default empty constructor is fine.. but we know
>> theses lines are not to be executed)
> 
> I've decided to go for a parameterless shared_ptr constructor with a
> comment.
> 
> Let me know what ca65fc523763201fde29dffd89c63788d81bdd16 does.
> 
You're close, only express.cpp still has errors, at 5 locations (3133,
3139, 3153, 3157 and 3170), or just 3107 (as it's a template).

backend/parser/express.cpp(3107): error: no instance of constructor
"boost::shared_ptr<T>::shared_ptr [with T=pov::TextureBlendMap]" matches
the argument list
            argument types are: (long)
          return shared_ptr<MAP_T>(NULL);
                 ^
          detected during instantiation of "boost::shared_ptr<MAP_T>
pov::Parser::Parse_Blend_List<MAP_T>(int, pov::ColourBlendMapConstPtr,
int) [with MAP_T=pov::TextureBlendMap]" at line 3170



The 3 compilers agree. Just that one and we can try the link :-)
(Well, I cheated, replacing the NULL with nothing to test... )
it linked... but "make check" ends with a core dump.
Reconfiguring with --enable-debug ...


#0  0x0000000000579557 in pov::IsoSurface::Compute_BBox
(this=0x2b634c0dc8e0) at backend/shape/isosurf.cpp:746
#1  0x000000000051d684 in pov::Parser::Parse_Object_Mods
(this=this@entry=0x2b6344004cc0, Object=0x2b634c0dc8e0) at
backend/parser/parse.cpp:7390
#2  0x0000000000525921 in pov::Parser::Parse_Object
(this=this@entry=0x2b6344004cc0) at backend/parser/parse.cpp:6410
#3  0x000000000052b15d in pov::Parser::Parse_Frame (this=0x2b6344004cc0)
at backend/parser/parse.cpp:6720
#4  0x000000000052b9b4 in pov::Parser::Run (this=0x2b6344004cc0) at
backend/parser/parse.cpp:203
#5  0x0000000000599da7 in pov::Task::TaskThread (this=0x2b6344004cc0,
completion=...) at backend/support/task.cpp:171
#6  0x00002b63370faa4a in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0
#7  0x00002b6337b2d182 in start_thread (arg=0x2b633cd48700) at
pthread_create.c:312
#8  0x00002b6337e3e30d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111


> 0  0x0000000000579557 in pov::IsoSurface::Compute_BBox (this=0x2b634c0dc8e0) at
backend/shape/isosurf.cpp:746
> #1  0x000000000051d684 in pov::Parser::Parse_Object_Mods
(this=this@entry=0x2b6344004cc0, Object=0x2b634c0dc8e0) at
backend/parser/parse.cpp:7390
> #2  0x0000000000525921 in pov::Parser::Parse_Object (this=this@entry=0x2b6344004cc0)
at backend/parser/parse.cpp:6410
> #3  0x000000000052b15d in pov::Parser::Parse_Frame (this=0x2b6344004cc0) at
backend/parser/parse.cpp:6720
> #4  0x000000000052b9b4 in pov::Parser::Run (this=0x2b6344004cc0) at
backend/parser/parse.cpp:203
> #5  0x0000000000599da7 in pov::Task::TaskThread (this=0x2b6344004cc0,
completion=...) at backend/support/task.cpp:171
> #6  0x00002b63370faa4a in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0
> #7  0x00002b6337b2d182 in start_thread (arg=0x2b633cd48700) at pthread_create.c:312
> #8  0x00002b6337e3e30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

container is null.

void IsoSurface::Compute_BBox()
{
    container->ComputeBBox(BBox);
    if(Trans != NULL)
    {
        Recompute_BBox(&BBox, Trans);
    }
}



-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

On 01/07/2014 2:56 PM, clipka wrote:
> Am 01.07.2014 09:41, schrieb Thomas de Groot:
>> On 1-7-2014 1:43, clipka wrote:
>>> Ready for the next round.
>>>
>>
>> Keep it going!
>>
>> While this is all gobbledegook to me, I love to read your exchange of
>> thoughts :-) It shows the brain at work... or is this play for you guys?
>>
>> Thomas
>
> Geeks' variation of Mornington Crescent ;-)
>

Beware! of Geeks bearing sub-routines.

-- 
Regards
     Stephen

I solemnly promise to kick the next angle, I see.

Post a reply to this message

Am 01.07.2014 22:17, schrieb Le_Forgeron:

>> Let me know what ca65fc523763201fde29dffd89c63788d81bdd16 does.
>>
> You're close, only express.cpp still has errors, at 5 locations (3133,
> 3139, 3153, 3157 and 3170), or just 3107 (as it's a template).

We should be there now. (Besides the isosurface bug there was also a 
corresponding parametric bug.)

Post a reply to this message

Am 02.07.2014 04:13, schrieb clipka:
> Am 01.07.2014 22:17, schrieb Le_Forgeron:
>
>>> Let me know what ca65fc523763201fde29dffd89c63788d81bdd16 does.
>>>
>> You're close, only express.cpp still has errors, at 5 locations (3133,
>> 3139, 3153, 3157 and 3170), or just 3107 (as it's a template).
>
> We should be there now. (Besides the isosurface bug there was also a
> corresponding parametric bug.)
>

While you're at it, could you please do me a favour and also try 
building the new "feature/colour_model" branch? I did some nasty 
template stuff there, and need to know if the Linux compilers can digest it.

Post a reply to this message

Le 02/07/2014 04:13, clipka nous fit lire :
> Am 01.07.2014 22:17, schrieb Le_Forgeron:
> 
>>> Let me know what ca65fc523763201fde29dffd89c63788d81bdd16 does.
>>>
>> You're close, only express.cpp still has errors, at 5 locations (3133,
>> 3139, 3153, 3157 and 3170), or just 3107 (as it's a template).
> 
> We should be there now. (Besides the isosurface bug there was also a
> corresponding parametric bug.)
> 
Yes. Compile, link, run.

* make check : ok for the 3 (g++, icpc, clang++)

Yet, it seems gcc (only) is too fast on benchmark. (4 seconds on 12 threads)

Rendering benchmark gives the attached pictures (the icpc seems ok,
within usual time, but gcc is bogus and too fast, far too fast)


-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Attachments:
Download 'gcc.png' (76 KB) Download 'icpc.png' (448 KB)

Preview of image 'gcc.png'

Preview of image 'icpc.png'

Le 02/07/2014 12:04, clipka nous fit lire :

> 
> While you're at it, could you please do me a favour and also try
> building the new "feature/colour_model" branch? I did some nasty
> template stuff there, and need to know if the Linux compilers can digest
> it.
> 
You're welcome, until my soon-to-be-holidays (very soon now!).

g++ does not like it.
clang++ neither.
And icpc is not better.

All of them get a problem with ">>" in template.. it should be "> >" to
avoid ambiguity with >> operator... so it fails. But even correcting
that is not enough.

The error log of gcc and icpc are past the 1.8MBytes (the largest is 7
MBytes)... so I just attach the clang one.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Post a reply to this message

Attachments:
Download 'errorcolourcl.txt' (589 KB)

Am 02.07.2014 19:07, schrieb Le_Forgeron:
> Le 02/07/2014 12:04, clipka nous fit lire :
>
>>
>> While you're at it, could you please do me a favour and also try
>> building the new "feature/colour_model" branch? I did some nasty
>> template stuff there, and need to know if the Linux compilers can digest
>> it.
>>
> You're welcome, until my soon-to-be-holidays (very soon now!).
>
> g++ does not like it.
> clang++ neither.
> And icpc is not better.
>
> All of them get a problem with ">>" in template.. it should be "> >" to
> avoid ambiguity with >> operator... so it fails. But even correcting
> that is not enough.
>
> The error log of gcc and icpc are past the 1.8MBytes (the largest is 7
> MBytes)... so I just attach the clang one.

Can you please give me the output with ">>" corrected to "> >"? Thanks a 
lot!

Post a reply to this message