Am 06.08.2021 um 15:43 schrieb jr:

>> 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)

I did resort to working with a VM for some time for testing code for 
*NIX compatibility, but given my low knowledge level of the *NIX world I 
found it rather a hassle compared to my Windows jockey mouse-pusher 
comfort zone. Particularly the process of transferring the 
version-to-test to the test VM kept bothering me.

Nowadays I have the Windows Subsystem for Linux at my disposal if needs 
be, which feels a bit more integrated. For instance, I can pop up an 
Ubuntu terminal from my Windows explorer, taking me straight to a 
specific directory on my Windows file system.

It still is a thing I try to avoid though.


So if you see an error with POV-Ray's *NIX command line interface, why 
wouldn't I test it with the Windows pseudo-command line first? If the 
error is there as well, chances are I can fix it from within my comfort 
zone, and don't need to add stress to my life by taking another stroll 
in the *NIX world.

Even if the error I find should turn out to be located in the 
Windows-specific portion of the code, chances are the problem with the 
Unix side of things is very similar in nature. So even if I can't avoid 
a detour through the *NIX world entirely, I'll need to spend less time 
there because I already know what I'm about to encounter there.


>> 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).

Abso-bloody-lutely.

The Wiki is primarily designed to host content entered manually via the 
Wiki interface itself.

I presume there are also channels for bulk uploads of content, but 
they'd have to be in a format supported by the Wiki.

The developers' manual is currently a guesstimated 90% automatically 
generated from the source code, and 10% manually edited information, 
compiled by a dedicated tool that generates either a suite of 
full-fledged HTML pages or a single PDF.

To cram that content into the Wiki would have required writing import 
scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
format, while presumably Jim has just as much knowledge about the format 
generated by said tool (beyond the fact that it's HTML, of course).


Also, the Wiki is not really designed to handle information that may 
change over time.

That's already a bit of a hassle when it comes to changes to the user 
manual as new features are added to the scene language, or limitations 
are lifted, or other some such.

The information in the developers' manual can be even more 
version-specific, especially in times where I'm again doing one of my 
refactoring sprees where I re-arrange parts of the internal 
architecture, or throw away and re-write entire sections of the code.


>> 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.

Does it though? Or is it just set to freely do that, and the other end 
takes the liberty to make use of that?

If you were to bar your browser from divulging that information, would 
you really hit a brick wall?

> 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)

It's been ages since I've seen an issue reporting page that doesn't 
require you to at least disclose your e-mail address. Which is all for 
the better in my opinion, because as a developer I want a chance to 
contact the issue reporters, in case I have further questions.

And a system hosting hundreds - nay, thousands upon thousands - of 
projects, some of which carry big names? Nope, just a captcha won't cut 
it. Even if you can effectively protect against spam that way (which I 
doubt for sites of a certain magnitude), you couldn't protect against 
trolling. And in such a scenario, trolling would happen, period. Maybe 
not to all projects, but to some. Especially the high-profile ones.

(Also, I for one am repulsed by sites that make me count traffic lights 
or bridges or whatever just to get access to them.)

>> 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'.

Now I think you're confusing the technological platform (such as Git) 
with a particular service based on that platform (such as GitHub).

Back when we made the decision, we had our reasons to pick Git as the 
technological platform, and once that had been settled, to choose GitHub 
as the hosting service. I can elaborate why those two specifically, if 
you are interested.

The main point though is that the decision has been made. Whether it is 
the _perfect_ choice is a moot question: Unless some pressing need crops 
up, the hassle of migrating even to a different hosting service - let 
alone an entirely different technological platform - far outweighs any 
benefit such a move might provide in the long run. Let alone that other 
hosting services and platforms also tend to have their downsides.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 06.08.2021 um 15:43 schrieb jr:
> ...
>> [not] using a VM with a BSD or some Linux...
>
> I did resort to working with a VM for some time for testing code for
> *NIX compatibility, but given my low knowledge level of the *NIX world I
> found it rather a hassle compared to my Windows jockey mouse-pusher
> comfort zone. Particularly the process of transferring the
> version-to-test to the test VM kept bothering me.

directory trees/drives can be shared.


> Nowadays I have the Windows Subsystem for Linux at my disposal if needs
> be, which feels a bit more integrated. For instance, I can pop up an
> Ubuntu terminal from my Windows explorer, taking me straight to a
> specific directory on my Windows file system.
>
> It still is a thing I try to avoid though.

</shakes-head>  :-)


