Hi,

Here is a zip containing PROOF's core include files and a basic test code file.

Contents:
primitives.inc : basic definitions (some could be part of POV-Sdl native syntax)
oocore.inc : object oriented core features, definitions, macros, etc ...
oocore_test.inc : test code for oocore.inc. The result is text in #debug
channel.
oocore_test.pov : scene file for oocore_test.inc. The appearance of the
                  ready made basic scene means all went OK.

                  ==> Run the "oocore_test.pov" file and see the #debug channel
(Messages tab) for the results.

Remember, it is just an WIP for an early POC.

I consider that the main OO features are available and oocore.inc makes the job.
Therefore, I had a go for objects in scene and designed classes in order to
describe spheres, boxes, cylinder, toruses, and (in the future) all POV's
objects by PROOF's classes, including voluminous objects (mesh, mesh2, blob,
complex CSG's...) for which we will be in position to control the behaviour.

REMARKS:

Rem1: splines can be described by classes and be easily controlled because
instances keep track of internal data (spline defining points in this case). We
can extend, catenate, normalize, .... in a clean and easy manner. Splines are in
my TODO list.


Rem2 : Trees are complex structures that can be embeded in classes.

Rem3 : Animation could be eased with an object-oriented approach

Rem4 : I think that if I could write Sdl code for OO, then the parser can do it
natively with the appropriate evolutions.

Regards

Bruno

Post a reply to this message

Attachments:
Download 'proof_core_wip1.zip' (9 KB)

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> Here is a zip containing PROOF's core include files and a basic test code file.

quick.  :-)  thanks, will find some time to look at week's end.

> ...
> Rem2 : Trees are complex structures that can be embeded in classes.

fwiw, here's a (quad)tree in SDL:

<https://news.povray.org/povray.binaries.images/message/%3Cweb.5eeb464b936ed80b4d00143e0%40news.povray.org%3E/#%3Cweb.5
eeb464b936ed80b4d00143e0%40news.povray.org%3E>


regards, jr.

Post a reply to this message

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> Here is a zip containing PROOF's core include files and a basic test code file.
>
> Contents:
> ...

oops..  ;-)

Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
  ...
==== [Parsing...] ==========================================================
File 'oocore.inc' line 35: Possible Parse Error: Cannot find file
 'collections.inc', even after trying to append file type extension.
File 'oocore.inc' line 35: Parse Error: Cannot open include file
 collections.inc.
Fatal error in parser: Cannot parse input.
Render failed


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > Here is a zip containing PROOF's core include files and a basic test code file.
> >
> > Contents:
> > ...
>
> oops..  ;-)
>
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.9945627.unofficial
>   ...
> ==== [Parsing...] ==========================================================
> File 'oocore.inc' line 35: Possible Parse Error: Cannot find file
>  'collections.inc', even after trying to append file type extension.
> File 'oocore.inc' line 35: Parse Error: Cannot open include file
>  collections.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> regards, jr.

Yes, ooops :)

So sorry. However, "collections.inc" is not required for "oocore.inc" and
"oocore_test.inc" ... You can comment the #include statements.

B.

Post a reply to this message

hi,

"Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> ... You can comment the #include statements.

thanks, that did it.  will defer comment(s) until I've seen a more functional
example, other than to say that re yr comment about finding a way to test
whether the argument is a function (for 'primitives.inc:check'), have a look at
WFP's 'povr' and the 'setidtypes.inc' mechanism.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> > ... You can comment the #include statements.
>
> thanks, that did it.  will defer comment(s) until I've seen a more functional
> example, other than to say that re yr comment about finding a way to test
> whether the argument is a function (for 'primitives.inc:check'), have a look at
> WFP's 'povr' and the 'setidtypes.inc' mechanism.
>
>
> regards, jr.

Thanks!! Will post new version of "primitives.inc" and "collections.inc" with
unit
testing code. Then, I will do some unit testing with "oocore.inc". And then, I
will expose my "objects.inc", the one that deals with scene objects,their core
class hierachy and fundamental mechanisms.

Bruno

Post a reply to this message

