hi,

> The unix folder in our repo is littered with various files ...
> Make recommendations how to get them back up to snuff if they
> could still be of use.

regarding 'unix/icons/*.png'.  I think they could be installed under
'/usr/share/icons/', perhaps '/usr/share/icons/POV_Ray/'?  would require
organising them by size, and renaming, to accommodate the existing conventions.
benefit: would be available in "desktop environments" (Gnome/KDE/etc).

the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
'*.x?m' files could go under '/usr/share/pixmaps/', I suggest.

(either '/usr/share/' or '/usr/local/share/' would do.)


regards, jr.

Post a reply to this message

Am 03.08.2021 um 18:04 schrieb jr:

> the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
> '*.x?m' files could go under '/usr/share/pixmaps/', I suggest.

I'm not 100% sure about the `README.*` files off the top of my head, but 
`install` should be present in the main folder of the tarball as `INSTALL`.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 03.08.2021 um 18:04 schrieb jr:
>
> > the 'install' and 'README.*' weren't included in the 'povunix' tarball.  the
> > '*.x?m' files could go under '/usr/share/pixmaps/', I suggest.
>
> I'm not 100% sure about the `README.*` files off the top of my head, but
> `install` should be present in the main folder of the tarball as `INSTALL`.

ah, found the 'README.*'s -- once I looked in the correct directory.  (will get
back on these in a couple of days)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> ah, found the 'README.*'s -- once I looked in the correct directory.  (will get
> back on these in a couple of days)

the 'NEWS' file makes it clear the release is source only, so 'README.bin' could
simply be deleted.  the 'README' and 'README.md' files are, essentially,
identical. suggest updating the 'Dependencies' and 'Generating configure..'
sections in 'README.md', and rename that to 'README'.  the 'README.unix' too
needs some updating (from v3.6); I think that file will become (more) relevant
again (cf X support).

the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
"migrate" to the archive's top-level directory.


regards, jr.

Post a reply to this message

Am 05.08.2021 um 12:05 schrieb jr:

> the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
> "migrate" to the archive's top-level directory.

That's where they currently are in the tarball, are they not?

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 12:05 schrieb jr:
>
> > the 'ChangeLog', 'AUTHORS', 'COPYING', 'NEWS', and 'README*' files ought to
> > "migrate" to the archive's top-level directory.
>
> That's where they currently are in the tarball, are they not?

I was looking at the /unix/ files (only).  duplicates can just be deleted.  the
'README.md' in the top-level dir is newer, still suggest that should become
"the" new 'README'; then only 'README.unix' needs moving up.


regards, jr.

Post a reply to this message

Am 05.08.2021 um 16:31 schrieb jr:

> 'README.md' in the top-level dir is newer, still suggest that should become
> "the" new 'README'; then only 'README.unix' needs moving up.

No, not really. `README.md` is specificially aimed at someone looking at 
the entire repository package (or, even more to the point, someone 
looking at the repository on GitHub).

The `README` in the Unix-specific package should be aimed specifically 
at someone looking at that particular tarball.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 16:31 schrieb jr:
>
> > 'README.md' in the top-level dir is newer, still suggest that should become
> > "the" new 'README'; then only 'README.unix' needs moving up.
>
> No, not really. `README.md` is specificially aimed at someone looking at
> the entire repository package (or, even more to the point, someone
> looking at the repository on GitHub).

then, surely, it should be on github, and not in the archive; a paragraph in the
'README' with repository url would suffice (to my thinking).


> The `README` in the Unix-specific package should be aimed specifically
> at someone looking at that particular tarball.

agree.  and that tarball will already have been downloaded.  so I'd be looking
for intro/overview + general instructions - only.

anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
high priority for you, I feel, so why even have tarballs?  would just "git
clone" not be preferential?

(this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
development code resides "in the cloud" now rather than on own(ed) server(s))

regards, jr.

Post a reply to this message

Am 05.08.2021 um 18:02 schrieb jr:

> anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
> high priority for you, I feel, so why even have tarballs?  would just "git
> clone" not be preferential?

I think that's a severe misunderstanding.

My *NIX expertise is very low, that's why I'm not doing much for *NIX.

That doesn't mean I don't care. It just means I can't do.

> (this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
> development code resides "in the cloud" now rather than on own(ed) server(s))

It has been ever since we moved to a Git-based solution, right at the 
time of the 3.7.0.0 release.

And to be frank, the GitHub infrastructure around the repo has been 
quite an asset in the development work ever since. With the manpower 
available to us, it would have been impossible to set up (let alone 
maintain!) anything even remotely like it on our own turf.

As a matter of fact, *NIX-ness might have been the feature to benefit 
most. With the dev team stocked pretty much with pure Windows jockeys, 
automated test builds were the only thing that had us on our toes 
regarding *NIX-incompatibilities. Setting up such facilities on our own 
would have required quite the effort.

