I guess a new build was overdue.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> I guess a new build was overdue.

is it ok to just make and copy the new executable into place, or have any of the
supporting files (docs etc) changed too?

on one of the new (in 3.8) features: I don't think there's a way to enumerate
the keys of a dictionary?  could that (function ?) be added?


regards, jr.

Post a reply to this message

Am 30.08.2018 um 21:38 schrieb jr:

> is it ok to just make and copy the new executable into place, or have any of the
> supporting files (docs etc) changed too?

There's a caveat regarding the help file: In v3.8 it is expected to have
the name `povray.chm`, while in v3.7 it has the name `povray37.chm`.
This means v3.8.0-alpha cannot open the help file of a v3.7 it is
dropped into, unless you copy it to the new name (a simple link should
suffice); on the other hand you can leverage it to drop in the v3.8
inbuilt help from the source package.

I haven't gotten around to updating the v3.8 help file to the latest
Wiki contents yet, so it may be a bit behind.

Other than that, there are no really interesting changes to the support
files, so there's no reason to copy them as well (and besides, v3.7
wouldn't like it).

> on one of the new (in 3.8) features: I don't think there's a way to enumerate
> the keys of a dictionary?  could that (function ?) be added?

Not yet. I had pondered different approaches to facilitate this, but
wasn't happy with any of them, so decided to postpone that problem for now.

From a user's perspective the most straightforward approach would have a
for-each directive to iterate over all the entries in the dictionary,
possibly like so:

    #for(K,Dict)
      #debug concat("Key='",K,"' Value='",Dict[K],"'\n")
    #end

However, this comes with pitfalls in cases where the dictionary is
modified during the loop, e.g. to add more entries or remove the current
entry.

Another approach that avoids these issues would be to have a function
that would construct an array holding all the keys, which you could then
iterate over like so:

    #local KeyArray = keys(Dict);
    #for(I,0,dimension_size(Keys,1))
      #local K = KeyArray[I];
      #debug concat("Key='",K,"' Value='",Dict[K],"'\n")
    #end

However, this would be more memory-heavy, maybe also slower, and more
cumbersome to use.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 30.08.2018 um 21:38 schrieb jr:
>
> > is it ok to just make and copy the new executable into place, or have any of the
> > supporting files (docs etc) changed too?
> There's a caveat regarding the help file: ... `povray37.chm`.

this is a for a Linux box.  :-)

> I haven't gotten around to updating the v3.8 help file to the latest
> Wiki contents yet, so it may be a bit behind.

when you do, can you please add information regarding the new, relaxed upper
limit for strings?  I found a few mentions of it [limit] not applying any more,
but no number for the new limit.  also for the colour_map entry, iirc.

> Other than that, there are no really interesting changes to the support
> files, so there's no reason to copy them as well (and besides, v3.7
> wouldn't like it).

ok.  thanks.

> > on one of the new (in 3.8) features: I don't think there's a way to enumerate
> > the keys of a dictionary?  could that (function ?) be added?
>
> Not yet. I had pondered different approaches to facilitate this, but
> wasn't happy with any of them, so decided to postpone that problem for now.
>
> From a user's perspective the most straightforward approach would have a
> for-each directive to iterate over all the entries in the dictionary,
> possibly like so:
>
>     #for(K,Dict)
>       #debug concat("Key='",K,"' Value='",Dict[K],"'\n")
>     #end
>
> However, this comes with pitfalls in cases where the dictionary is
> modified during the loop, e.g. to add more entries or remove the current
> entry.

agree, an iterator ("general purpose"?) would be clean, maybe even '#foreach()'.

would it not be acceptable to take a "snap-shot" and make that available, on the
(documented) understanding that it is simply the state at that time, and is read
only?

I ask because I think a dictionary could be a handy mechanism for macro
parameters and "package configuration" for stand-alone include files.

> Another approach that avoids these issues would be to have a function
> that would construct an array holding all the keys, which you could then
> iterate over like so:
>
>     #local KeyArray = keys(Dict);
>     #for(I,0,dimension_size(Keys,1))
>       #local K = KeyArray[I];
>       #debug concat("Key='",K,"' Value='",Dict[K],"'\n")
>     #end
>
> However, this would be more memory-heavy, maybe also slower, and more
> cumbersome to use.

