On 4/14/21 1:44 PM, ingo wrote:
> in news:6076e733$1@news.povray.org William F Pokorny wrote:
> 
>>> //-----------
>>> #version 3.8;
>>>
>>> #macro SomeThing(A)
>>>     #local RD = dictionary;
>>>     RD
>>> #end
>>>    
>>> #declare SD = SomeThing(1);
>>> //-----------
>>>
>>
>> I'm confused as to what you are trying to do. Not myself used
>> dictionaries much as yet, but it looks to me like you are after:
> 
> The goal is to build a datastructure with the macro to pass around. After
> eliminating everything in the body of the macro this is what's left.

Perhaps it would be simpler for the macro body to just be:

#macro...
dictionary {
...
}
#end

I do not see the reason for the local variable RD, though it 'should' 
always work - or always fail, if illegal to do.

> 
> Haven't tried other versions of POV-Ray yet. Fiddling with something else.
> Will try soon as my old brain starts to remember discussing this with
> clipka before, .. I think.
> 

Might not be worth your time. I think the land mine is sitting there 
with dictionaries no matter the version.

We can debug with simpler SDL. Further, if v3.8 master is compiled with 
POV_DEBUG set and the RD dictionary is set up with a few defaults, v3.8 
based version reliably trips a hard, debug, parser panic assertion.

This means there are at least a couple things wrong when doing 
assignments like #declare SD = RD; with dictionaries.

The original povr segfault (when I hit it) is during a pointer 
assignment during the parser clean up. The panic test which fails is 
couple lines below it, doing a reference>0 check. (Moving the test prior 
to the assignment doesn't roll up the segfault)

// ./configure COMPILED_BY="wfp" CXXFLAGS="-DPOV_DEBUG"
//-----------
#version 3.8;

// #local RD = dictionary;

    #local RD = dictionary {
        .foo: "this is nice.",
        .bar: 12345
    }

    #declare SD = RD;

    #error "Stop after parsing"
//-----------

Aside 1: the array code has special empty array handling, which doesn't 
exist for dictionaries. Perhaps it should...?

Near term. If using dictionaries, I'd recommend configuring and 
compiling with POV_DEBUG defined no matter the version - some protection 
in that.

Aside 2: The segfault and POV_DEBUG assertion is during parser clean up. 
However, I don't understand the related code well enough to know whether 
or not there might be situations where dictionaries might be 'running' 
OK, but not always behaving as they should. Users beware.

Unsure how long it might take me to unravel the dictionary parsing code 
well enough to understand the problems - let alone fix them...

Bill P.

Post a reply to this message

ingo <ing### [at] tagpovrayorg> wrote:
> Not sure whether this was reported before.
>
> ...
>
> This crashes POV-Ray. Sometimes it asks to write a dump file.
>
> ...
>
> This results in: test.pov" line 5: Parse Error: Expected 'numeric
> expression', dictionary identifier found instead
>
> Should have added:
> This is version 3.8.0-x.10064738+av694.msvc14.win64.
> Win10.

Confirmed in both cases (running the same version in Win10).

William P's 'clean' code runs smoothly...
#macro SomeThing()
   dictionary
#end
#declare SD = SomeThing();

For what it's worth, this also runs OK...
#macro SomeThing(A)
   dictionary
#end
#declare SD = SomeThing(1);

Post a reply to this message

in news:web.60793806d2107a6cd98418916e066e29@news.povray.org Kenneth 
wrote:

> Confirmed

Thanks

Post a reply to this message

On 4/15/21 11:59 AM, William F Pokorny wrote:
> Aside 2: The segfault and POV_DEBUG assertion is during parser clean up. 
> However, I don't understand the related code well enough to know whether 
> or not there might be situations where dictionaries might be 'running' 
> OK, but not always behaving as they should. Users beware.
> 
> Unsure how long it might take me to unravel the dictionary parsing code 
> well enough to understand the problems - let alone fix them...

I believe I've run down the two issues to mistakes in a copy 
constructor. However, I need to test(1) with large dictionaries having 
key hashing collisions to be sure my fixes - as well the previously 
existing code - work correctly.

Posting immediately to confirm the previous code has the potential to 
"cross dictionaries" if you are using '#declare dic2 = dic1;' like 
encodings. Tangled and orphaned entries are possible.

