It's official now:

https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1


A note to Unix users:

We're now providing Unix-specific source code packages again. We 
recommend that you build from the `povunix-*.tar.gz` tarball, rather 
than the "Source code (tar.gz)" or "Source code (zip)" packages or the 
raw repo contents.


A note to Windows XP users:

Let us know if there are still any of you out there. Otherwise we'll 
presume that Vista (and higher) support should be enough for everybody.


Happy Testing!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> It's official now:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1
>
>
> A note to Unix users:
>
> We're now providing Unix-specific source code packages again. We
> recommend that you build from the `povunix-*.tar.gz` tarball, rather
> than the "Source code (tar.gz)" or "Source code (zip)" packages or the
> raw repo contents.
>
>
> A note to Windows XP users:
>
> Let us know if there are still any of you out there. Otherwise we'll
> presume that Vista (and higher) support should be enough for everybody.
>
>
> Happy Testing!

A thousand thanks, though this deprives me of an excuse to further cleanup my
front end addon with the now uniformly supported stochastic AA !
The Doxygen 1700+ pages auto generated developer doc is insanely well formatted
!

Post a reply to this message

Am 11.07.2021 um 14:54 schrieb Mr:

> The Doxygen 1700+ pages auto generated developer doc is insanely well formatted
> !

Credit for that goes almost entirely to the authors of Doxygen and the 
toolchain for its PDF export. LaTeX may be key there, I guess.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> It's official now:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1
>
>
> A note to Unix users:
>
> We're now providing Unix-specific source code packages again. We
> recommend that you build from the `povunix-*.tar.gz` tarball, rather
> than the "Source code (tar.gz)" or "Source code (zip)" packages or the
> raw repo contents.

downloaded the 'povunix' as recommended, was surprised the archive unpacks in
the cwd rather than in a sub-directory.  that said, and one warning (cf
'core/render/trace.cpp') aside, building and install went ok (i5, Slackware
14.2).

(in which scenario is building from "Source code (tar.gz)" still preferred?)


regards, jr.

Post a reply to this message

Am 11.07.2021 um 18:53 schrieb jr:

> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> the cwd rather than in a sub-directory.

If you can help wrangling the `tar` and/or `gzip` command to rectify 
that, I'd appreciate it.

We're currently using the following sequence of commands to bundle the 
files we want:


tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
# Bundle relevant portions of the original source tree, making sure
# to exclude interim products placed there by the prebuild process.
tar -chWf "${tarfile}"          \
   --anchored                    \
   --exclude="*Makefile.am"      \
   --exclude="unix/prebuild*"    \
   --exclude="unix/scripts*"     \
   --exclude="platform/windows"  \
   --exclude="vfe/win"           \
   doc platform source unix vfe  \
   LICENSE README.md changes.txt revision.txt
# Add everything created by the prebuild process, except for some
# interim products created by the prebuild process.
# (Note that some files may have already been added by the previous
# command, so we're using `-u` instead of `-r` to avoid duplicates.)
tar -uhWf "${tarfile}"          \
   --anchored                    \
   --exclude="*Makefile.am"      \
   --exclude="configure.ac"      \
   --exclude="bootstrap"         \
   ${prebuild_made}
# Compress bundle into proper tarball
gzip "${tarfile}"


where `prebuild_made` is a list of files detected as having been created 
by `unix/prebuild.sh`.


> (in which scenario is building from "Source code (tar.gz)" still preferred?)

In the one where you're building for a non-Unix platform but have a ZIP 
file format phobia, I guess.

The "Source code (tar.gz)" and "Source code (zip)" assets are added 
automatically by GitHub, whether we want it to or not.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 11.07.2021 um 18:53 schrieb jr:
>
> > downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> > the cwd rather than in a sub-directory.
>
> If you can help wrangling the `tar` and/or `gzip` command to rectify
> that, I'd appreciate it.
>
> We're currently using the following sequence of commands to bundle the
> files we want:
>
> tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
> # Bundle relevant portions of the original source tree, making sure
> # to exclude interim products placed there by the prebuild process.
> tar -chWf "${tarfile}"          \
>    --anchored                    \
>    --exclude="*Makefile.am"      \
>    --exclude="unix/prebuild*"    \
>    --exclude="unix/scripts*"     \
>    --exclude="platform/windows"  \
>    --exclude="vfe/win"           \
>    doc platform source unix vfe  \
>    LICENSE README.md changes.txt revision.txt
> # Add everything created by the prebuild process, except for some
> # interim products created by the prebuild process.
> # (Note that some files may have already been added by the previous
> # command, so we're using `-u` instead of `-r` to avoid duplicates.)
> tar -uhWf "${tarfile}"          \
>    --anchored                    \
>    --exclude="*Makefile.am"      \
>    --exclude="configure.ac"      \
>    --exclude="bootstrap"         \
>    ${prebuild_made}
> # Compress bundle into proper tarball
> gzip "${tarfile}"
>
> where `prebuild_made` is a list of files detected as having been created
> by `unix/prebuild.sh`.

