"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

Bruno Cabasson <bru### [at] yahoofr> wrote:

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

I don't think it can tell in a non-error triggering way.

Looking at your code,

#macro extend(arr, extension_arr)
    // We cannot know whether an array is "array" or "array mixed".
    // So we let the aprser generate an error if elements are of incompatible
types.
    #local start = dimension_size(arr, 1);
    #for (i, 0, dimension_size(extension_arr, 1) - 1)
        #local arr[start + i] = extension_arr[i];
    #end
#end

I think all you have to do is determine the size of both arrays, create a
temporary array of either dynamic size, or big enough to hold all the elements
of both, fill that array, and then declare the original array identifier name to
now be the new temporary array.

That would also let you get around the mixed array error, by making temporary
array a mixed type.

Post a reply to this message

Le 21/03/2022 à 20:22, Bald Eagle a écrit :
> Bruno Cabasson <bru### [at] yahoofr> wrote:
> 
>>   > 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.
> 
> I don't think it can tell in a non-error triggering way.
> 
> Looking at your code,
> 
> #macro extend(arr, extension_arr)
>      // We cannot know whether an array is "array" or "array mixed".
>      // So we let the parser generate an error if elements are of incompatible
> types.
>      #local start = dimension_size(arr, 1);
>      #for (i, 0, dimension_size(extension_arr, 1) - 1)
>          #local arr[start + i] = extension_arr[i];
>      #end
> #end
> 
> I think all you have to do is determine the size of both arrays, create a
> temporary array of either dynamic size, or big enough to hold all the elements
> of both, fill that array, and then declare the original array identifier name to
> now be the new temporary array.

==> this could change the nature of the target array. What would be the 
type of the resulting array (fixed/variable size, array/array_mixed)? 
The code should choose one possibility among 4, for example variable 
size array mixed. I think the code above is quite generic for both 
parameters, except for "arr" which must only be of variable size. That 
is one (small) of the restrictions for using PROOF. The parser does the 
appropriate checks during assignment.

However, my purpose during this VERY early stage of exploring a Proof Of 
Concept, and implementing a feasibility-showing Sdl code, is to 
determine if 3.8b2 features allow to define and implement basic 
Object-Oriented features, such as classes, properties, methods, 
inheritance, without too much dammage concerning syntax and usage ... If 
it is the case - and I think it is, see my future post with oocore.inc 
and its test code in the next hours - it would mean that we can benefit 
from the Object-Oriented'ness, even if it is with some restrictions. But 
it is just an exploration.

"primitives.inc" ans "collections.inc" are just helpers for now. They 
are NOT what is to foscus on now. Despite their quite secondary nature, 
I wrote test code to ensure minimal behaviour.

> 
> That would also let you get around the mixed array error, by making temporary
> array a mixed type.
> 

Hi,

Thanks for the suggestion.

While writing the code, I was facing two possibilities :

1) extend(my_arr, extension_arr),
	restriction :  my_arr is not declared of fixed size (PROOF standard ?)

or

2) #declare my_extended_arr = extend(my_arr, extension_arr)
	restriction : my_extended_arr is of a chosen type
	(variable/fixed size, array/array mixed), unless we use
	a 3rd parameter.


I decided arbitrarilly to write the first one : in-place extension, 
pretty much like Python's my_list.extend(extension_list), and assume the 
"small" restriction that arrays in PROOF are not declared fixed size. I 
am looking for functional OO features, not performance nor memory 
efficiency.

In the second case, perhaps a primitive named something like 
"catenate()" could to the thing. I can write it later.

I was also thinking of someting like python's "zip()"... But for now, I 
concentrate on OO aspects and feasibility.

Cheers


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

Hi,

Here is an updated package, including "oocore.inc". The test file 
"oocore_ut.pov" provides examples on how classes can be defined and how 
main OO features can work in the "testing whole classes" section.

Again, for the time being, this is only a study, and requires v3.8beta2.

Soon, and if this approach is accepted by people here, I will go further 
with POV objects encapsulation within PROOF. As I already said, such an 
encapsulation, in itself, does not bring much compared to native syntax. 
Except we now can deal with objects and classes we can derive and attach 
behaviour to.

To my eyes, POV-Sdl is not really a *programming* language. It is a 
Scene Description Language, which is quite different and very 
specialized. Since we have Object Orientedness, perhaps we could be in 
position to make it a *real* programming language. Even if not 
full-featured, even with limitations, even with syntactic and functional 
sacrifices.

Of course, if it finally appears that nobody is interested, I will stop 
the study and drop PROOF. Will not bother me much.

B.

-- 


https://www.avast.com/antivirus

Post a reply to this message

