Folks,

The beta 28 windows source is up at:

  http://www.povray.org/temp/povwin-src-3.7.beta.28.zip

I'd appreciate it if some of you could let me know the results of a
sanity-check on it before I put it on the source download page.

thanks,

-- Chris

Post a reply to this message

On Sun, 17 Aug 2008 10:34:07 +0200, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> The beta 28 windows source is up at:
>
>   http://www.povray.org/temp/povwin-src-3.7.beta.28.zip
>
> I'd appreciate it if some of you could let me know the results of a
> sanity-check on it before I put it on the source download page.

A quick test compile reveals that it does not play nice with Boost 1.36.0  
(released Aug 14).

When compiling 'radiosity.cpp',  
'pov::Random{Int/Double}Sequence::Generator' clashes with  
'boost::Generator' because the whole Boost namespace is imported into the  
POV namespace with a 'using' statement. The declaration "friend class  
Generator" then picks up the Boost class instead of the nested class.

It would be best to get rid of the 'using' statements, at least in header  
files.



There is also a problem in 'taskqueue.h'. Apparently the type  
'boost::condition' is deprecated in favour of 'condition_variable_any'.  
There is a typedef that provides the old name for backwards compatibility  
, but to get it one must include 'boost/thread/condition.hpp'.



Also, the compiler (VC8) finds the use of 'IStream' and 'Rectangle' to be  
ambiguous in some places, because those names are defined in Platform SDK  
headers that get pulled in somewhere. A solution would be to qualify them,  
i.e. 'pov_base::IStream' and 'pov_base::Rectangle'.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Sun, 17 Aug 2008 10:34:07 +0200, Chris Cason 
> <del### [at] deletethistoopovrayorg> wrote:
>> The beta 28 windows source is up at:
>>
>>   http://www.povray.org/temp/povwin-src-3.7.beta.28.zip
>>
>> I'd appreciate it if some of you could let me know the results of a
>> sanity-check on it before I put it on the source download page.
> 
> A quick test compile reveals that it does not play nice with Boost 
> 1.36.0 (released Aug 14).

You need to use a pre-1.35 boost.

I recently outlined it in p.unix (and will just copy and paste it here):
This is a complex boost change, not a change in POV-Ray. Please read the 
*boost* documentation, as this is not a POV-Ray issue! Do no use boost 1.35 
or later with the current POV-Ray 3.7 beta source code if you want a 
functional executable. The fact that a program compiles and links does not 
make it function correctly. There is nothing wrong with either boost 1.36 or 
POV-Ray 3.7, you just have to use the correct version of boost. Use boost 
1.34 with the current POV-Ray 3.7 beta source code.

	Thorsten, POV-Team

Post a reply to this message

Le Sun, 17 Aug 2008 18:25:26 +0200, Thorsten Froehlich a modifié des
petits morceaux de l'univers pour nous faire lire :

> You need to use a pre-1.35 boost.
> 

Can you be a bit more specific ? I'm on gentoo (boost is 1.35-r1 so far, 
but might evolve anytime soon), so i'm interested a bit by this subject.

> Please read the *boost* documentation, as this is not a POV-Ray issue! 

Which part, please, as boost is really a huge collection of parts ?
thread ? mutex ? other ?
RTFM is no good when the manual is the size of the Britannica 
Encyclopedia and nothing more is at least provided to choose the right 
volume.

> Do no use boost
> 1.35 or later with the current POV-Ray 3.7 beta source code if you want
> a functional executable.

It really does not matter, as the available unix source code is late 
(still at 25b, whereas 28 is available for Windows binary since...)

Post a reply to this message

On 17 Aug 2008 17:37:42 -0400
Le Forgeron <jgr### [at] freefr> wrote:

> > Please read the *boost* documentation, as this is not a POV-Ray
> > issue! 
> 
> Which part, please, as boost is really a huge collection of parts ?
> thread ? mutex ? other ?
> RTFM is no good when the manual is the size of the Britannica 
> Encyclopedia and nothing more is at least provided to choose the right 
> volume.

http://www.boost.org/doc/libs/1_35_0/doc/html/thread/changes.html