had not known '--anchored', interesting.  I guess simplest would be just
repacking, something like (any typos mine):

tarfile="povunix-v${POV_RAY_FULL_VERSION}.tar"
  ...
# Compress bundle into proper tarball

mkdir v${POV_RAY_FULL_VERSION}
( cd v${POV_RAY_FULL_VERSION} ; tar -xf ../$tarfile )
rm -f $tarfile
tar $tarfile ${POV_RAY_FULL_VERSION} && sync
gzip "${tarfile}"
rm -fr ${POV_RAY_FULL_VERSION}


> > (in which scenario is building from "Source code (tar.gz)" still preferred?)
>
> In the one where you're building for a non-Unix platform but have a ZIP
> file format phobia, I guess.
>
> The "Source code (tar.gz)" and "Source code (zip)" assets are added
> automatically by GitHub, whether we want it to or not.

ah, ok.  thanks.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ... typos ...  </sigh>  even missed out the cli options, sorry.

mkdir v${POV_RAY_FULL_VERSION}
( cd v${POV_RAY_FULL_VERSION} ; tar -xf ../$tarfile )
rm -f $tarfile
tar -cvf $tarfile v${POV_RAY_FULL_VERSION} && sync
gzip "${tarfile}"
rm -fr v${POV_RAY_FULL_VERSION}


regards, jr.

Post a reply to this message

Am 11.07.2021 um 19:58 schrieb jr:

>>> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
>>> the cwd rather than in a sub-directory.
>>
>> If you can help wrangling the `tar` and/or `gzip` command to rectify
>> that, I'd appreciate it.
...
> had not known '--anchored', interesting.  I guess simplest would be just
> repacking, something like (any typos mine):
...

I think I've found something: Adding `--transform "s,^,FOO/,"` to the 
parameters should do the job (for a suitable definition of `FOO`). 
Requires GNU, but we don't need this to work on end-users' machines.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 11.07.2021 um 19:58 schrieb jr:
>
> >>> downloaded the 'povunix' as recommended, was surprised the archive unpacks in
> >>> the cwd rather than in a sub-directory.
> >>
> >> If you can help wrangling the `tar` and/or `gzip` command to rectify
> >> that, I'd appreciate it.
> ...
> > had not known '--anchored', interesting.  I guess simplest would be just
> > repacking, something like (any typos mine):
> ...
>
> I think I've found something: Adding `--transform "s,^,FOO/,"` to the
> parameters should do the job (for a suitable definition of `FOO`).

works using 'sed'?!  v nice.  (will try and remember to explore this when
opportune)


regards, jr.

Post a reply to this message

Am 12.07.2021 um 00:02 schrieb jr:

>> I think I've found something: Adding `--transform "s,^,FOO/,"` to the
>> parameters should do the job (for a suitable definition of `FOO`).
> 
> works using 'sed'?!  v nice.  (will try and remember to explore this when
> opportune)

Not sure if it uses `sed` under the hood, but the syntax seems to be 
`sed`-like, yes.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> It's official now:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1
>
>
> A note to Unix users:
>
> We're now providing Unix-specific source code packages again. We
> recommend that you build from the `povunix-*.tar.gz` tarball, rather
> than the "Source code (tar.gz)" or "Source code (zip)" packages or the
> raw repo contents.
>
>
> A note to Windows XP users:
>
> Let us know if there are still any of you out there. Otherwise we'll
> presume that Vista (and higher) support should be enough for everybody.
>
>
> Happy Testing!

I could install and run the benchmark without any problems on two Linux
machines.

Thank you Clipka.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.07.2021 um 00:02 schrieb jr:
>
> >> I think I've found something ...

