POV-Ray : Newsgroups : povray.general : gamma issues 3.8 Server Time
6 Oct 2022 22:11:48 EDT (-0400)
  gamma issues 3.8 (Message 5 to 14 of 24)  
<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: clipka
Subject: Re: gamma issues 3.8
Date: 16 Jun 2021 16:26:32
Message: <60ca5e78$1@news.povray.org>
Am 16.06.2021 um 20:14 schrieb ingo:
> When I move I put dates on boxes. Boxes that have not been opened are
> thrown out unopnend after two years unless they have a red sticker.

So, following that logic, should we just throw away all the sample 
scenes altogether? ;)


> Thinking about this and backwards compatibilty, would it be easier to keep
> a few startegic versions of POV-Ray running, executing, compiling for
> current and future compilers and OS's (3.1g, 3.5, 3.7)? This could give a
> dev more freedom to break things and probably to keep the source cleaner?
> It would also kind of solve the old image problem.

For a purely command-line only thingumajig - no graphical output 
whatsoever - that might be feasible. But porting a graphical user 
interface between different OS versions, different operating systems, 
hardware platforms etc. over and over again... that will almost 
inevitably lead to feature rot, as features not easily portable and not 
strictly necessary will be "temporarily" disabled, others not necessary 
on a particular platform will be amputated and not revived when ported 
to a platform that might benefit from it, and so on...

In the end, the UI versions of the old pieces of software will become 
unusable hunks of rotted code, that aren't worthy of keeping alive.

And then some day command-line interfaces may go out of fashion 
entirely, and the command-line-only strain of the software will suffer 
the same fate, too.


Also, each time the programming language standards change, the old code 
will have to be adapted to work with the new standard. Same deal there: 
Code that was originally clean and sane becomes patched up only at the 
edges that openly exhibit issues, while other portions may be forgotten 
and quietly slip out of alignment, until some day the whole thing comes 
crashing down, because at its core, hidden under layers of patches, its 
bones have become brittle. And the libraries our code relies on will 
also be moving targets, which will break stuff every now and then. Which 
is especially problematic when it's something we're using as extensively 
as the boost thread library.


At some point in time, it will probably be easier to just install an 
emulator or virtual machine, and run old binaries that way.


We've been doing something along those lines with POV-Ray v3.7, at least 
as far as the Unix version goes - putting out maintenance releases to 
keep it compatible with whatever comes our way. But we won't be able to 
keep it supported forever, especially on the Windows platform. We'd 
eventually need to write a brand new front-end for it. Which takes time 
and energy, because the front-end interface differs from that of v3.8. 
And eventually v3.7 will succumb to boost rot, because newer versions of 
boost will grow more and more incompatibilities with our code, and 
eventually cease to even support what we're using it for, because that 
portion of boost is effectively outdated already; while the older 
versions of boost will grow more and more incompatibilities with modern 
compilers, and be unavailable for more and more modern target platforms. 
And ripping out boost and replacing it with something else may turn out 
to be more work than it's worth, due to how intensively we were using it 
in v3.7. At that point, v3.7 will go the way of the Dodo.

The good news is that v3.8 will be reasonably close to v3.7 in its 
behavior, and hopefully work as a plug-in replacement. And work for 
ripping out boost (the most extensively used portions anyway) had almost 
finished in v3.8 (in fact it had, but we're reverting back to before 
that for v3.8.0), so it'll be much less susceptible to poorly aging 
libraries, and thus might be a lot easier to keep alive in the long run 
than poor old v3.7.

In fact, it might even be easier to revive any of the older versions 
than to keep v3.7 alive. v3.6.2 and earlier versions didn't use boost at 
all. Of course they also didn't support multithreading.


Well, so much for my crystal ball peek into the future, anyway. Only 
time will tell how much I'm over- or underestimating the troubles involved.


> Dreaming, maybe a future povray parser could just start an other engine
> depending on the #version of the scene file.
> 
> (I have no idea of the complexity of all that)

That won't fly at all. At best, the combo of parser and render engine 
could be exchanged. But even that would require a well-defined interface 
to plug those pieces into a front-end. We don't have such a thing at 
present, and I dare say we never will. Not a stable one, at any rate. 
Which defies the whole idea. Oddly enough, we'll probably continue trying.

