"jr" <cre### [at] gmailcom> wrote:
> ...
> had a v quick look, pleased the INSTALL isn't just the usual generic.  will try
> a no-SDL install in the coming days.  thank you.

tried building but got an error.


regards, jr.


using:

  ./configure \
  --enable-silent-rules \
  --without-libsdl \
  --without-libsdl2 \
  --disable-no-lc-identifiers \
  --with-x \
  --build=${ARCH}-slackware-linux \
  COMPILED_BY="$POVRAY_BUILDER"


edited output from extracting archive thru 'make':

povray-3.8.0-x.povr_b0bcf6c0/
  ...
===============================================================================
POV-Ray (povr) 3.8.0-x.povr_b0bcf6c0 has been configured.
===============================================================================

Built-in features:
  I/O restrictions:          enabled
  X/SDL Window display:      enabled (sdl not available)
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
  Unsupported image formats: -

Compilation settings:
  Build architecture:  x86_64-slackware-linux-gnu
  Built/Optimized for: x86_64-slackware-linux-gnu
  Compiler vendor:     gnu
  Compiler version:    g++ 5.5.0

  Preprocessor flags (CPPFLAGS):
    -pthread -I/usr/include/OpenEXR -I/usr/include

  Compiler flags (CXXFLAGS):
    -pipe -w -fno-enforce-eh-specs -std=c++11 -march=native -mtune=haswell -O2
    -fPIC -pthread

  Linker flags (LDFLAGS):
    -L/usr/lib

  Libraries (LIBS):
    -lXpm -lSM -lICE -lX11 -lIlmImf -lIlmImf -lImath -lHalf -lIex -lIexMath
    -lIlmThread -pthread -lIlmThread -ltiff -ljpeg -lpng -lz -lrt -lm -pthread

  ...
make  all-recursive
make[1]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0'
Making all in source
make[2]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0/source'
  CXX      povmain.o
  CXX      backend/bounding/boundingtask.o
  CXX      backend/control/messagefactory.o
  ...
  CXX      core/math/chi2.o
  CXX      core/math/hypercomplex.o
  CXX      core/math/jitter.o
In file included from core/math/jitter.cpp:37:0:


../source/core/math/jitter.h:104:43: error:

     jx = -0.5f + static_cast<double>(rand()) /
(static_cast<double>(RAND_MAX/((0.5)-(-0.5f))));
                                           ^
../source/core/math/jitter.h:104:69: error:

     jx = -0.5f + static_cast<double>(rand()) /
(static_cast<double>(RAND_MAX/((0.5)-(-0.5f))));

^
Makefile:1309: recipe for target 'core/math/jitter.o' failed
make[2]: *** [core/math/jitter.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0/source'
Makefile:707: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0'
Makefile:500: recipe for target 'all' failed
make: *** [all] Error 2

Post a reply to this message

On 4/28/21 12:27 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> had a v quick look, pleased the INSTALL isn't just the usual generic.  will try
>> a no-SDL install in the coming days.  thank you.
> 
> tried building but got an error.
> 
...
> 
> using:
> 
>    ./configure \
>    --enable-silent-rules \
>    --without-libsdl \
>    --without-libsdl2 \
>    --disable-no-lc-identifiers \
>    --with-x \
>    --build=${ARCH}-slackware-linux \
>    COMPILED_BY="$POVRAY_BUILDER"
> 

Thanks for trying. The --enable-silent-rules is probably not needed 
unless you've somehow overridden the tarball shipped default (...one can 
do it by various methods (the reason the enable and disable are always 
both available as configure options), but it is not common).

---
Of course my compiles with your configure (and some C++ compiler 
settings you must be picking up somewhere by env var or something) and 
all work. I can't reproduce so my best guess...

With the jitter.h issue could you try changing the two calls to rand() 
to std::rand() (a) and then at the top of jitter.h just after the 
comment about c++ variants of c includes add an include of cstdlib so it 
looks like:

// C++ variants of C standard header files
#include <cstdlib>

Then try the make (the compiles) again?

(a) - What those always should have been I think and the first thing I 
see which might be wrong. I see on searching a few more bare rand() 
calls sitting in the code too which might also cause you trouble 
compiling if this the issue (some in pattern.cpp). Hmm, wonder why those 
not an issue before for you if so...

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/28/21 12:27 PM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> Thanks for trying. The --enable-silent-rules is probably not needed
> unless you've somehow overridden the tarball shipped default (...one can
> do it by various methods (the reason the enable and disable are always
> both available as configure options), but it is not common).
>
> ---
> Of course my compiles with your configure

:-)

> ...
> With the jitter.h issue could you try changing the two calls to rand()
> to std::rand() (a) and then at the top of jitter.h just after the
> comment about c++ variants of c includes add an include of cstdlib so it
> looks like:
>
> // C++ variants of C standard header files
> #include <cstdlib>
>
> Then try the make (the compiles) again?
>
> (a) - What those always should have been I think and the first thing I
> see which might be wrong. I see on searching a few more bare rand()
> calls sitting in the code too which might also cause you trouble
> compiling if this the issue (some in pattern.cpp). Hmm, wonder why those
> not an issue before for you if so...

tomorrow night.  factoid - when the alpha.10064268 was published, missing
'std::' prefixes were a problem.  cheers.


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/28/21 12:27 PM, jr wrote:
> > ...
> With the jitter.h issue could you try changing the two calls to rand()
> to std::rand() (a) and then at the top of jitter.h just after the
> comment about c++ variants of c includes add an include of cstdlib so it
> looks like:
>
> // C++ variants of C standard header files
> #include <cstdlib>
>
> Then try the make (the compiles) again?