a snap-shot in other words.  (I don't see why function + iterator would have to
be exclusive :-))


regards, jr.

Post a reply to this message

> I guess a new build was overdue.

[on Windows 7 Ultimate 64-bit]
I'm getting a strange fatal error on all scene files that I try to run (which I
haven't seen before, with other similar development builds that get installed
into the v3.7 directory):

"cannot create render state output file"

Since no one else has mentioned this, I must be doing something wrong at my
end(?)

I assume that a scene needs  #version 3.8  (although I've also tried it with
#version 3.80 and 3.7, with no luck.) Does anything in PVENGINE or POVRAY.INI
need changing, perhaps?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> > I guess a new build was overdue.
>
> [on Windows 7 Ultimate 64-bit]
> I'm getting a strange fatal error on all scene files that I try to run...

BTW, my scenes do run (they parse), but the error occurs at the end of the
parsing stage. So it doesn't seem to be a library-path problem(?)

Post a reply to this message

On 08/31/2018 01:48 PM, Kenneth wrote:
> 
>> I guess a new build was overdue.
> 
> [on Windows 7 Ultimate 64-bit]
> I'm getting a strange fatal error on all scene files that I try to run (which I
> haven't seen before, with other similar development builds that get installed
> into the v3.7 directory):
> 
> "cannot create render state output file"
> 
> Since no one else has mentioned this, I must be doing something wrong at my
> end(?)
> 
> I assume that a scene needs  #version 3.8  (although I've also tried it with
> #version 3.80 and 3.7, with no luck.) Does anything in PVENGINE or POVRAY.INI
> need changing, perhaps?
> 
> 
> 
> 

This says POV-Ray does not have permission to write to the directory.

Changing the version in the SDL won't affect POV-Ray's ability to write
to that directory. :)

The render state file is an intermediate file in case you want to
abort/resume a render. You can turn it off with -CC on the command line,
but then I'd bet that it won't have permission to write the output image
to that directory either.

Does it work with other directories? i.e. ones you own?

-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:

> > [on Windows 7 Ultimate 64-bit]
> > I'm getting a strange fatal error on all scene files that I try to run...
> > "cannot create render state output file"
> >
>
> This says POV-Ray does not have permission to write to the directory.

My first thought was to check my (Windows)POV-Ray menu item, "Options/Script I/O
restrictions" (in case it had changed somehow), but it's set to:
No restrictions
Permit Read/Write in Current Directory
Disable Starting Other programs

BTW, no problem occurs when I run one of the older (3.7-folder) alpha or beta
versions-- just this 3.8.0 variant.

>
> The render state file is an intermediate file in case you want to
> abort/resume a render. You can turn it off with -CC on the command line,
> but then I'd bet that it won't have permission to write the output image
> to that directory either.
>

Good news: Adding -cc to the command line DOES work-- the scene now renders!
Thanks for that hint.

So apparently(?), the problem is with the state-file-writing mechanism, in some
way... (at least on my end)...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> Good news: Adding -cc to the command line DOES work-- the scene now renders!
> Thanks for that hint.
>

Well, things are still not quite right: I neglected to notice that, even though
the scene does now render to the preview window, there's no image saved:

"cannot write PNG data" (fatal error after the preview)

I re-checked my POVRAY.INI file to make sure it has the correct library path for
image output; it's still correctly set to...

Output_File_Name="C:/Users/Computer/Documents/Kens POV-Ray rendered IMAGES/"

But no image file is written.
Alas, still very strange...

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> Well, things are still not quite right...
>
..... and they're getting stranger :-/

Now the same problem is happeniong with my (older) 3.7 alphas and betas-- even
my original 3.7.0--  EXCEPT with my 'stand-alone' 3.7.1 beta 9  install. That
one continues to work correctly. (It's own 'guts' are in its own folder in
"Programs/POV-Ray" called "3.7 beta", which might be a clue; all the other 3.7
alphas and betas-- and 3.7.0-- share another different folder there but still in
"Programs/POV-Ray".)

So I re-booted my computer as a last resort. But the problem remains.

Seems that *something* must have gotten corrupted in the 'problem' POV-ray
folder (my only guess right now.) Woe is me :-(

Post a reply to this message