Hello,

It has been a long time since I have delved into SDL and my slowly rusting
mind could use a refresher on something.

Is it possible to create "objects" like classes or generally any named
container having properties in SDL other than to use an array?

I am not looking for the stack vs heap aspects of classes and structs, only
the POCO/DTO aspects.

Am I stuck hacking it by using strings in an array and string parsing to
mimic this, or does someone have a better way?

I am just looking for a clean way to have a chunk of information that has
properties which may be of multiple types wherein its internal properties
are in he same scope/are united and "owned" by that object, without
emulating this using multiple arrays whose contents are correlated only by
sharing indices...

Ian

Post a reply to this message

Am 16.11.2016 um 01:49 schrieb [GDS|Entropy]:

> It has been a long time since I have delved into SDL and my slowly rusting
> mind could use a refresher on something.
> 
> Is it possible to create "objects" like classes or generally any named
> container having properties in SDL other than to use an array?

You indeed seem to be a bit out of touch with development ;)

As of recently, an official experimental branch exists that supports
more advanced data containers:

https://github.com/POV-Ray/povray/tree/feature/dictionary

https://github.com/POV-Ray/povray/releases/tag/v3.7.1-x.dictionary.8791118

Official experimental branch means that the intent is to add the feature
to official POV-Ray, but the syntax hasn't been finalized yet.

The branch adds a `dictionary` container type, which is essentially a
string-indexed variable-type array. As syntactic sugar, it also supports
dot-identifier notation:

    #declare Foo = dictionary;
    #declare Foo["Go Figure"] = 47;
    #declare Foo.Fnord = sphere { <0,0,0>, 2 };

For giggles, the branch also adds support for a new flavour of
one-dimensional integer-indexed array that can grow dynamically as needed.

Another for-giggles extension allowing to mix data of different types in
one and the same array (both fixed and dynamic size) also already exists
in one of my drawers.


More detailed information on the currently implemented syntax can be
found somewhere on these neswgroups, probably posted mid-september.


The next step would be to introduce some syntax to assign macros to
arbitrary (i.e. non-global) variables, ideally without actually
duplicating the macro; that would effectively turn the dictionary type
into a mechanism for object-oriented programming (using duck-typing).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> You indeed seem to be a bit out of touch with development ;)

Very much so. ;)

> As of recently, an official experimental branch exists that supports
> more advanced data containers:

Sweet! Is this in UberPov in any form yet?

> The branch adds a `dictionary` container type, which is essentially a
> string-indexed variable-type array. As syntactic sugar, it also supports
> dot-identifier notation:
> 
>     #declare Foo = dictionary;
>     #declare Foo["Go Figure"] = 47;
>     #declare Foo.Fnord = sphere { <0,0,0>, 2 };

Oh nice!

> For giggles, the branch also adds support for a new flavour of
> one-dimensional integer-indexed array that can grow dynamically as needed.

Thats cool, does it have Queue type push/pop operation?
Those sorts of structures would be nice to have, just the standard run if
the mill ones at the least.

> Another for-giggles extension allowing to mix data of different types in
> one and the same array (both fixed and dynamic size) also already exists
> in one of my drawers.

That sounds like a tuple array.

> More detailed information on the currently implemented syntax can be
> found somewhere on these neswgroups, probably posted mid-september.

I will look for it.

> The next step would be to introduce some syntax to assign macros to
> arbitrary (i.e. non-global) variables, ideally without actually
> duplicating the macro; that would effectively turn the dictionary type
> into a mechanism for object-oriented programming (using duck-typing).

That also is a great idea.

Being able to define a class or other named container laid out the same way
(properties, constructor and such) would be nice too though but probably a
huge pain, otherwise I would guess it would already exist, which I guess is
why the dictionary is setup the way it is.

Before I read your comment I was seriously considering making an SDL I/O
macro for handling JSON, just so I could make class like structures in a
known language, but that is not needed I guess now unless it would be very
helpful to have.

Ian

Post a reply to this message

Am 16.11.2016 um 06:29 schrieb [GDS|Entropy]:

>> As of recently, an official experimental branch exists that supports
>> more advanced data containers:
> 
> Sweet! Is this in UberPov in any form yet?

Not yet.


>> For giggles, the branch also adds support for a new flavour of
>> one-dimensional integer-indexed array that can grow dynamically as needed.
> 
> Thats cool, does it have Queue type push/pop operation?

Nah, so far it just provides the bare minimum for not having to specify
a maximum size at initialization.