worked a treat, install tonight.  thanks.  patch attached, in case other Linux
users have use for it.


regards, jr.

Post a reply to this message

Attachments:
Download 'patch20210428.txt' (1 KB)

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 4/28/21 12:27 PM, jr wrote:
> > > ...
> > Then try the make (the compiles) again?
>
> worked a treat, install tonight. ...

have trouble due to one of the includes.  scene + output attached; 'logo.inc' is
symlinked into povr's include dir.


regards, jr.

Post a reply to this message

Attachments:
Download 'povr.txt' (3 KB)

On 5/1/21 4:09 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>> On 4/28/21 12:27 PM, jr wrote:
>>>> ...
>>> Then try the make (the compiles) again?
>>
>> worked a treat, install tonight. ...
> 
> have trouble due to one of the includes.  scene + output attached; 'logo.inc' is
> symlinked into povr's include dir.
> 
> 
> regards, jr.
>

Thanks!

First, in include/shapes.inc - before installing in a directory, try 
adding an include to transforms.inc just below the include for 
functions.inc so the includes at top look like:


#include "functions.inc"  // <-- Dependency on povr's f_supertorus()
#include "transforms.inc" // <-- Several transform macros are used

In my cut down set of core includes, I tried to have only the necessary 
includes to save on parsing time and core maintenance. I've gotten it 
wrong(1).

---
(1) - I had it in my head if I had tests including each of the shipped 
includes, I'd pick up any dependencies, but you have to actually call 
each macro and I don't yet, which means probably other include and macro 
issues are lurking. :-(  More include macro self testing required I 
guess!

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/1/21 4:09 PM, jr wrote:
> > ...
> > have trouble due to one of the includes.  ...
>
> Thanks!
>
> First, in include/shapes.inc - before installing in a directory, try
> adding an include to transforms.inc just below the include for
> functions.inc so the includes at top look like:
>
> #include "functions.inc"  // <-- Dependency on povr's f_supertorus()
> #include "transforms.inc" // <-- Several transform macros are used

ok, that solved the problem.  cheers.


> ... which means ... More include macro self testing required I
> guess!

if test parameters can be "presented" as sets, stored in an array of 'array
mixed' for example, foreach might be of help automating the running.
(if there's (small) help I can provide, ask)


regards, jr.

Post a reply to this message

On 4/26/21 7:42 AM, William F Pokorny wrote:
> Ref:
> 
>
http://news.povray.org/povray.binaries.programming/message/%3C6086a32c%40news.povray.org%3E/#%3C6086a32c%40news.povray.org%3E

> 
> 
> Web message: 6086a32c@news.povray.org
> 
> ---

In working with Tor Olav's idea for a more accurate VAngle macro, I 
discovered the lower case identifier checking(1) is far too expensive 
when making a million calls to a macro with internal #local identifiers.

For now, I recommend configuration with --disable-no-lc-identifiers, if 
running scenes calling macros with internal identifiers a great many times.

Bill P.

(1) - I'm using c++11 regex at the moment. I've noted some complaints 
about performance of std regex, but whether it's that or just how our 
macros work in being re-read / interpreted on each call - I don't know. 
Might be significant expense is unavoidable and the case checking should 
not be the default behavior.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/26/21 7:42 AM, William F Pokorny wrote:
> > Ref:
> >
> >
http://news.povray.org/povray.binaries.programming/message/%3C6086a32c%40news.povray.org%3E/#%3C6086a32c%40news.pov
ray.org%3E
> >
> >
> > Web message: 6086a32c@news.povray.org
> >
> > ---
>
> In working with Tor Olav's idea for a more accurate VAngle macro, I
> discovered the lower case identifier checking(1) is far too expensive
> when making a million calls to a macro with internal #local identifiers.
>
> For now, I recommend configuration with --disable-no-lc-identifiers, if
> running scenes calling macros with internal identifiers a great many times.
>
> Bill P.
>
> (1) - I'm using c++11 regex at the moment. I've noted some complaints
> about performance of std regex, but whether it's that or just how our
> macros work in being re-read / interpreted on each call - I don't know.
> Might be significant expense is unavoidable and the case checking should
> not be the default behavior.

You seem to solve so many issues in that linux only branch, is there a chance
that some of those fix propagate to master or do they already? Sorry if this is
not what you were referring to at all, but  some unjustified overhead to the use
of separated pov macro files was mentioned numerous times by Clipka and
supposedly solved in his branch, just in case.

Post a reply to this message

On 5/13/21 11:43 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> You seem to solve so many issues in that linux only branch, is there a chance
> that some of those fix propagate to master or do they already? 

They don't get into v3.8 master today as it is not being updated for a 
couple years. Where I believe fixes could be adopted more or less 
directly by the v3.8 master branch, I make a point to publish them on 
this news server or sometimes on github.

If mainstream work resumes, I have some hope the investigative 
information on issues will be of help, if not always my code changes.

> Sorry if this is
> not what you were referring to at all, but some unjustified overhead to the use
> of separated pov macro files was mentioned numerous times by Clipka and
> supposedly solved in his branch, just in case.
> 

I believe the v3.8 master branch, as it sits, has all Christoph's 
completed macro performance enhancements. So my branch, hgpovray38 and 
qtpovray have them too being based on that code - unless I've missed 
something.

Bill P.

Post a reply to this message