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