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