Well, actually we currently have _two_ such interfaces: The POVMS 
interface and the VFE. Neither is anywhere close to intuitive though (at 
least *I* haven't gotten a good grasp on either of them yet, and it's 
not like I'm totally new to the source code), and I wouldn't want to 
have to interface to either of them. And neither seems to be 
particularly suited to just exchanging the back-end on the fly.


> Is there anything of a time frame, weeks, months, less than a year and a
> halve? Currently my time is limited but it will change towards the end of
> the year.

Folks at dev team level are itching to get v3.8.0 out as soon as quality 
concerns permit. I'm pretty sure we'll have the first beta before the 
month is over. How quickly things progress from then on depends; my 
estimates vary between anything from another month (when I'm feeling 
excessively optimistic) to half a year (when I'm extrapolating from past 
frustration). It certainly won't take as long as the v3.7.0 beta phase.


Post a reply to this message

From: ingo
Subject: Re: gamma issues 3.8
Date: 16 Jun 2021 17:08:49
Message: <XnsAD4BEB72182seed7@news.povray.org>
in news:60ca5e78$1@news.povray.org clipka wrote:

> Folks at dev team level are itching to get v3.8.0 out as soon as
> quality concerns permit.


Well, let's start look for the boxes with red stickers then.


-- 
https://ingoogni.nl


Post a reply to this message

From: clipka
Subject: Re: gamma issues 3.8
Date: 16 Jun 2021 19:29:18
Message: <60ca894e$1@news.povray.org>
Am 16.06.2021 um 22:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> What I'd really like to see is some esteemed members of the community
>> sticking their heads together, looking through the sample scenes, and
>> then deciding, on a case-by-case basis, how to proceed with the scene.
> 
> Certainly could do that, although AFAICR, there were a LOT of scenes in the
> distribution...  IIRC, it's something like > 2600 files.

2579 in v3.7.

But of those,

- 312 are in the `previews` subdirectory, containing nothing but 
pre-rendered images of scenes, and

- 1778 are in the `templates` subdirectory, containing short scene 
snippets, and typically coming in pairs of one text file and one 
rendered image. Plus a few HTML files. So that's a guesstimated ~850 
code snippets.

That leaves us with <500 files making up genuine scenes, organized into 
312 distinct scenes (judging by the number of preview images).


Of course those ~850 code snippets also might warrant getting a review, 
possibly even more so than the sample scenes.


> I'm not sure what the best way to attack this is, but if I were gonna play
> Project Manager, I'd suggest that an outline was made by outputting a directory
> tree, and then people with the artistic and technical eyes for detail could do a
> quick sifting through the rendered scenes to tag the most egregious examples, or
> using knowledge of the code features to pick out the ones that would need
> editing due to deprecated keywords/syntax/code structure or other such things
> that don't necessarily show themselves in the renders.

I've thrown together something using GitHub Wiki on our repo; please 
have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review 
to see whether that might be a useful tool to manage this task, and how 
you think it could be improved.


Post a reply to this message

From: Bald Eagle
Subject: Re: gamma issues 3.8
Date: 16 Jun 2021 21:45:00
Message: <web.60caa8ed490c1b141f9dae3025979125@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

....

> I've thrown together something using GitHub Wiki on our repo; please
> have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review
> to see whether that might be a useful tool to manage this task, and how
> you think it could be improved.

Do you sell phials of the potion that allows you to do the work of 10 people in
mere minutes?


Are there any guidelines that we're following with regard to file formatting?
Indentation - tabs, spaces, doesn't matter...

Many files say something to the effect of
"Persistence Of Vision raytracer version 3.5 sample file."

but then there is #version  3.7;

update to make consistent?

scenes/objects/ttf1.pov is ... heinous?
I'm guessing part of this project is to make them ... better?

fonts/typefaces that are shipped are:
crystal.ttf
cyrvetic.ttf
povlogo.ttf
timrom.ttf

I recall you recently calling out timrom - are we deprecating its usage until we
find something better?  (I like the seriffage of jsMath-cmmi10.ttf and
jsMath-cmti10.ttf)

Inquiring minds want to know!  :)


Post a reply to this message