Attachments:
Download 'collections.inc.txt' (11 KB) Download 'collections_ut.pov.txt' (11 KB) Download 'oocore.inc.txt' (17 KB) Download 'oocore_ut.pov.txt' (23 KB) Download 'primitive_ut.pov.txt' (17 KB) Download 'primitives.inc.txt' (10 KB)

Le 22/03/2022 à 13:29, Bruno Cabasson a écrit :
> Hi,
> 
> Here is an updated package, including "oocore.inc". The test file 
> "oocore_ut.pov" provides examples on how classes can be defined and how 
> main OO features can work in the "testing whole classes" section.
> 
> Again, for the time being, this is only a study, and requires v3.8beta2.
> 
> Soon, and if this approach is accepted by people here, I will go further 
> with POV objects encapsulation within PROOF. As I already said, such an 
> encapsulation, in itself, does not bring much compared to native syntax. 
> Except we now can deal with objects and classes we can derive and attach 
> behaviour to.
> 
> To my eyes, POV-Sdl is not really a *programming* language. It is a 
> Scene Description Language, which is quite different and very 
> specialized. Since we have Object Orientedness, perhaps we could be in 
> position to make it a *real* programming language. Even if not 
> full-featured, even with limitations, even with syntactic and functional 
> sacrifices.
> 
> Of course, if it finally appears that nobody is interested, I will stop 
> the study and drop PROOF. Will not bother me much.
> 
> B.
> 

Hi.

Please find a WIP for the "objects.inc" file, with a basic test file 
(not intended for unit-testing) and a result image.

You can see the class hierachy I designed so far :

   +- ObjectItem
   |  |    - no properties -
   |  |    commit() // generates Sdl items
   |  |
   |  +- ObjectPhotons
   |  |      target_
   |  |      refraction_
   |  |      reflection_
   |  |      collect_
   |  |      pass_through_
   |  |      - no additional methods -
   |  |
   |  +- ObjectRadiosity
   |  |      importance_
   |  |      - no additional methods -
   |  |
   |  +- ObjectModifiers
   |  |      texture_
   |  |      _has_interior_texture
   |  |      interior_texture_
   |  |      _has_interior
   |  |      interior_
   |  |      _has_pigment
   |  |      pigment_
   |  |      _has_normal
   |  |      normal_
   |  |      _has_finish
   |  |      finish_
   |  |      _has_transform
   |  |      transform_
   |  |      object_photons
   |  |      _has_object_radiosity
   |  |      object_radiosity
   |  |      _has_bounded_by
   |  |      bounded_by_
   |  |      _has_clipped_by
   |  |      clipped_by_
   |  |      double_illuminate_
   |  |      hollow_
   |  |      no_shadow_
   |  |      no_image_
   |  |      no_reflection_
   |  |      no_radiosity_
   |  |      - no additional methods -
   |
   +- Object
      |   modifiers
      |   _spawned
      |   _instance
      |   spawn() // Actually creates the Sdl object
      |              (using ObjectItem's commmit() method)
      |
      +- Sphere
      |      center
      |      radius_
      |      - no additional methods -
      |
      +- Box
      |      ur
      |      ll
      |      - no additional methods -
      |
      +- Cylinder
      |      base
      |      cap
      |      radius_
      |      open_
      |     - no additional methods -
      |
      +- Torus
      |      major
      |      minor
      |      spindle_type
      |      sturm_
      |      - no additional methods -
      |
      .../... and so forth in the future for other POV objects.


I just implemented basic shapes to see what happens : sphere, box, 
cylinder and torus.

Objects classes can define 2 methods, invoked by describe() and dump() 
convenience macros:
  -) describe() ==> MyClass_describe() macro
       outputs a description of the class in the #debug channel
  -) dump() ==> MyClass_dump() macro
       outputs a dump of the contents of an instancein the #debug channel

The "object_test.pov" test file shows how these classes can be used and 
the "object_test.png" image is the result of the Run.

Using classes for such a scene is not really interresting. But we are 
now in the Object Oriented world. I will not explain the advantages of 
OO ....

RECALL : It is just the VERY beginning of a POC.

I hope I can illustrate soon how OO can help in our scenes (or 
animations). If any of you has ideas or inspiration, you are welcome to 
contribute.


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 'objects.inc.txt' (30 KB) Download 'objects_test.png' (112 KB) Download 'objects_test.pov.txt' (7 KB)

Preview of image 'objects_test.png'

hi,

Bruno Cabasson <bru### [at] yahoofr> wrote:
> ...
> > Here is an updated package, ...
> You can see the class hierachy I designed so far :
> ...

thanks.  hope for a "look around" over the weekend.


regards, jr.

Post a reply to this message