Automated test builds also helped a lot to get us through the times when 
C++11 and clang both started to see widespread use, sending additional 
ripples across the boost library, and opened up new portability pitfalls 
due to incomatibilities between ever shifting boost versions, certain 
constructs that turned out to no longer work in C++11, and the like. 
With us Windows jockeys having no (or only cumbersome) access to a truly 
C++11-compatible (let alone C++11-strict) development environment back 
then, the availability of not just one but three(!) independent 
free-for-open-source hosted build test services was invaluable to keep 
POV-Ray compatible with all the fast-changing world of C++ back then, 
both the established and the emerging.

We also got some feedback and contributions via GitHub that we might not 
have gotten otherwise. Certainly not on as large a scale as in CompuServ 
times, but still.

Among those who got into touch with us were the folks who maintain the 
"homebrew" packages to provide *NIX software for MacOS. Which put 
official MacOS compatibility back on the menu, after it had already 
dropped off the back of the truck in the years prior.

The issue tracker also proved useful, if only because it meant we no 
longer had to waste time keeping spammers out of our self-hosted bug 
tracker.

And the fact that *NIX tarballs are back on the menu is also courtesy of 
GitHub, because as we now migrated all the automated build tests from 
3rd party services to GitHub's new own, we found that we could easily do 
additional stuff whenever we were to auto-build Windows binaries. Even 
stuff that would require a *NIX machine to run. (Or a MacOS machine, for 
that matter, but that's not a thing that has manifested so far). So we 
added *NIX tarballs to that build process.

And a developers' manual, just because we could. I had already set up a 
few scripts and configs for that purpose years ago for my own use, but 
never got around to setting up a channel for publishing the generated 
documents.

Which is another boon of GitHub: It is so much easier to set up a new 
release there, with any arbitrary set of associated downloadables, than 
it would be on our own web server.

Which is what has gotten you folks each and every alpha release since 
v3.7.0.0. I have no access to the web server to bundle up and publish 
releases there, and I wouldn't have dared to bother Chris with anything 
other than betas or better. Let alone that it would have taken a couple 
of days minimum (if not weeks) for each such release to eventually make 
it onto some downloadable page.

I wouldn't even have seen the benefit of such releases in the first 
place. It was more a matter of, "hey, we can do this on a regular basis 
with almost zero effort, so why not."

And I won't even mention the occasional experimental build, such as the 
OpenType support builds.

Even whether beta.1 would be out yet, without GitHub's ease of deploying 
software, is anybody's guess. It might still be in the pipeline between 
me and Chris Cason. Or I might still be procrastinating about even 
actually running the build process on my local machine. Having GitHub 
run it is so much easier and leaves far less room for PEBCAK errors, 
once the process has been set up.


There's no fault in being somewhat suspicious of 3rd party services like 
GitHub. But let that not blind you to their benefits.

Division of labour has been one of the most efficient strategies in the 
history of humanity, and this is just another application of that principle.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 05.08.2021 um 18:02 schrieb jr:
>
> > anyway, the whole thing makes me wonder why you .. bother.  *NIX-ness is not a
> > high priority for you, I feel, so why even have tarballs?  would just "git
> > clone" not be preferential?
>
> I think that's a severe misunderstanding.
>
> My *NIX expertise is very low, that's why I'm not doing much for *NIX.
>
> That doesn't mean I don't care. It just means I can't do.

glad to read this.  (very) probably I read too much into things.  (like your
post re declare=X=Y syntax, where you wrote using a "faux Windows command line";
cannot imagine a shortage of (computing) resource on your side, so wondered why
isn't he using a VM with a BSD or some Linux, then a "real" command-line would
be at hand)


> > (this rant is "tainted" -- probably -- by your mentioning that even the POV-Ray
> > development code resides "in the cloud" now rather than on own(ed) server(s))
>
> It has been ever since we moved to a Git-based solution, right at the
> time of the 3.7.0.0 release.
> ...
> We also got some feedback and contributions via GitHub that we might not
> have gotten otherwise. Certainly not on as large a scale as in CompuServ
> times, but still.
>
> Among those who got into touch with us were the folks who maintain the
> "homebrew" packages to provide *NIX software for MacOS. Which put
> official MacOS compatibility back on the menu, after it had already
> dropped off the back of the truck in the years prior.

additional channels of communication is useful.


> ...
> And a developers' manual, just because we could. I had already set up a
> few scripts and configs for that purpose years ago for my own use, but
> never got around to setting up a channel for publishing the generated
> documents.

moot, of course, but wonder whether publishing that to the wiki would have been
so very different (time+effort-wise).


> ...
> There's no fault in being somewhat suspicious of 3rd party services like
> GitHub. But let that not blind you to their benefits.

personally, my main "beef" with such sites is that in order to orient myself and
look at some info, my browser has to divulge all sorts of info about the system
it's running on.  and a requirement to create an account just to comment/add an
issue? when a captcha to confirm it's not a bot would do.  (the IP address is
logged anyway)


> Division of labour has been one of the most efficient strategies in the
> history of humanity, and this is just another application of that principle.

sure.  true also of alternatives, like eg 'fossil'.


regards, jr.

Post a reply to this message