Le 07/03/2022 à 19:26, Bruno Cabasson a écrit :
> "jr" <cre### [at] gmailcom> wrote:
>> hi,
>>
>> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
>>> ... You can comment the #include statements.
>>
>> thanks, that did it.  will defer comment(s) until I've seen a more functional
>> example, other than to say that re yr comment about finding a way to test
>> whether the argument is a function (for 'primitives.inc:check'), have a look at
>> WFP's 'povr' and the 'setidtypes.inc' mechanism.
>>
>>
>> regards, jr.
> 
> Thanks!! Will post new version of "primitives.inc" and "collections.inc" with
> unit
> testing code. Then, I will do some unit testing with "oocore.inc". And then, I
> will expose my "objects.inc", the one that deals with scene objects,their core
> class hierachy and fundamental mechanisms.
> 
> Bruno
> 
> 
Hi folks!

Please find hereafter new versions of "primitives.inc" and 
"collections.in" with unit-testing code.

Working on unit-testing "oocore.inc", the core Object Oriented features. 
Then will come "objects.inc" and its unit-testing file(s).

Regards

     Bruno

-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

Post a reply to this message

Attachments:
Download 'collections_ut.pov.txt' (11 KB) Download 'primitive_ut.pov.txt' (16 KB) Download 'primitives.inc.txt' (10 KB) Download 'collections.inc.txt' (11 KB)

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> ...
> Please find hereafter new versions of "primitives.inc" and
> "collections.in" with unit-testing code.

great, something for the weekend :-).


regards, jr.

Post a reply to this message

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> Hi folks!
>
> Please find hereafter new versions of "primitives.inc" and
> "collections.in" with unit-testing code.
>
> Working on unit-testing "oocore.inc", the core Object Oriented features.
> Then will come "objects.inc" and its unit-testing file(s).

have had a look around, some nice ideas there, genuinely looking forward to
seeing where, application-wise, your efforts will lead.  while the following
will probably read like "critique", it's not really, just highlighting
(potential) issues, and yes, adding a "gripe" or two :-).

names.  collections.inc:234:"// Could not use 'slice' as it is a SDL keyword".
so why not 'Slice' (not that I'm advocating uppercase use :-)) or '_slice'?  the
problem, imo, is not the keyword per se, but your use of names like 'get()' for
"globally visible"s, ie no "namespacing".  the "obvious" choice would be 'oo'
followed by underscore or camelcase.  (macro names used unadorned include:
check, exec, exists, extend, get, in, list, map, next.  sure, not keywords, but
common perhaps?)

if I understand the code correctly, in 'primitives.inc' you use the 'rgb'
keyword to coerce values to 3-vector format?  would '<1,1,1>*value' not do the
same, "cleaner"?

extend() - not sure how far you will be able to .. bend SDL :-), but think that
an important macro like extend should be "general".  clipka's advice wrt arrays
was (paraphrasing) "if you know the #elements in advance, declare the array
sized"; however, if I were to:
  #declare A = array [2] {"a","b"};
  #declare B = array [2] {"c","d"};
  extend(A,B)
I'd get: "Parse Error: Array subscript out of range".

gripe(s): why does yr editor not always place whitespace between keyword and
brace?  personally also not a friend of long lines, particularly when concluded
by C++ style comment(s).  including another include (colours) for just white +
yellow?  (also makes the versioning more "dependent")  tja, and then there's the
unit test output.. :-)  without any documentation for yr project, the results of
unit testing can only be of interest if the output _tells_ what one is looking
at, and states (consistently) 'fail' or 'pass', or such.  (time _is_ precious)

anyway, as I said, curious + interested to see how it will all develop.


regards, jr.

Post a reply to this message

Le 14/03/2022 à 17:34, jr a écrit :
 > hi,
 >
 > Bruno Cabasson <bru### [at] yahoofr> wrote:
 >> Hi folks!
 >>
 >> Please find hereafter new versions of "primitives.inc" and
 >> "collections.in" with unit-testing code.
 >>
 >> Working on unit-testing "oocore.inc", the core Object Oriented features.
 >> Then will come "objects.inc" and its unit-testing file(s).
 >
 > have had a look around, some nice ideas there, genuinely looking 