> ... So even if I can't avoid
> a detour through the *NIX world entirely, I'll need to spend less time
> there because I already know what I'm about to encounter there.

don't really agree.  for instance, there never has been a functional, let alone
conceptual, equivalent of X on MS Windows.  (was glad to read (in 'INSTALL'?)
that the preview X window proper may be brought back)


>>> And a developers' manual...
>> moot, of course, but wonder whether publishing that to the wiki would have been
>> so very different (time+effort-wise).
>
> Abso-bloody-lutely.
>
> The Wiki is primarily designed to host content entered manually via the
> Wiki interface itself.
>
> I presume there are also channels for bulk uploads of content, but
> they'd have to be in a format supported by the Wiki.
>
> The developers' manual is currently a guesstimated 90% automatically
> generated from the source code, and 10% manually edited information,
> compiled by a dedicated tool that generates either a suite of
> full-fledged HTML pages or a single PDF.
>
> To cram that content into the Wiki would have required writing import
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import
> format, while presumably Jim has just as much knowledge about the format
> generated by said tool (beyond the fact that it's HTML, of course).

well, adding a link to the "suite of full-fledged HTML pages" certainly would
not be too .. taxing.

agree on editing aspects etc, though that doesn't apply for generated stuff.


>> ... my browser has to divulge all sorts of info about the system
>> it's running on.
>
> Does it though? Or is it just set to freely do that, and the other end
> takes the liberty to make use of that?
>
> If you were to bar your browser from divulging that information, would
> you really hit a brick wall?

is besides the point.  I think that the onus is on the site to only ask for what
 is needed.  personally, I take what I need, I do not grab more/everything just
because I can, and expect (of course) the same from others.

my "solution" to this is to use a dedicated machine[*] for all browsing.

[*] a Chromebook, so I have an option to "powerwash" if needed.


>> ... captcha ...
>
> It's been ages since I've seen an issue reporting page that doesn't
> require you to at least disclose your e-mail address. Which is all for
> the better in my opinion, because as a developer I want a chance to
> contact the issue reporters, in case I have further questions.

sure, email would be ok (even with verification ;-)).


>> sure.  true also of alternatives, like eg 'fossil'.
>
> Now I think you're confusing the technological platform (such as Git)
> with a particular service based on that platform (such as GitHub).

perhaps, though it seems comparable to me.


regards, jr.

Post a reply to this message

Am 07.08.2021 um 09:23 schrieb jr:

