Not sure wether this was reported before.


//-----------
#version 3.8;

#macro SomeThing(A)
  #local RD = dictionary;
  RD
#end 
 
#declare SD = SomeThing(1);
//-----------

This crashes POV-Ray. Sometimes it asks to write a dump file.


//-----------
#version 3.8;

#macro SomeThing(A)
  #local RD = dictionary;
  (RD)
#end 
 
#declare SD = SomeThing(1);
//------------


This results in: test.pov" line 5: Parse Error: Expected 'numeric 
expression', dictionary
identifier found instead

Ingo

Post a reply to this message

hi,

ingo <ing### [at] tagpovrayorg> wrote:
> Not sure wether this was reported before.
>
> //-----------
> #version 3.8;
>
> #macro SomeThing(A)
>   #local RD = dictionary;
>   RD
> #end
>
> #declare SD = SomeThing(1);
> //-----------
>
> This crashes POV-Ray. Sometimes it asks to write a dump file.

here (unofficial alpha.10064268) it parses cleanly, with and without argument.
 can also assign key to 'SD'.  only warnings (assumed gamma, no objects).


> //-----------
> #version 3.8;
>
> #macro SomeThing(A)
>   #local RD = dictionary;
>   (RD)
> #end
>
> #declare SD = SomeThing(1);
> //------------
>
>
> This results in: test.pov" line 5: Parse Error: Expected 'numeric
> expression', dictionary
> identifier found instead

same here.


regards, jr.

Post a reply to this message

in news:web.6075d5d9d2107a6c79819d986cde94f1@news.povray.org jr wrote:

 
> here (unofficial alpha.10064268) it parses cleanly, with and without
> argument. 
>  can also assign key to 'SD'.  only warnings (assumed gamma, no
>  objects). 
> 
> 

Should have added:
This is version 3.8.0-x.10064738+av694.msvc14.win64.
Win10.

Thanks jr, I'll step a version or so back tomorrow to test.

Ingo

Post a reply to this message

Op 13/04/2021 om 19:17 schreef ingo:
> Not sure wether this was reported before.
> 
> 
> //-----------
> #version 3.8;
> 
> #macro SomeThing(A)
>    #local RD = dictionary;
>    RD
> #end
>   
> #declare SD = SomeThing(1);
> //-----------
> 
> This crashes POV-Ray. Sometimes it asks to write a dump file.
> 
> 
> //-----------
> #version 3.8;
> 
> #macro SomeThing(A)
>    #local RD = dictionary;
>    (RD)
> #end
>   
> #declare SD = SomeThing(1);
> //------------
> 
> 
> This results in: test.pov" line 5: Parse Error: Expected 'numeric
> expression', dictionary
> identifier found instead
> 
> Ingo
> 

Using 3.8.0-alpha.10064268-+av691.msvc14w

First code works fine.
Second code crashes with identical parse error.

-- 
Thomas

Post a reply to this message

On 4/13/21 1:17 PM, ingo wrote:
> Not sure wether this was reported before.
> 
> //-----------
> #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:

#macro SomeThing()
   dictionary
#end
#declare SD = SomeThing();

---
That said. Playing around with your original, first encoding I do see 
flaky segfaults which come and go in the povr branch that includes a set 
of v3.8 parser fixes necessary for other parser issues.

Thus far, the direct encoding above has never crashed. Neither has v3.8 
master at commit 74b3ebe0 for ANY variation of your encodings (ignoring 
the second (RD) one and less any heavy dictionary use).

I'll try and get together a debug build over the next few days - 
hopefully it crashes reliably enough I can run down the cause. I suspect 
something is going wrong with the identifier pointer handling when we 
get to the:

#declare SD = RD; // Effective action

Then depending on where the pointers point in memory and perhaps too the 
actual dictionary use, we crash or not - but, we shall see.

Bill P.

Post a reply to this message

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.

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.

Ingo

Post a reply to this message

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)

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

Thanks.

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

Don't know. I think the dictionary feature is still new enough (and it's 
been buggy enough), we don't know what sizes would be common.

The concern over the behavior of the token hashing function for the 
symbol table(s) applies to much more than dictionaries. This code is 
used during parsing and at run time for variables in the function calls 
for isosurfaces and parametrics. Part of why, for performance, it's best 
to set up functions for isosurfaces and parametrics as fully resolved as 
possible at the final use in those objects.

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

As for another povr branch release, I have no firm date in mind at the 
moment. I'm still significantly hung up on documentation(how) and 
strongly related is what to do with all the ini, config, flag, 
global_settings and environment variable inputs at the front of each 
POV-Ray execution.