From: ingo
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 01:40:41
Message: <XnsAD4C4E16A3C35seed7@news.povray.org>
in news:web.60caa8ed490c1b141f9dae3025979125@news.povray.org Bald Eagle 
wrote:

> Indentation - tabs, spaces, doesn't matter...
> 

I would not bother with that. All together it shows POV-Ray as it is.

-- 
https://ingoogni.nl


Post a reply to this message

From: clipka
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 03:16:47
Message: <60caf6df$1@news.povray.org>
Am 17.06.2021 um 03:44 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
> ....
> 
>> I've thrown together something using GitHub Wiki on our repo; please
>> have a look at https://github.com/POV-Ray/povray/wiki/Scene-Files-Review
>> to see whether that might be a useful tool to manage this task, and how
>> you think it could be improved.
> 
> Do you sell phials of the potion that allows you to do the work of 10 people in
> mere minutes?

If you're talking about the list of scenes, that's just the miracle of 
Unix command-line tools (on a Windows machine no less) to get a raw 
list, and a text editor with good find/replace to bring it into the 
GitHub Markdown format.

The real work only starts from there: What do we even _do_ with this list?


> Are there any guidelines that we're following with regard to file formatting?
> Indentation - tabs, spaces, doesn't matter...

Well... there's some topic for discussion for you.

Me, personally, I would LOVE to see consistent formatting throughout all 
the sample scenes. Preferably MY own favorite style of course. (The 
style used in the "Insert Menu" sample snippets, for instance, is an 
abomination. No offense, Friedrich.)


One thing really worth investigating though is whether there are any 
lowercase variable names in those scenes - because those are very 
strongly non-recommended. William Pokorny might be able to help with 
that: If I understand correctly he has a version of the parser that 
warns on lowercase variables.

Also, while it might be argued to keep the file formatting intact to 
reflect the wide variety in that respect, I'd really love to see at 
least the file headers standardized. Again, my personal opinion.


> Many files say something to the effect of
> "Persistence Of Vision raytracer version 3.5 sample file."
> 
> but then there is #version  3.7;
> 
> update to make consistent?

Another point worth discussing: Should it be the version in which the 
sample file was first introduced, the one in which it was last updated, 
the one that it now requires as minimum, or the one it will ship with 
(i.e. v3.8)?


> scenes/objects/ttf1.pov is ... heinous?
> I'm guessing part of this project is to make them ... better?

I would think so.
Oh, by the way: That particular scene should be called out for showing 
an outdated version number in the output image.

> fonts/typefaces that are shipped are:
> crystal.ttf
> cyrvetic.ttf
> povlogo.ttf
> timrom.ttf
> 
> I recall you recently calling out timrom - are we deprecating its usage until we
> find something better?  (I like the seriffage of jsMath-cmmi10.ttf and
> jsMath-cmti10.ttf)

Unfortunately we're stuck with whatever fonts will ship with POV-Ray 
v3.8.0. Removing any of the fonts from the list is a no-go for 
compatibility reasons, and adding any other fonts means starting a 
non-trivial endeavor of selecting fonts based on (a) artistic quality, 
(b) technical quality, (c) size, (d) set of characters covered, (e) 
licensing issues, and presumably (f) then some.

The font that really got under my skin was cyrvetic.ttf. But if we stick 
to ASCII, the fonts are useful. Though arguably not the prettiest.


> Inquiring minds want to know!  :)

Team up and discuss. This is (or should be) as much your software 
package as it is mine.


Post a reply to this message

From: Bald Eagle
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 06:20:00
Message: <web.60cb21b7490c1b141f9dae3025979125@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

> If you're talking about the list of scenes, that's just the miracle of
> Unix command-line tools (on a Windows machine no less) to get a raw
> list, and a text editor with good find/replace to bring it into the
> GitHub Markdown format.

And lots and lots of practice and experience.

> The real work only starts from there: What do we even _do_ with this list?

Oh how right you are.


> Me, personally, I would LOVE to see consistent formatting throughout all
> the sample scenes. Preferably MY own favorite style of course. (The
> style used in the "Insert Menu" sample snippets, for instance, is an
> abomination. No offense, Friedrich.)