>> The next step would be to introduce some syntax to assign macros to
>> arbitrary (i.e. non-global) variables, ideally without actually
>> duplicating the macro; that would effectively turn the dictionary type
>> into a mechanism for object-oriented programming (using duck-typing).
> 
> That also is a great idea.
> 
> Being able to define a class or other named container laid out the same way
> (properties, constructor and such) would be nice too though but probably a
> huge pain, otherwise I would guess it would already exist, which I guess is
> why the dictionary is setup the way it is.

To be honest, there's something I like about duck-typing -- but yeah,
avoiding the hassle of implementing a type system with inheritance and
all is probably the main reason I'm going that route. A type system can
probably be bolted on later.

> Before I read your comment I was seriously considering making an SDL I/O
> macro for handling JSON, just so I could make class like structures in a
> known language, but that is not needed I guess now unless it would be very
> helpful to have.

As a matter of fact, an inbuilt JSON import feature also already exists
in the same drawer the variable-type arrays reside in (not a
coincidence; my idea is to convert the JSON data directly into a
corresponding hierarchy of SDL containers, but this requires that arrays
can hold variable types), as part of an effort to import DAZ Studio DSON
material definitions.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 
> As a matter of fact, an inbuilt JSON import feature also already exists
> in the same drawer the variable-type arrays reside in (not a
> coincidence; my idea is to convert the JSON data directly into a
> corresponding hierarchy of SDL containers, but this requires that arrays
> can hold variable types), as part of an effort to import DAZ Studio DSON
> material definitions.
> 
 
I am glad I asked then! :D

It would be very cool to be able to import DAZ materials, even though I
have somewhat against them for their neglect of Bryce and Carrara, and
Hexagon frankly. I have all 3 on my dedicated gfx box (the Xeon machine).

One of my favorite web comics is actually made with Carrara and started in
Bryce: Requiem. Great plot, and the author is a software and graphics guy
like most of us.

One bit of irritation I have with arrays is that you cant do this:

#declare myArray = array[foo][bar];

// loop
#local etc = myArray[iterator];

And similar with assignment.

I ended up making a 1d array of 1d arrays. Its just more code to do pretty
much the same thing, and isn't really intuitive to those used to and coming
from other languages.

I think some concessions to the way many of the popular languages work,
like JS, Java and C# would be beneficial, with regard to array behavior.

I also noticed that I cannot do the following:
Short-circuit conditional ops (shocked me)
Unary modification and assignment (+= and so forth)

I had been away from SDL so long these facts took me aback. I assume there
are very good reasons for this, because they are so common if not for such
they would have been implemented already.

It would be very cool if, as part of the refactor toward modularization,
that the SDL were abstracted and facaded from the engine, so that ANY SDL
which meets the required interface specification could then be used, which
would likely simplify inclusion of Pov as a 3rd party rendering option.
Frankly you could leave the internal SDL coding and just facade
that...though that would be less ideal from an architectural standpoint
than a purpose built generic DSL interpreter, but also far less work and so
maybe a good "phase 1" go of it.

I had once tried to hook into Pov so that I could invoke the render and
host the output in a C# app picturebox, but I never figured out how. Moray
does it so it is obviously possible, but I don't know how much of a hack
their method was or if there is some actual API for this.

I would like to do this as part of the rework of my Image2Pov texture
creation app, the one that produces extremely realistic agates, marbles and
such from colors harvested from images.

Ian

Post a reply to this message

Am 17.11.2016 um 00:20 schrieb [GDS|Entropy]:

> One bit of irritation I have with arrays is that you cant do this:
> 
> #declare myArray = array[foo][bar];
> 
> // loop
> #local etc = myArray[iterator];
> 
> And similar with assignment.
> 
> I ended up making a 1d array of 1d arrays. Its just more code to do pretty
> much the same thing, and isn't really intuitive to those used to and coming
> from other languages.
> 
> I think some concessions to the way many of the popular languages work,
> like JS, Java and C# would be beneficial, with regard to array behavior.

I agree; but we have to make concessions between what would be nice to
have, and what we can bolt on to the existing parser architecture. Since
I have no immediate idea how to tackle this one, and there are usually
ways to work around the issue, I don't think it should have high priority.


> I also noticed that I cannot do the following:
> Short-circuit conditional ops (shocked me)

Short-circuit conditional ops (I presume you mean the `?:` ternary
operator) are nice-to-have sugar, but probably difficult to implement,
with the parser being as convoluted as it is; moreover, `#if ... #else
... #end` already provide a workaround if sort-circuit operation is
really necessary.

What bothers me much more is that we don't have a short-circuit `select`
statement, at least in user-defined functions, as that is an actual
factor in render performance of certain isosurfaces. But I prefer not to
touch the current VM, and instead wait for it to be replaced with a new one.

> Unary modification and assignment (+= and so forth)