Aside: Stumbled across another option the other day; long in the code, 
but apparently never documented (Include_ini?).

I'd like to make that big, not completely functional or consistent 
tangle of code simpler and self documenting - with a capability for 
localized translations, but, how... I've got some starts / tests in the 
code, but nothing I'd consider anywhere near complete. Been looking some 
at Rust, which has a popular and powerful command line options package. 
I was thinking maybe it could be used as a completely stand alone front 
end generating some standard option setting input file to POV-Ray 
itself. Still just playing / thinking. Likely, such simplification a 
pipe dream, but nothing wrong with dreaming I guess. :-)

Not sure what you are after with the -windowid? Some time back made X11 
the default preview window handler in the povr branch. Though, sdl2 (or 
sdl1.2) is supported too as a command line option. So, by default, there 
is an X window with an id which you can query/grab when POV-Ray is run 
with the preview window. Is that what you are after - to do window 
captures/dumps or similar?

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> The concern over the behavior of the token hashing function ...

might be worth comparing with other, say the Berkeley DB, hash implementations.


> > ...option to supply an X window to 'povr'?
> ...
> Not sure what you are after with the -windowid?

so I could do the equivalent of 'xterm -into $id', ie have 'povr's output go
into a window supplied by my app.


regards, jr.

Post a reply to this message

On 4/19/21 3:51 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> The concern over the behavior of the token hashing function ...
> 
> might be worth comparing with other, say the Berkeley DB, hash implementations.
> 

Not committed, but I've added such a TODO to the code along with notes 
on the versions I tested.

> 
>>> ...option to supply an X window to 'povr'?
>> ...
>> Not sure what you are after with the -windowid?
> 
> so I could do the equivalent of 'xterm -into $id', ie have 'povr's output go
> into a window supplied by my app.
> 

By 'output' taking you to mean the preview window.

It could be useful. I've not done enough X11 windows stuff to understand 
the implications. Today, certain events are captured by the preview 
window set up. Meaning - I think - the larger application would not have 
complete control the 'POV-Ray' sub window.

---
Dreaming : As you know, I've carried for a while the thought of POV-Ray 
being it's own simple modeler for splines an such. Further, if we get to 
the point where the 'scene' rendered is responding to window events, why 
couldn't POV-Ray be a sort of infinitely configurable dynamic window gui 
widget sub-app for other applications. The executable is small enough 
(performance?). With it one could get whatever windowing look they 
wanted and not be locked into available ones with particular widget 
packages and appearances.

Aside: Years back, I ran across a windowing package with a similar idea. 
The displayed, apparent widgets collection was decoupled from the larger 
display. It looked like there were widget gui windows everywhere, but it 
worked with only one gui 'event window' and a single dynamically 
generated and mapped image underneath. The image looking like a 
collection of gui widgets. But, I've never again been able to find my 
notes or the package!

Sorry about the ramblings. I'll put the -windowid thing on my 
'interested in it list' - no promises.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/19/21 3:51 PM, jr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> ...
> >> The concern over the behavior of the token hashing function ...
> >
> > might be worth comparing with other, say the Berkeley DB, hash implementations.
>
> Not committed, but I've added such a TODO to the code along with notes
> on the versions I tested.

had I been thinking, I'd have mentioned "or anything with a decent associative
array implementation".  awk and Tcl :-) come to mind.


> >>> ...option to supply an X window to 'povr'?
> >> ...
> >> Not sure what you are after with the -windowid?
> >
> > so I could do the equivalent of 'xterm -into $id', ie have 'povr's output go
> > into a window supplied by my app.
>
> By 'output' taking you to mean the preview window.

yes.  (will try + remember to stick with correct terminology)


> It could be useful. I've not done enough X11 windows stuff to understand
> the implications. Today, certain events are captured by the preview
> window set up. Meaning - I think - the larger application would not have
> complete control the 'POV-Ray' sub window.

I suspect one would need to use the 'pause_when_done' option, cf gnuplot's
'-persist'.  the window remains povr's, the display is "live" while povr runs.
from Tk I'd create an empty frame with the '-container' option and get its id,
then run povr with an option to display itself in window '$id'.

afair, povr, when it asks for a "toplevel" (or "root"?) window, it gets a
handle.  bar one (or two) event mask stuff things, there's be no difference, and
neither povr or the user can really tell.

wish I could be more precise but when I lost my previous life a little over a
decade ago, among the losses was a near complete set of O'Reilly's X11R5 books.
so all from (dimmed) memories.