forward to
 > seeing where, application-wise, your efforts will lead.  while the 
following
 > will probably read like "critique", it's not really, just highlighting
 > (potential) issues, and yes, adding a "gripe" or two .
 >
 > names.  collections.inc:234:"// Could not use 'slice' as it is a SDL 
keyword".
 > so why not 'Slice' (not that I'm advocating uppercase use :-)) or 
'_slice'?  the
 > problem, imo, is not the keyword per se, but your use of names like 
'get()' for
 > "globally visible"s, ie no "namespacing".  the "obvious" choice would 
be 'oo'
 > followed by underscore or camelcase.  (macro names used unadorned 
include:
 > check, exec, exists, extend, get, in, list, map, next.  sure, not 
keywords, but
 > common perhaps?)

===> I see these macro names as if they were part of the native 
language. Thus, I try to avoid CamelCasing or use underscores as prefix 
of suffix.

 >
 > if I understand the code correctly, in 'primitives.inc' you use the 'rgb'
 > keyword to coerce values to 3-vector format?  would '<1,1,1>*value' 
not do the
 > same, "cleaner"?
 >
 > extend() - not sure how far you will be able to .. bend SDL , but 
think that
 > an important macro like extend should be "general".  clipka's advice 
wrt arrays
 > was (paraphrasing) "if you know the #elements in advance, declare the 
array
 > sized"; however, if I were to:
 >    #declare A = array [2] {"a","b"};
 >    #declare B = array [2] {"c","d"};
 >    extend(A,B)
 > I'd get: "Parse Error: Array subscript out of range".
 >

===> You are correct. The use of some PROOF features may (and will) 
imply some restrictions. But that's highly secondary for me. In this 
particular case, I don't know if Sdl can detect if the array is of fixed 
sized. Please, enlighten me.


 > gripe(s): why does yr editor not always place whitespace between 
keyword and
 > brace?

===> Please, precise your mind.

personally also not a friend of long lines, particularly when concluded
 > by C++ style comment(s).

===> I agree that some lines are a bit long. Beautifying detail for now.

  including another include (colours) for just white +
 > yellow?  (also makes the versioning more "dependent")  tja,

===> Why not? Including a *small* file is not a problem. Did you never 
#include'ed & C/C++ file or import'ing a python module for just one 
symbol? Performance is not in my scope yet, and not significant for such 
a small file as colors.inc. Besides, #version'ing has ALWAYS been an 
issue and been part of our coding process.

    and then there's the
 > unit test output..   without any documentation for yr project, the 
results of
 > unit testing can only be of interest if the output _tells_ what one 
is looking
 > at, and states (consistently) 'fail' or 'pass', or such.  (time _is_ 
precious)
 >

===> PROOF is in an early state of POC, nothing more at the moment. Sdl 
does not ship with an UT engine, as other languages do (eg pyUnit for 
Python). So I do what Sdl currently allows me to do quite easily. My 
tests are abolutely not ment to be exhaustive. However, they are a 
minimum guarantee for myself and the code to be used for the next steps 
of the POC, even though they just output text. The output shows the 
functionning of my macros. It is no time for developping a UT engine 
prior to PROOF, in particular in this phase. Any contributor is 
welcome... It is also no time for documenting. Way too early. PROOF 
could be a conceptual flop... I try to comment (almost) everything so 
that the reader makes a global idea of things I write. I think I added 
quite a lot of explanations for where I am now.


 > anyway, as I said, curious + interested to see how it will all develop.
 >
 >
 > regards, jr.
 >

Hi. Sorry for the delay. I was on vacation last week without great 
possibility for POVing.

Your remarks are welcome and I'll take them into account in a next 
version. I also look forward for other people to comment and suggest.


New package including oocore.inc with (pseudo?)unit-tesing coming soon.


Regards

     Bruno



-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le 
logiciel antivirus Avast.
https://www.avast.com/antivirus



-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

Post a reply to this message