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