hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/27/21 2:08 AM, jr wrote:
> > ...
> >> As implemented it's a stand alone bit of code.
> >
> > that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?
>
> Could be. Yes.

nice.


> ...
> > supported by a similar function which returns an 'array mixed' with the various
> > "properties"/categories broken out?
>
> What I've not done for arrays vs mixed arrays as yet is look for a
> method 'like' that employed to break out a few of the object types like
> light sources(1). The object flags popped into my head on Tor Olav's
> question.

I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
and so perhaps a complementary function (eg) 'is_type_details()' which returns
an array mixed, where the various flags are used to distinguish one ("390")
object from another.


> Even without getting different type ids for arrays vs mixed arrays today
> from id_type, you can walk a mixed array asking about the types for each
> element and in that way via SDL looping (or your foreach work) build up
> what types in total are seen for any given the mixed array.

not sure I really understand.  if some macro expects an array mixed parameter,
say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
for instance, whether I use 'strlen(string)' or similar, if it's not a string,
POV-Ray will "intervene".  (did I misread?)

(and the (snipped) macro examples too, while safe to use, would not allow me to
catch (as in handle with own error message) the eventual "odd" value, I think)


regards, jr.

Post a reply to this message

On 5/28/21 3:48 AM, jr wrote:
> hi,
> 
...
>> ...
>>> supported by a similar function which returns an 'array mixed' with the various
>>> "properties"/categories broken out?
>>
>> What I've not done for arrays vs mixed arrays as yet is look for a
>> method 'like' that employed to break out a few of the object types like
>> light sources(1). The object flags popped into my head on Tor Olav's
>> question.
> 
> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> and so perhaps a complementary function (eg) 'is_type_details()' which returns
> an array mixed, where the various flags are used to distinguish one ("390")
> object from another.
> 

Yes, is_type_details(), a possibility, but it would be work creeping 
well past "easy."

Aside: For the details which could be provided as strings of text as to 
type, my thought was this work would be pushed onto users - or some 
include file maintainer - in the form of a macro containing a big switch 
kicking out text or setting up an array with, say, response strings: 
"The is type passed to MagicMacro24 is a light_source."

> 
>> Even without getting different type ids for arrays vs mixed arrays today
>> from id_type, you can walk a mixed array asking about the types for each
>> element and in that way via SDL looping (or your foreach work) build up
>> what types in total are seen for any given the mixed array.
> 
> not sure I really understand.  if some macro expects an array mixed parameter,
> say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
> for instance, whether I use 'strlen(string)' or similar, if it's not a string,
> POV-Ray will "intervene".  (did I misread?)
> 
> (and the (snipped) macro examples too, while safe to use, would not allow me to
> catch (as in handle with own error message) the eventual "odd" value, I think)
> 

You understood. What I coded up there is checking on the cheap; POV-Ray 
does it and the result is an internal parser error. What I had in mind 
for what I think you want to do - using id_type() - is something like 
the attached test case. Yes/No?

Bill P.

Post a reply to this message

Attachments:
Download 'utf-8' (3 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 3:48 AM, jr wrote:
> >> ...
> >> What I've not done for arrays vs mixed arrays as yet is look for a
> >> method 'like' that employed to break out a few of the object types like
> >> light sources(1). The object flags popped into my head on Tor Olav's
> >> question.
> >
> > I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> > and so perhaps a complementary function (eg) 'is_type_details()' which returns
> > an array mixed, where the various flags are used to distinguish one ("390")
> > object from another.
> >
>
> Yes, is_type_details(), a possibility, but it would be work creeping
> well past "easy."
>
> Aside: For the details which could be provided as strings of text as to
> type, my thought was this work would be pushed onto users - or some
> include file maintainer - in the form of a macro containing a big switch
> kicking out text or setting up an array with, say, response strings:
> "The is type passed to MagicMacro24 is a light_source."

I was about to suggest (almost) the opposite.  :-)

thinking that if one (you :-)) were to set up an enum, covering the basics
(float, bool, vector, macro, function, array, string, such[*]), then changing
(in the parser, between versions) ids could be "contained" in one mapping.  then
'is_type()', and later perhaps its companion func, would always provide
consistent "numbers".  and yes, some include file to turn the numbers back into
human speak would be v useful (will collaborate if thought helpful).

[*] off the top of my head.  in most ("95%") situations, I think, just knowing
it's "an array", say, without the "fall out" from using 'dimensions(foo)' when
it isn't, will suffice.


> ...
> > (and the (snipped) macro examples too, while safe to use, would not allow me to
> > catch (as in handle with own error message) the eventual "odd" value, I think)
>
> You understood. What I coded up there is checking on the cheap; POV-Ray
> does it and the result is an internal parser error. What I had in mind
> for what I think you want to do - using id_type() - is something like
> the attached test case. Yes/No?

thanks.  will look at code tonight/tomorrow.


regards, jr.

Post a reply to this message