Purely syntactic sugar. Should be reasonably easy to implement, but
isn't high on my personal agenda.


> It would be very cool if, as part of the refactor toward modularization,
> that the SDL were abstracted and facaded from the engine, so that ANY SDL
> which meets the required interface specification could then be used, which
> would likely simplify inclusion of Pov as a 3rd party rendering option.
> Frankly you could leave the internal SDL coding and just facade
> that...though that would be less ideal from an architectural standpoint
> than a purpose built generic DSL interpreter, but also far less work and so
> maybe a good "phase 1" go of it.

My goal is to introduce a clean conceptual separation between the render
engine and the parser, so that the parser (typically along with the
front-end) could be replaced by something else entirely. Which means
that there's still a lot of stuff to be moved from the parser to the
render engine (most notably object initialization and certain
post-parse/pre-render processing steps).

Bolting another layer on top of the parser? No, thanks.


> I had once tried to hook into Pov so that I could invoke the render and
> host the output in a C# app picturebox, but I never figured out how. Moray
> does it so it is obviously possible, but I don't know how much of a hack
> their method was or if there is some actual API for this.

POV-Ray for Windows does provide a GUI plug-in API, which to my
knowledge is how Moray interfaces to POV-Ray. I have never had a closer
look at the interface though -- my guess is that it is not much more
than a way for the plug-in to initiate a render of a POV or INI file.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I agree; but we have to make concessions between what would be nice to
> have, and what we can bolt on to the existing parser architecture. Since
> I have no immediate idea how to tackle this one, and there are usually
> ways to work around the issue, I don't think it should have high priority.

I agree completely; the stuff I mentioned was just piddly little things
that are of quite low priority. The sorts of things that should go on the
backlog and may never be seen again frankly. ;-)

> 
>> I also noticed that I cannot do the following:
>> Short-circuit conditional ops (shocked me)
> 
> Short-circuit conditional ops (I presume you mean the `?:` ternary
> operator) are nice-to-have sugar, but probably difficult to implement,
> with the parser being as convoluted as it is; moreover, `#if ... #else
> ... #end` already provide a workaround if sort-circuit operation is
> really necessary.

I meant && and ||; apologies for being unclear.


> What bothers me much more is that we don't have a short-circuit `select`
> statement, at least in user-defined functions, as that is an actual
> factor in render performance of certain isosurfaces. But I prefer not to
> touch the current VM, and instead wait for it to be replaced with a new one.

Sort of like C# yield return? 

>> Unary modification and assignment (+= and so forth)
> 
> Purely syntactic sugar. Should be reasonably easy to implement, but
> isn't high on my personal agenda.

I agree, i was kist surprised by its absence. :)

> 
> My goal is to introduce a clean conceptual separation between the render
> engine and the parser, so that the parser (typically along with the
> front-end) could be replaced by something else entirely. Which means
> that there's still a lot of stuff to be moved from the parser to the
> render engine (most notably object initialization and certain
> post-parse/pre-render processing steps).
> 
> Bolting another layer on top of the parser? No, thanks.

I wasn't aware of that the engine and parser were so tightly coupled, but
had an inkling that might have been the case based on some of the items you
mentioned that needed to be done. I am starting to get the picture of why
the refactoring is so high priority.

>
> POV-Ray for Windows does provide a GUI plug-in API, which to my
> knowledge is how Moray interfaces to POV-Ray. I have never had a closer
> look at the interface though -- my guess is that it is not much more
> than a way for the plug-in to initiate a render of a POV or INI file.
> 
> 

I wonder what they were doing to get the render to occur in their own
hosted form window? That is the crux of it.

I am afraid that I will discover that they scanned the memory, located the
pov process and hooked into the live output of the renderer directly, then
just copied the memory contents and shoved it into a picture box. *shivers*

Ian

Post a reply to this message

Am 17.11.2016 um 02:51 schrieb [GDS|Entropy]:

>> POV-Ray for Windows does provide a GUI plug-in API, which to my
>> knowledge is how Moray interfaces to POV-Ray. I have never had a closer
>> look at the interface though -- my guess is that it is not much more
>> than a way for the plug-in to initiate a render of a POV or INI file.
>>
>>
> 
> I wonder what they were doing to get the render to occur in their own
> hosted form window? That is the crux of it.
> 
> I am afraid that I will discover that they scanned the memory, located the
> pov process and hooked into the live output of the renderer directly, then
> just copied the memory contents and shoved it into a picture box. *shivers*

It's not that bad. Judging from a quick glance, it's a neat event
dispatch interface using a bunch of C function pointers, including some
apparently intended to report the rendered pixel data (see `pvguiext.h`).

Post a reply to this message