there was one other (small) thing, forgot to mention.  during installation, if
another 3.8 version already exists, the old 'povray.{conf,ini}' files get
renamed to '*.bak' and new files are put in place.  this has the disadvantage
that the existing povray no longer works as configured.  the usual practice is
to leave existing files alone if found, and create the distributed as
'povray.{conf,ini}.new'; "admin" then integrates manually.


regards, jr.

Post a reply to this message

Am 14.07.2021 um 11:34 schrieb jr:

> there was one other (small) thing, forgot to mention.  during installation, if
> another 3.8 version already exists, the old 'povray.{conf,ini}' files get
> renamed to '*.bak' and new files are put in place.  this has the disadvantage
> that the existing povray no longer works as configured.  the usual practice is
> to leave existing files alone if found, and create the distributed as
> 'povray.{conf,ini}.new'; "admin" then integrates manually.

Can you please file an issue report on GitHub, to put a propoer pin in this?

I tend to lose track of stuff mentioned only on the newsgroups.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 14.07.2021 um 11:34 schrieb jr:
>
> > there was one other (small) thing, forgot to mention.  during installation, if
> > another 3.8 version already exists, the old 'povray.{conf,ini}' files get
> > renamed to '*.bak' and new files are put in place.  this has the disadvantage
> > that the existing povray no longer works as configured.  the usual practice is
> > to leave existing files alone if found, and create the distributed as
> > 'povray.{conf,ini}.new'; "admin" then integrates manually.
>
> Can you please file an issue report on GitHub, to put a propoer pin in this?

went there, cannot add an "issue" without acquiring an account.  sorry.


> I tend to lose track of stuff mentioned only on the newsgroups.

perhaps a "kind soul" with github membership followed this thread and will
create the report.


regards, jr.

Post a reply to this message

Am 15.07.2021 um 16:14 schrieb jr:

>> Can you please file an issue report on GitHub, to put a propoer pin in this?
> 
> went there, cannot add an "issue" without acquiring an account.  sorry.

I'd argue that it's worth it, given that it's free of charge. It may not 
be the last issue you might want to report.

GitHub _is_ our preferred place for bug reports these days.

And we're by far not the only ones. There is an ever growing number of 
other pieces of open source software out there that have GitHub as their 
_only_ official channel for bug reporting. Having a GitHub account opens 
up the door to those, too.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 15.07.2021 um 16:14 schrieb jr:
>
> >> Can you please file an issue report on GitHub, to put a propoer pin in this?
> >
> > went there, cannot add an "issue" without acquiring an account.  sorry.
>
> I'd argue that it's worth it, given that it's free of charge. It may not
> be the last issue you might want to report.

I'm sure that people like you, self-confessed "Windows jockeys" that is, find
the  environment .. conducive to your working.  a bit like Linux distributions,
some people find Ubuntu/Debian "floats their boat".

fwiw, the 'github.com/POV-Ray/povray/tags' page would benefit from showing
checksums (sha256?) for the archives, too.


> GitHub _is_ our preferred place for bug reports these days.

sure.  (though regrettable from my perspective)  as long as no account is needed
to download the source archive.


> And we're by far not the only ones. There is an ever growing number of
> other pieces of open source software ...

the "not the only ones" argument reminds me of an old saying "people, eat more
shit, four billion flies can't be wrong".  fifteen or twenty years ago,
SourceForge was the place to be (seen) on, maybe github will do better, who
knows?


regards, jr.

Post a reply to this message

Am 16.07.2021 um 13:45 schrieb jr:

> fwiw, the 'github.com/POV-Ray/povray/tags' page would benefit from showing
> checksums (sha256?) for the archives, too.

I'm not sure what the benefit of that would be.

If you do not trust to get the proper archives from GitHub, I see no 
reason to trust that you'll see the proper SHAs for those files.

(Or do you mena SHAs of the commits corresponding to those tags? Well, 
the first 7 digits of those _are_ shown on that page; and if you click 
on those, it'll take you to a page where the full SHA of the commit is 
shown in all its glory.)

Now, publishing checksums on the POV-Ray home page, that might be 
another matter. But even then, it only really makes sense for versions 
we build on our own machines and upload to GitHub later. Not so much for 
the betas: They are built directly on GitHub servers.

(And yes, I do trust Microsoft's GitHub servers more than I do my own 
Windows 10 machine.)