On 5/28/21 8:23 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/28/21 3:48 AM, jr wrote:
>>>> ...
>>>> What I've not done for arrays vs mixed arrays as yet is look for a
>>>> method 'like' that employed to break out a few of the object types like
>>>> light sources(1). The object flags popped into my head on Tor Olav's
>>>> question.
>>>
>>> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
>>> and so perhaps a complementary function (eg) 'is_type_details()' which returns
>>> an array mixed, where the various flags are used to distinguish one ("390")
>>> object from another.
>>>
>>
>> Yes, is_type_details(), a possibility, but it would be work creeping
>> well past "easy."
>>
>> Aside: For the details which could be provided as strings of text as to
>> type, my thought was this work would be pushed onto users - or some
>> include file maintainer - in the form of a macro containing a big switch
>> kicking out text or setting up an array with, say, response strings:
>> "The is type passed to MagicMacro24 is a light_source."
> 
> I was about to suggest (almost) the opposite.  :-)
> 
> thinking that if one (you :-)) were to set up an enum, covering the basics
> (float, bool, vector, macro, function, array, string, such[*]), then changing
> (in the parser, between versions) ids could be "contained" in one mapping.  then
> 'is_type()', and later perhaps its companion func, would always provide
> consistent "numbers".  and yes, some include file to turn the numbers back into
> human speak would be v useful (will collaborate if thought helpful).
> 

Suppose it could be done by running a script to build such a cross index 
as a check in hook or something.

There is today a basic enum to cross reference in the code that gets 
used when reporting messages and such. We're basically talking about 
some parallel ID enum to locked integer index I guess - which 
is_type_details() or similar could use... I'll think about it, but at 
the moment it all feels a bit clunky /ugly given the minor value to end 
users.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 8:23 AM, jr wrote:
> > ...
> > thinking that if one (you :-)) were to set up an enum, ...
> Suppose it could be done by running a script to build such a cross index
> as a check in hook or something.
>
> There is today a basic enum to cross reference in the code that gets
> used when reporting messages and such. ...

if that implies that the enumeration is sort of stable, perhaps it can be
"pressed into service"?

re the 'is_type()' code -- SDL user me says "Yes".  :-)  fwiw, I like this:

  #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))

"idiom" a lot.

(also made me wonder what was playing on your radio while you wrote that code.
UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."
<https://www.youtube.com/watch?v=KSBIDIZ6ySc> :-))


regards, jr.

Post a reply to this message

On 5/29/21 2:53 AM, jr wrote:
> if that implies that the enumeration is sort of stable, perhaps it can be
> "pressed into service"?

It is in service with is_type(), but is itself not stable as keywords 
and keyword groupings change. Could an 'intended stable' form be created 
/ maintained - sure. Is it worth the trouble - ehhh...

> 
> re the 'is_type()' code -- SDL user me says "Yes".:-)   fwiw, I like this:
> 
>    #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))
> 
> "idiom" a lot.
> 
> (also made me wonder what was playing on your radio while you wrote that code.
> UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."

References to 'radio' will lead the kids reading to think we're ancient. 
The youtube link was perhaps enough to fool em - that we're playing with 
POV-Ray won't help. ;-)

As for what's playing in my head... A storm, always about three beats 
from incoherence. When I listen to music while coding, it's 
meaningful-vocal-less. Thinking, reading, coding in a public place where 
the sounds are a vibration, where only an occasional word or two pops to 
the surface, is best.

Anyhow. Let me know when I've gone over the edge - another one. I'm 
still upright - I think.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> References to 'radio' will lead the kids reading to think we're ancient.

Just call it "wireless".  A term so old, its new again.


> The youtube link was perhaps enough to fool em - that we're playing with
> POV-Ray won't help. ;-)

"More than just a pixel shader...."


> Anyhow. Let me know when I've gone over the edge - another one.

Don't call them "edges" - call them "new frontiers".

Post a reply to this message

On 5/29/21 8:03 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> References to 'radio' will lead the kids reading to think we're ancient.
> 
> Just call it "wireless".  A term so old, its new again.
> 
...

Ah! We just have to apply enough spin... :-)

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/29/21 2:53 AM, jr wrote:
> > if that implies that the enumeration is sort of stable, perhaps it can be
> > "pressed into service"?
>
> It is in service with is_type(), but is itself not stable as keywords
> and keyword groupings change. Could an 'intended stable' form be created
> / maintained - sure. Is it worth the trouble - ehhh...

so.  an include with one macro and version specific data, then?


> ...
> As for what's playing in my head... A storm, always about three beats
> from incoherence. When I listen to music while coding, it's
> meaningful-vocal-less. Thinking, reading, coding in a public place where
> the sounds are a vibration, where only an occasional word or two pops to
> the surface, is best.

:-)  recognise the preference (?) for instrumentals.  (cannot usually relax
enough in a public place to .. let my mind wander)


regards, jr.

Post a reply to this message

On 5/29/21 11:43 AM, jr wrote:
> so.  an include with one macro and version specific data, then?

Yeah, one could have a  macro - include which sets up an array of the 
values as they sit each version of code . Basically a bunch of calls to:

#macro Mcr_id_type(_id) id_type(_id) #end

setting up an array (or dictionary) which you'd then reference in 
compares to id_type() instead of calls to Mcr_id_type().

Bill P.

Post a reply to this message