Am 02.06.2021 um 03:50 schrieb Tor Olav Kristensen:

> Have you considered using Travis to do automatic testing of povr after each
> commit to Github ?
> 
> https://docs.travis-ci.com/user/languages/c/#ci-environment-for-c-projects
> 
> Travis is, AFAIK, free to use for open source projects.

It is. I'm not sure I'd recommend it though.

Yes, it is a German company so that's a pro ;). But there are other 
alternatives:

- If you want something braindead simple, go to Semaphore.

- If you want something very flexible, two days ago I would have 
recommended AppVeyor, because it is a good deal more powerful (or was, 
last time I checked) than Travis CI, and also supports Windows builds. 
Well, I just double-checked and found that Travis CI does that, too, by 
now. Still, I think AppVeyor has a slightly larger portfolio of OS versions.


   *** BUT ***

If you're hosting on GitHub, I'd strongly recommend instead looking to 
GitHub Workflows, aka GitHub Actions. It just so happens that I 
discovered and toyed with it just yesterday.

Pros:

- Pretty much identical choice of platforms as the others.

- Easy to set up if you're after something simple, thanks to various 
pre-made templates.

- Crazy amount of flexibility if you so desire, regardin the "build 
matrix", i.e. which combination of platforms, compilers, build scripts 
and whatnot you're using, which combinations NOT to use, on what 
branches and under what circumstances to use them, which steps to skip 
under which conditions, which jobs have to complete before starting 
others, and other such bells & whistles - all while still being 
reasonably sane to wrap your brain around.

- Crazy amount of flexibility what steps your job is comprised of (no 
hard-wired "pre-buld / build / post-build / deploy" sequence).

- Avoids signing up yet another account on yet another service.

   *** AND ***

in my opinion the most important advantage of all:

- While you're at it, you can use the exact same mechanism to set up 
build tests (or other jobs) that you can trigger MANUALLY.

For example, you can set up just a simple automated test to run on each 
check-in, and run exhaustive platform compatibility tests only on demand.

(Or, you can set up automated actions in some branches, but keep the 
opportunity to manually trigger them on others.)


Caveat:

- For organizations, the free plan includes only 2000 min/month of time 
to run stuff. (AFAIU, there is no such limit for repos owned by 
individual users, at least for private repos.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 02.06.2021 um 03:50 schrieb Tor Olav Kristensen:
>
> > Have you considered using Travis to do automatic testing of povr after each
> > commit to Github ?
> >
> > https://docs.travis-ci.com/user/languages/c/#ci-environment-for-c-projects
> >
> > Travis is, AFAIK, free to use for open source projects.
>
> It is. I'm not sure I'd recommend it though.
>
> Yes, it is a German company so that's a pro ;). But there are other
> alternatives:
>...

Thank you for reviewing the options.

My needs were quite modest compared to what may be needed for POV-Ray.
But it was very interesting to look into such tools and try one of them.

I'm sure that we can implement some smart automated testing with one of the
alternatives that you mentioned.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Am 02.06.2021 um 08:12 schrieb clipka:
> If you're hosting on GitHub, I'd strongly recommend instead looking to 
> GitHub Workflows, aka GitHub Actions. It just so happens that I 
> discovered and toyed with it just yesterday.
...
> Caveat:
> 
> - For organizations, the free plan includes only 2000 min/month of time 
> to run stuff. (AFAIU, there is no such limit for repos owned by 
> individual users, at least for private repos.)

Correction:

There is a limit of 2000 min/month for private repos, no matter whether 
you are an org or individual user.

There is no such limit for public repos, you can run as much stuff as 
you like.

Post a reply to this message

On 5/30/21 6:58 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An updated tarball of my povr branch. A little rushed, but want to post
>> a new one ahead of being busy with real life for a bit.
>> ...
>> version is small (5-6MB). The compiled in place ones sits at about 50MB
>> post build - mostly due all the object files.
> 
> compiles/builds cleanly, installed size (including source tree) ~14M.  thank
> you.  (need to find out about 'rtr'!.  v impressive)
> 

Thanks for giving it go!

Yep, rtr is cool and I hope use it (or similar) for more than demos - 
eventually.

Aside: Credit for the real time ray tracing feature goes back mostly to 
Chris and Thorsten - as far as I know. My work amounts to getting it to 
work with unix/linux builds - with Jerome providing helpful background 
information.

The test scene set up is mine and it explores another way to parse a 
multi frame animations once. Just need to work out how to capture each 
rendered frame to an image file...

Aside: There is too that crazy-neat, more or less works already, idea of 
Kenneth's for using rtr to build up better radiosity samples files. Need 
to get back to playing with that and the related ideas of otherwise 
implemented/faked radiosity file creation...

Bill P.

Post a reply to this message

On 6/1/21 9:50 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An updated tarball of my povr branch. A little rushed, but want to post
>> a new one ahead of being busy with real life for a bit.
>> ...
> 
> Thank you.
> 
> Have you considered using Travis to do automatic testing of povr after each
> commit to Github ?
> 
...

Tor Olav & Christoph, I'm aware of those offerings, if not precisely how 
to use them. There is a place for such release build testing I'd say, 
though I'm not sure what form(s) it'll all take for me in the future.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Yep, rtr is cool and I hope use it (or similar) for more than demos -
> eventually.
> ...
> Just need to work out how to capture each rendered frame to an image file...

may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
though.


regards, jr.

Post a reply to this message

On 6/9/21 11:46 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Yep, rtr is cool and I hope use it (or similar) for more than demos -
>> eventually.
>> ...
>> Just need to work out how to capture each rendered frame to an image file...
> 
> may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
> though.
> 

Yeah, maybe. A long while back now, I did play a little with xwd - stand 
alone just snapping a paused preview window. Hit some issue that looked 
to be related to quantization or a shift of color values. I could not 
quickly sort it and I dropped the work - work that's been on the floor a 
long while now. In truth it's 'play' down my list at the moment - 
though(1) ;-).