(1) I suspect jr's recent foreach include work will come in handy! :-)

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... However, I need to test(1) with large dictionaries having
> key hashing collisions to be sure my fixes - as well the previously
> existing code - work correctly.
> ...
> (1) I suspect jr's recent foreach include work will come in handy! :-)

still ongoing but thank you for the vote of confidence.  and glad the code will
get a work-out.  :-)

quickly cobbled up example of what I think you have in mind, ie automating the
dictionary creation, below.  hth.


regards, jr.


#version 3.8;

global_settings {assumed_gamma 1}

#include "foreach.inc"

#declare A = array {
  "Aa", "Ab", "Ac", "Ad", "Ae", "Af", "Ag", "Ah", "Ai", "Aj", "Ak", "Al", "Am",
  "An", "Ao", "Ap", "Aq", "Ar", "As", "At", "AA", "Av", "Aw", "Ax", "Ay", "Az"
};

#macro mkKeys(i_,j_,elem_,arg_)
  #local arg_[elem_] = i_ * j_;
#end

#declare D = dictionary {
  .Macro: "mkKeys",
  .Walk: 1,
  .Extra: on,
  .Arg: "R"
};

#declare R = dictionary {
  .foo: 0
};

Foreach(A,D)

#debug concat("Az = ",str(R.Az,0,0),".\n")

Post a reply to this message

(a couple of corrections, and an extension)

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> ...and glad the code will get a work-out.  :-)

since ingo has apparently had a look, it should have read: glad the code will
get more work-out.


> quickly cobbled up example of what I think you have in mind, ie automating the
> dictionary creation, below.  hth.

not creation, .. "stuffing".  and the macro name ought to have been singular.
anyway, have a look at attached, a simple(r?) way of making key names (values
won't matter as much, I assume).


regards, jr.

Post a reply to this message

Attachments:
Download 'wfp.pov.txt' (1 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... However, I need to test(1) with large dictionaries having
> key hashing collisions to be sure my fixes - as well the previously
> existing code - work correctly.

thought/wondered a little more about testing (increasingly?) large dictionaries,
and made a monkeyed version ('foreach_d.inc') which has an option to add an
adjustable delay between calls of a payload macro (up to a minute).  if thought
useful, can provide a copy.


regards, jr.

Post a reply to this message

On 4/18/21 6:46 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ... However, I need to test(1) with large dictionaries having
>> key hashing collisions to be sure my fixes - as well the previously
>> existing code - work correctly.
> 
> thought/wondered a little more about testing (increasingly?) large dictionaries,
> and made a monkeyed version ('foreach_d.inc') which has an option to add an
> adjustable delay between calls of a payload macro (up to a minute).  if thought
> useful, can provide a copy.
> 

Yes, please post. You suspected correctly the foreach include fit less a 
direct fit than I 'thought' it would be for my testing.

That said, not posted an update because I've been sliding sideways 
yesterday and today.

Off taking a closer look at our parser string hash function. It's fast, 
but the distribution(1) into the symbol hash table isn't very good - bad 
enough I first thought something wrong was wrong with my dictionary fixes.

Currently have a version based on c++11 std::hash which - so long as you 
compile at high optimizations - is looking really good for performance 
and distribution. This even with my presently clunky adoption of the 
library version in code.

(1) - The linked lists off each hash key get long. For 256 incremented, 
'A' prefixed keys, table entries very clustered and with list depths of 
up to 15.

I hope to be back to testing my dictionary fixes in the next few days.

Bill P.

Post a reply to this message

in news:607d917e$1@news.povray.org William F Pokorny wrote:

> I hope to be back to testing my dictionary fixes in the next few days.
> 

Thanks Bill, for looking into this.

Ingo

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/18/21 6:46 AM, jr wrote:
> > ...
> Yes, please post. ...

attached.


> ...
> (1) - The linked lists off each hash key get long. For 256 incremented,
> 'A' prefixed keys, table entries very clustered and with list depths of
> up to 15.

makes one wonder how people actually use dictionaries.  are more than, say, 15
or 20 keys common?  (personally, less than 10, always, I'd say)  maybe a
"survey" on new (to 3.8) features' uptake?

a couple of 'povr' questions.  when will you make the lowercase-able version
available?  would you consider a feature request for a "-windowid" command-line
option to supply an X window to 'povr'?


regards, jr.

Post a reply to this message

Attachments:
Download 'wfpdelay.tar.xz.dat' (4 KB)