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