>> GitHub _is_ our preferred place for bug reports these days.
> 
> sure.  (though regrettable from my perspective)  as long as no account is needed
> to download the source archive.

These days, there is pretty much no software project that allows the 
reporting of bugs without _some_ form of identification. It's just not 
possible anymore - they'd be swamped by spambots.

And with that in mind, I for one welcome our new insect overl... erm, I 
mean, I for one applaud every project that uses some reasonably common 
bug tracking service, rather than rolling their own. Because although I 
do agree that it sucks to be unable to report a bug without registering 
_somewhere_, in my opinion it sucks less if that registration is good 
for multiple pieces of software that I use.


>> And we're by far not the only ones. There is an ever growing number of
>> other pieces of open source software ...
> 
> the "not the only ones" argument reminds me of an old saying "people, eat more
> shit, four billion flies can't be wrong".  fifteen or twenty years ago,
> SourceForge was the place to be (seen) on, maybe github will do better, who
> knows?

SourceForge thought they could exploit their pole position with 
impunity. Which is how they lost it to GitHub.

We didn't go to GitHub because we thought it was the bee's knees; we 
went there because we decided to set up a public repository, in hopes to 
get more people to contribute - and SourceForge had just gone rogue at 
the time we were ready to actually go ahead with that step. GitHub just 
happened to be pretty much the only contender, and actually we were 
initially quite skeptical, not the least because we had no experience 
with Git in particular nor even any other distributed version control 
system in general.

Looking back, I'm sure it wasn't the worst of choices.


Also, I'm not saying you should join the flies and host your own 
projects there (although I might, if you were to ask for advice in that 
matter). Going with that image, it's more like I'm saying that if you 
want to catch flies, that's where to find lots of them. That's not a 
question of taste - it's just pure matter of fact.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> ... github ...

I suspect you could sell ice boxes to the inuit -- in mid-winter.  ;-)


>> fwiw, ... checksums ...
>
> I'm not sure what the benefit of that would be.
>
> If you do not trust to get the proper archives from GitHub, I see no
> reason to trust that you'll see the proper SHAs for those files.

not worried/paranoid about GitHub as an organisation, just wary of .. clever
individuals, who always find some nook or cranny.


regards, jr.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> ... v3.8.0-beta.1 ...
> Happy Testing!

when I run the beta with '-cc +w400 +h300 +a +rtr +kla', the preview window pops
up but shows nothing.  the current 'povr' is fine with exact same command-line.


regards, jr.

Post a reply to this message

Am 18.07.2021 um 13:07 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> ... v3.8.0-beta.1 ...
>> Happy Testing!
> 
> when I run the beta with '-cc +w400 +h300 +a +rtr +kla', the preview window pops
> up but shows nothing.  the current 'povr' is fine with exact same command-line.

"povr" is not POV-Ray. It is a derivative work by someone who also 
happens to work on POV.Ray.

I don't have the capacity (nor even an overwiew of what would have to be 
done) to merge Bill's changes into POV-Ray proper.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> when I run the beta with '-cc +w400 +h300 +a +rtr +kla', the preview window pops
> up but shows nothing.
>
Those settings work OK in the Windows version.