I 'believe' in rtr much of the work needed to create an output image is 
still done for each frame, perhaps I just need to figure out how to 
pause and trigger a write to unique output files. Oh, and some way to 
run through all the cameras only once I guess.

Bill P.

(1) - Banging around my head of late is the idea that with functions we 
can perhaps create a collection of inbuilts that query generic 
environmental information and return a 'change-this' result(1a) which 
could be used during the render of each frame. With >= v3.8 we have 
stuff like user_defined cameras, pigments and densities(media)... We 
have longer had stuff like isosurfaces, parametrics. Supposing such a 
collection of inbuilt functions, might we be able to change quite a lot 
more stuff frame to frame in rtr? Arbitrarily fly about a scene with a 
couple user defined camera definitions which are no longer static?

(1a) - Expect too might need f_delay, f_pause_resume like inbuilt 
functions rather than just functions that might query the state of 
values in some file say. Guess f_delay might be useful all by itself.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/9/21 11:46 AM, jr wrote:
> > ...
> > may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
> > though.
>
> Yeah, maybe. A long while back now, I did play a little with xwd - stand
> alone just snapping a paused preview window. Hit some issue that looked
> to be related to quantization or a shift of color values. I could not
> quickly sort it and I dropped the work - work that's been on the floor a
> long while now. In truth it's 'play' down my list at the moment -
> though(1) ;-).
>
> I 'believe' in rtr much of the work needed to create an output image is
> still done for each frame, perhaps I just need to figure out how to
> pause and trigger a write to unique output files. ...

had a look at the xwd-1.0.6 source and modified (quick hack) the main function
to create N files from the given window.  no syncing though, adding another
option to specify a delay after each file might help a little.  patch attached
just in case, but anyway, it would be a "crutch" at best.

tested a couple of times with small number frames, running a 'povr' with the
command-line given in 'rtr_kla.pov'.  then the modified 'xwd' ('-nfrm' + '-out'
required):

  $ ./xwd -nfrm 10 -out /tmp/foo -name "POV-Ray (povr) 3.8 povr X11 "

creates '/tmp/foo_00.xwd' etc.  I used 'xv' for visual check:

  $ xv /tmp/foo*.xwd

(curiously, could only identify 'povr' window name + class, but no id shown)


regards, jr.

Post a reply to this message

Attachments:
Download 'wfp_xwd1.txt' (4 KB)

On 6/12/21 7:12 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 6/9/21 11:46 AM, jr wrote:
>>> ...
...
> 
> had a look at the xwd-1.0.6 source and modified (quick hack) the main function
> to create N files from the given window.  no syncing though, adding another
> option to specify a delay after each file might help a little.  patch attached
> just in case, but anyway, it would be a "crutch" at best.
> 
> tested a couple of times with small number frames, running a 'povr' with the
> command-line given in 'rtr_kla.pov'.  then the modified 'xwd' ('-nfrm' + '-out'
> required):
> 
>    $ ./xwd -nfrm 10 -out /tmp/foo -name "POV-Ray (povr) 3.8 povr X11 "
> 
> creates '/tmp/foo_00.xwd' etc.  I used 'xv' for visual check:
> 
>    $ xv /tmp/foo*.xwd
> 
> (curiously, could only identify 'povr' window name + class, but no id shown)
> 
...

Interesting. Thanks. I've captured your patch and this post to a sub 
directory of my jr_causing_trouble directory... :-)

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Interesting. Thanks. I've captured your patch and this post to a sub
> directory of my jr_causing_trouble directory... :-)

</grin>  perhaps amend directory name to and_posting_buggy_code!  found one (the
first?), the "if .. else if' in 'mkFname' need ">=" operators (or literals + 1,
or 'last - 1').


regards, jr.

Post a reply to this message