> > Do no use boost
> > 1.35 or later with the current POV-Ray 3.7 beta source code if you
> > want a functional executable.

What is really surprising, is that the 3.7 version I compiled with 1.36
_is_ functional. I rendered several images with it... There are subtle
differences in the rendering of some objects, which made me go back to
3.6, but the executable is working.

John

Post a reply to this message

Fredrik Eriksson wrote:
> A quick test compile reveals that it does not play nice with Boost 1.36.0  
> (released Aug 14).

There is a warning in the README about the boost version: we do not
support anything other than 1.34_1 at the moment.

-- Chris

Post a reply to this message

Le Forgeron wrote:
> Which part, please, as boost is really a huge collection of parts ?
> thread ? mutex ? other ?

The windows readme goes into this a little bit with respect to boost
1.35 (I wasn't aware of 1.36). Basically it's a change in thread; I'm
not sure of the impact since I've not tested it - I'm simply playing safe.

I will update the source to suit the new boost soon.

> It really does not matter, as the available unix source code is late 
> (still at 25b, whereas 28 is available for Windows binary since...)

our Linux guys seem to be doing other stuff these days. I will do a
Linux source release myself (but it will just be the last source
release combined with updated .cpp and .h files; I can't reliably
update any other part of it such as makefiles and whatnot since I
don't know enough about it).

-- Chris

Post a reply to this message

On Mon, 18 Aug 2008 18:35:18 +1000
Chris Cason <del### [at] deletethistoopovrayorg> wrote:

> Fredrik Eriksson wrote:
> > A quick test compile reveals that it does not play nice with Boost
> > 1.36.0 (released Aug 14).
> 
> There is a warning in the README about the boost version: we do not
> support anything other than 1.34_1 at the moment.

Chris,

How does the problem manifest itself? I have 3.7beta compiled with
Boost 1.36, and the executable _does_ render. I haven't rendered many
scenes, it worked every time without any error message or other
problems (I only noticed some smaller differences in color and lighting).

John

Post a reply to this message

On Mon, 18 Aug 2008 11:39:21 -0300
John Coppens <joh### [at] johncoppenscom> wrote:

> How does the problem manifest itself? 

I mean - maybe this is a windows-only problem?

John

Post a reply to this message

Le Mon, 18 Aug 2008 18:41:59 +1000, Chris Cason a modifié des petits
morceaux de l'univers pour nous faire lire :

> Le Forgeron wrote:
>> Which part, please, as boost is really a huge collection of parts ?
>> thread ? mutex ? other ?
> 
> The windows readme goes into this a little bit with respect to boost
> 1.35 (I wasn't aware of 1.36). Basically it's a change in thread; I'm
> not sure of the impact since I've not tested it - I'm simply playing
> safe.
> 
> I will update the source to suit the new boost soon.

Good. May be it will solve the random concurrent access lock that I can 
still observe at some very rare time (25b with workaround for starting 
thread applied, on linux source): the rendering window appears, stay 
black, and nothing seems to happened until the mouse enter the rendering 
window (command line of povray process remains suspended, despite the 
rendering not occuring (or already done)); That bug seems not 
reproductible, but it occurs with 25b++ on both amd64/64bit & xeon 
systems (both on which I tried rendering the portfolio and other pictures 
from the sources). 
In fact, for the xeon, as it is a remote system, even mousing into the 
rendering window did not unlock the process. Might occurs once or twice 
for all the provided scenes (and ramdomly: does not seem to be a 
particular scene, usually it works fine, and then, that time, it fails).
I did not try to disable the rendering window, sorry.

(that Xeon is Linux RedHat ES 5 (quad-core), AMD64 is Linux gentoo 
(single core)... i have also access to some sparc-solaris (2.9 & 2.10) & 
RedHat ES 4, if necessary)

> 
>> It really does not matter, as the available unix source code is late
>> (still at 25b, whereas 28 is available for Windows binary since...)
> 
> our Linux guys seem to be doing other stuff these days. I will do a
> Linux source release myself (but it will just be the last source release
> combined with updated .cpp and .h files; I can't reliably update any
> other part of it such as makefiles and whatnot since I don't know enough
> about it).

Thank you. If you need my help for unix, feel free to ask mine.

Post a reply to this message