 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.06.2021 um 22:17 schrieb Bald Eagle:
> clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
