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