Do you correctly have *multiple* camera in your scene for rtr and kla to work
properly? (or a #while/#for loop to generate the multiple cameras?) With just a
single camera in such a scene, the parsing/rendering seems to go into an
endless(?) loop-- although I still see a single render of my scene in the
preview, not a blank screen like you mention.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...With just a
> single camera in such a scene, the parsing/rendering seems to go into an
> endless(?) loop--

I mean an endless loop with the computer chugging away, but doing nothing. The
real-time raytracing feature, when working properly, also generates an endless
looping animation-- but that's with all the new camera positions, one after the
other.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >
> > when I run the beta with '-cc +w400 +h300 +a +rtr +kla', the preview window pops
> > up but shows nothing.
> >
> Those settings work OK in the Windows version.
>
> Do you correctly have *multiple* camera in your scene for rtr and kla to work
> properly? ...

I think so, yes.  the code (and command-line) works fine with one particular
executable (WFP's povr) but not with the official "unofficial" alpha + beta
versions I have.  cheers.


regards, jr.

Post a reply to this message

Rendering a 3.8 version scene which includes functions.inc, I get the 
following parse warning:

"functions.inc" line 167: Parse warning: use of POV-Ray v3.7 keyword 
('deprecated') detected in alleged v3.5 scene.

The only place were version 3.5 is mentioned is precisely at the start 
of functions.inc:

#ifndef(Functions_Inc_Temp)
#declare Functions_Inc_Temp = version;
#version 3.5;
...
#end

At the mentioned line 167 of this /new/ functions.inc shipped with the 
beta, a /new/ if statement has been introduced, not there in previous 
versions:

#if (Functions_Inc_Temp < 3.8)
     #declare deprecated once "f_enneper was broken prior to v3.8; 
results will most likely differ."
              f_enneper = function { internal(18) }
#else
     #declare f_enneper = function { internal(18) }
#end


-- 
Thomas

Post a reply to this message

I still do not understand this parse warning as I do *not* run a version 
3.5 scene. Does it refer to POV-Ray includes which /mention/ version 3.5?
functions.inc seem to be the only include file containing this.

Just a short explanation would be enough about this mysterious warning.

Thanks,

Thomas

Op 19-7-2021 om 14:17 schreef Thomas de Groot:
> Rendering a 3.8 version scene which includes functions.inc, I get the 
> following parse warning:
> 
> "functions.inc" line 167: Parse warning: use of POV-Ray v3.7 keyword 
> ('deprecated') detected in alleged v3.5 scene.
> 
> The only place were version 3.5 is mentioned is precisely at the start 
> of functions.inc:
> 
> #ifndef(Functions_Inc_Temp)
> #declare Functions_Inc_Temp = version;
> #version 3.5;
> ...
> #end
> 
> At the mentioned line 167 of this /new/ functions.inc shipped with the 
> beta, a /new/ if statement has been introduced, not there in previous 
> versions:
> 
> #if (Functions_Inc_Temp < 3.8)
>      #declare deprecated once "f_enneper was broken prior to v3.8; 
> results will most likely differ."
>               f_enneper = function { internal(18) }
> #else
>      #declare f_enneper = function { internal(18) }
> #end
> 
> 


-- 
Thomas

Post a reply to this message

Am 29.07.2021 um 17:45 schrieb Thomas de Groot:
> I still do not understand this parse warning as I do *not* run a version 
> 3.5 scene. Does it refer to POV-Ray includes which /mention/ version 3.5?
> functions.inc seem to be the only include file containing this.
> 
> Just a short explanation would be enough about this mysterious warning.

It's a bug in `functions.inc`: At the start it claims that it needs only 
v3.5, but later it uses the `deprecated` keyword, which wasn't 
introduced until v3.7.

In other words, if someone were to use genuine POV-Ray v3.5, and render 
the scene with that very same include file, they'd get an error message.

The fact that POV-Ray warns about such scenarios is a brand new feature 
of v3.8.0-beta.1.

Post a reply to this message

Op 29/07/2021 om 21:54 schreef clipka:
> Am 29.07.2021 um 17:45 schrieb Thomas de Groot:
>> I still do not understand this parse warning as I do *not* run a 
>> version 3.5 scene. Does it refer to POV-Ray includes which /mention/ 
>> version 3.5?
>> functions.inc seem to be the only include file containing this.
>>
>> Just a short explanation would be enough about this mysterious warning.
> 
> It's a bug in `functions.inc`: At the start it claims that it needs only 
> v3.5, but later it uses the `deprecated` keyword, which wasn't 
> introduced until v3.7.
> 
> In other words, if someone were to use genuine POV-Ray v3.5, and render 
> the scene with that very same include file, they'd get an error message.
> 
> The fact that POV-Ray warns about such scenarios is a brand new feature 
> of v3.8.0-beta.1.

OK. Thanks for this. I shall just close my eyes ;-)

-- 
Thomas

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 29.07.2021 um 17:45 schrieb Thomas de Groot:
> > I still do not understand this parse warning as I do *not* run a version
> > 3.5 scene. Does it refer to POV-Ray includes which /mention/ version 3.5?
> > functions.inc seem to be the only include file containing this.
> >
> > Just a short explanation would be enough about this mysterious warning.
>
> It's a bug in `functions.inc`: At the start it claims that it needs only
> v3.5, but later it uses the `deprecated` keyword, which wasn't
> introduced until v3.7.

fwiw, same bug/keyword use for 'glass_old.inc'.


regards, jr.

Post a reply to this message