> Dreaming : As you know, I've carried for a while the thought of POV-Ray
> being it's own simple modeler for splines an such. Further, if we get to
> the point where the 'scene' rendered is responding to window events, why
> couldn't POV-Ray be a sort of infinitely configurable dynamic window gui
> widget sub-app for other applications. The executable is small enough
> (performance?). With it one could get whatever windowing look they
> wanted and not be locked into available ones with particular widget
> packages and appearances.

(I like where this is going.. :-))

a little like embedding a Tcl interpreter[*], I guess.  that particular way of
doing would not be difficult if the parser could deal with being fed piecemeal.
and even if a whole scene is required, one could generate that from boilerplate,
mostly.  thinking that other projects too might benefit, like BE's complete
keyword generator idea.

[*] have a look at df3tcl.


> Aside: Years back, I ran across a windowing package with a similar idea.
> The displayed, apparent widgets collection was decoupled from the larger
> display. It looked like there were widget gui windows everywhere, but it
> worked with only one gui 'event window' and a single dynamically
> generated and mapped image underneath. The image looking like a
> collection of gui widgets. But, I've never again been able to find my
> notes or the package!

a db with the image "hot spots", linked to event (procedures), and Robert's your
mother's brother.  :-)


> Sorry about the ramblings.

on occasion the highlight of the day.


> I'll put the -windowid thing on my 'interested in it list' - no promises.

it's a start.  :-)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> I suspect one would need to use the 'pause_when_done' option, cf gnuplot's
> '-persist'.  the window remains povr's, the display is "live" while povr runs.
> from Tk I'd create an empty frame with the '-container' option ...

an example (only 5 yrs ago and cannot recall details :-()

I use the attached with a BASH one-liner:

#!/bin/sh
/home/jr/src/tcltk/spiro-1.tk | gnuplot -persist

'execPlot' prepares the input to gnuplot.  different for different s/wares, but
usually boils down to "feeding" program's stdin.


regards, jr.

Post a reply to this message

Attachments:
Download 'spiro-1.tk.xz.dat' (2 KB)

On 4/19/21 10:19 AM, William F Pokorny wrote:
> On 4/18/21 6:46 AM, jr wrote:
...
> 
> I hope to be back to testing my dictionary fixes in the next few days.
> 

Posted my fixes:

http://news.povray.org/povray.beta-test/thread/%3C6080263e%241%40news.povray.org%3E/

Web Message: <6080263e$1@news.povray.org>

Plus, turned up nothing more that looks wrong to me in v3.8 with 
dictionaries once the fix in place.

----

Thanks jr for the testing assist!

I played quite a lot with the pure foreach array functionality too and I 
turned up not a single issue (not of my own doing :-)). Your include is 
looking good to me. Enough that I'll spend my few remaining play time 
minutes this day thinking about better alternatives to our 
Parse_String() macro hack.

Bill P.

Post a reply to this message

in news:608029da$1@news.povray.org William F Pokorny wrote:

> Posted my fixes

Thanks!

ingo

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/19/21 10:19 AM, William F Pokorny wrote:
> Posted my fixes: ...
> Plus, turned up nothing more that looks wrong to me in v3.8 with
> dictionaries once the fix in place.

thanks.  will try patch over the coming days.


> Thanks jr for the testing assist!

the pleasure's all mine, as they say.  ;-)


> I played quite a lot with the pure foreach array functionality too and I
> turned up not a single issue (not of my own doing :-)). Your include is
> looking good to me.

</dance-around-kitchen>  (not quite .. crackers, there's good music on the radio
too)  thanks, gives me "wind in the sails" to finish off documentation + stuff.

I also should say that it was made easier because of the "standing on the
shoulders of (POV-Ray community) titans" thing.


> Enough that I'll spend my few remaining play time
> minutes this day thinking about better alternatives to our
> Parse_String() macro hack.

what, no coffee?  ;-)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 4/19/21 10:19 AM, William F Pokorny wrote:
> > Posted my fixes: ...
> > Plus, turned up nothing more that looks wrong to me in v3.8 with
> > dictionaries once the fix in place.
>
> thanks.  will try patch over the coming days.

forgot to ask (for confirmation) - same fix for 'povr' I assume?


note to LeForgeron - can/should I use WFP's fix for the 'bitter orange'?


regards, jr.

Post a reply to this message

On 4/22/21 4:02 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
> 
> forgot to ask (for confirmation) - same fix for 'povr' I assume?
> 

Yes.

To be clear; When I make public a v3.8 fix, I 'fully expect' it to apply 
to the v3.8 master branch as is, but I've not verified it with my own 
testing.

It's the - in hand - povr branch code I test. A branch which has other 
fixes for bugs with which I do not wish to again be tangled.

Bill P.

Post a reply to this message