>>>> And a developers' manual...
...
>> To cram that content into the Wiki would have required writing import
>> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import
>> format, while presumably Jim has just as much knowledge about the format
>> generated by said tool (beyond the fact that it's HTML, of course).
> 
> well, adding a link to the "suite of full-fledged HTML pages" certainly would
> not be too .. taxing.

It still requires to put that army of HTML pages _somewhere_ first.

Did I mention that I do not have access to the POV-Ray web server? Nor 
do I really care to get such access. It's not the kind of work I want to 
put on my plate. I'm no good at it.


>>> sure.  true also of alternatives, like eg 'fossil'.
>>
>> Now I think you're confusing the technological platform (such as Git)
>> with a particular service based on that platform (such as GitHub).
> 
> perhaps, though it seems comparable to me.

Not really.

Technically, they might not differ that much.

In terms of how widespread they are though (and therefore how familiar 
potential contributors might be with them, and how easy it might be to 
find a compatible tool that they would feel comfortable using), Git and 
Fossil are worlds apart.

You can't take two steps in open source development these days without 
stumbling across Git. There's not a single modern development tool out 
there without at least one Git plug-in (except for tools that have Git 
support already built in, or don't provide any plug-in interface at 
all). And the choice of tools for Git is so plentiful that it does 
include quite a few that cater to people who don't have their brain 
wired "the proper git way".

Fossil? The first time I've ever heard of it was when you just brought 
it up.

Post a reply to this message

On 8/6/21 1:46 PM, clipka wrote:
> To cram that content into the Wiki would have required writing import 
> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
> format, while presumably Jim has just as much knowledge about the format 
> generated by said tool (beyond the fact that it's HTML, of course).

don't even /try/ to involve me. haven't you guys noticed that i've not 
been replying to the documentation updates / corrections that y'all have 
been flinging over the wall. i've been trying to step away from the 
curator role that i didn't really sign up for. hell...  i /still/ need 
to finish debugging the php / mysql changes to wikidocgen ( after server 
crash ) so that ought to be a clue as to my motivation.

Post a reply to this message

On 7/08/2021 18:12, clipka wrote:
> Did I mention that I do not have access to the POV-Ray web server? Nor 
> do I really care to get such access. It's not the kind of work I want to 
> put on my plate. I'm no good at it.

Yeah I don't blame you. Before the crash the old system was hanging on 
with chewing gum and sticky-tape. Now that we're up to date with all the 
latest libs and PHP version it's a little more amenable to having 
another person edit stuff, but it's still very much a case of 'ssh into 
the server and edit the PHP pages with VI'. All pages require 
interleaving of PHP and HTML as the website theme and individual page 
sections are pulled in from a common PHP library.

Oh, and there's no staging environment so all edits go live instantly 
:). If I forget to close a PHP statement or leave off a semicolon the 
entire page breaks (or the entire site if it's one of our include files ...)

I could set up a staging environment now that I've got plenty of disk 
space and have started managing the website with git, but I didn't think 
there was a pressing need (and your above comment confirms that).

-- Chris

Post a reply to this message

Am 07.08.2021 um 11:58 schrieb Ash Holsenback:
> On 8/6/21 1:46 PM, clipka wrote:
>> To cram that content into the Wiki would have required writing import 
>> scripts. And I have 0 - zero, zilch - knowledge about the Wiki import 
>> format, while presumably Jim has just as much knowledge about the 
>> format generated by said tool (beyond the fact that it's HTML, of 
>> course).
> 
> don't even /try/ to involve me. haven't you guys noticed that i've not 
> been replying to the documentation updates / corrections that y'all have 
> been flinging over the wall. i've been trying to step away from the 

> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

Sounds like great fun...
Not.

Don't worry, all I wanted to hint at was that even the two people who 
would know most about the matter are nowhere close to a position of just 
flicking a switch and magically importing those developers' docs into 
the Wiki. And that therefore, given all the other considerations 
besides, it makes no sense whatsoever to invest any time into even trying.

Post a reply to this message

On 7/08/2021 19:58, Ash Holsenback wrote:

> to finish debugging the php / mysql changes to wikidocgen ( after server 
> crash ) so that ought to be a clue as to my motivation.

I can take a look at that if you like. Was going to spend Sunday doing 
server maintenance.

-- Chris

Post a reply to this message

On 8/7/21 9:26 AM, Chris Cason wrote:
> On 7/08/2021 19:58, Ash Holsenback wrote:

>> to finish debugging the php / mysql changes to wikidocgen ( after 
>> server crash ) so that ought to be a clue as to my motivation.
> 
> I can take a look at that if you like. Was going to spend Sunday doing 
> server maintenance.
> 
> -- Chris

appreciate the offer... i'll manage. my only excuse is being lazy.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> ...
> Fossil? The first time I've ever heard of it was when you just brought
> it up.

a bit like music, there's always artists one has never heard of :-).

fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>


regards, jr.

Post a reply to this message

Am 07.08.2021 um 22:50 schrieb jr:

> fwiw: <https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>

Judging by that description, it looks like it would actually have been 
an inferior choice for us.

POV-Ray has a tradition of being forked, for various purposes, and we 
see that as something to be encouraged. Notable examples from the past 
include MegaPOV, MCPov, and that Special Relativity version of POV-Ray 
someone once made. Post-v3.7 examples include UberPOV, Hgpovray(*), 
qtpov and rpov.

I can't speak for the other fork authors, but to me as the author of 
UberPOV, the simplicity with which changes from official POV-Ray could 
be merged in on a semi-regular basis, while at the same time preventing 
UberPOV's own changes to spill back into the official POV-Ray repo, was 
a great help, and an encouraging factor in the decision to even start 
that fork in the first place. And I guess other people's experience is 
similar (*Hgpovray being an exception here, as the author deliberately 
chose to use a versioning system he's more familiar with).


Some additional points where Fossil would be a poor choice:

- "Drive-by contributions" is something we want to encourage, not 
discourage.

- "Trust over hierarchy" is a luxury we can't afford: POV-Ray's internal 
architecture is so convoluted and complex, our goals of what we want 
that architecture to eveolve into so different from the current status, 
and the road there so vaguely visible, that it is unreasonable to expect 
even the best developers to reliably make good design decisions when 
developing fixes, features or whatever. So no matter how much trust we 
place in their integrity and capabilities, it is prudent we don't just 
accept the result of their work based on implicit trust alone.

Post a reply to this message