Yes, I've been through those - but on the flip-side, he got them done enough to
work reliably and ship out over all these years.  Maybe there is some unix
scripting that could address that aspect to some degree...?

> One thing really worth investigating though is whether there are any
> lowercase variable names in those scenes - because those are very
> strongly non-recommended. William Pokorny might be able to help with
> that: If I understand correctly he has a version of the parser that
> warns on lowercase variables.

Very good point.

> Also, while it might be argued to keep the file formatting intact to
> reflect the wide variety in that respect, I'd really love to see at
> least the file headers standardized. Again, my personal opinion.

Following up on the above idea, maybe there's a tag in the comments that could
be used to help introduce some automation to the process?  So, just as an
off-the-top-of-the-head example, html has <header> <\header> and a script could
just replace everything in between.

> > Many files say something to the effect of
> > "Persistence Of Vision raytracer version 3.5 sample file."
> >
> > but then there is #version  3.7;
> >
> > update to make consistent?
>
> Another point worth discussing: Should it be the version in which the
> sample file was first introduced, the one in which it was last updated,
> the one that it now requires as minimum, or the one it will ship with
> (i.e. v3.8)?

Depending on the scene, put a file history?
/*
v 3.5
updated 1/2/03 by Joe Schmo for v 3.6
update 04/19/2018 by John Q. Public for v 3.7
min version required for proper usage: v 3.7
This file provided as part of the v 3.8 distribution package
*/


> > scenes/objects/ttf1.pov is ... heinous?
> > I'm guessing part of this project is to make them ... better?
>
> I would think so.

See attached.

> Oh, by the way: That particular scene should be called out for showing
> an outdated version number in the output image.

Yes,. It uses:
concat("Version:", str(version, 0, 1))
which is the version set in the scene, not a saved variable of the running
version.
Maybe it should display both?


> Team up and discuss. This is (or should be) as much your software
> package as it is mine.

Right-o.


Post a reply to this message


Attachments:
Download 'ttf1.png' (615 KB)

Preview of image 'ttf1.png'
ttf1.png


 

From: Bald Eagle
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 06:45:00
Message: <web.60cb26e8490c1b141f9dae3025979125@news.povray.org>
Ah crap.


I forgot to mention the warnings:

File 'ttf1.pov' line 26: Possible Parse Error: Text may not be displayed as
 expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
 later.
File 'ttf1.pov' line 39: Possible Parse Error: Text may not be displayed as
 expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
 later.


I don't see in the User Manual (wiki) where this is addressed.
https://wiki.povray.org/content/Reference:Text

What should I do to get rid of these?


Post a reply to this message

From: Cousin Ricky
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 11:11:31
Message: <60cb6623$1@news.povray.org>
On 2021-06-17 6:41 AM (-4), Bald Eagle wrote:
> 
> File 'ttf1.pov' line 26: Possible Parse Error: Text may not be displayed as
>  expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
>  later.
> File 'ttf1.pov' line 39: Possible Parse Error: Text may not be displayed as
>  expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
>  later.

These warnings do not appear with my rolled back version
(3.8.0-alpha.9945627).


Post a reply to this message

From: clipka
Subject: Re: gamma issues 3.8
Date: 17 Jun 2021 12:39:17
Message: <60cb7ab5$1@news.povray.org>
Am 17.06.2021 um 12:41 schrieb Bald Eagle:

> File 'ttf1.pov' line 26: Possible Parse Error: Text may not be displayed as
>   expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
>   later.
> File 'ttf1.pov' line 39: Possible Parse Error: Text may not be displayed as
>   expected. Please refer to the user manual regarding changes in POV-Ray v3.8 and
>   later.
> 
> 
> I don't see in the User Manual (wiki) where this is addressed.
> https://wiki.povray.org/content/Reference:Text
> 
> What should I do to get rid of these?

Those warnings are... um... special. They should be going away as soon 
as we have the first v3.8.0-beta.

(Technical background: Those warnings are related to my work to clean up 
character encoding stuff in the parser and beyond. It has been decided 
to back out those changes in order to not break backward compatibility, 
while also not spending ages to try to somehow mimick the old behavior 
in legacy scenes.)


Post a reply to this message

<<< Previous 4 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.