 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I guess a new build was overdue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/31/2018 04:05 PM, Kenneth wrote:
> "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/"
Is that the directory that the SDL source is in? Just wondering. The
default is to write to the same directory, so maybe ...
It would be helpful if the error message included the path that POV-Ray
is trying to write to.
Try copying your source file to that directory. Then render it. If that
works, then we know it's a config problem elsewhere.
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> 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/"
>
Well, I found the problem: Human Error (as usual!)
With my WORKING v3.7.1 beta 9 version, I had *changed* the name of my
image-output folder to...
Kens_POV_Ray_rendered_IMAGES
.... which is the currently correct one.
..... and likewise for the image-output library path in its own POVRAY.INI
file...
Output_File_Name=C:\Users\Computer\Documents\Kens_POV_Ray_rendered_IMAGES\
Note the added underscores (and the no-longer-needed double-quotes, since there
are no longer any spaces in that library path.) So everything works fine in beta
9!
HOWEVER, the new 3.8.0 alpha 'engine' was loaded into my older 3.7 folder (which
is the correct placement)-- but the POVRAY.INI file for *v3.7* was using my OLD
library path (the one that I *thought* was correct, the one with no underscores
etc.) I had forgotten to change that INI file to the newer library path for my
output images.
SO... it turned out to be a library-path problem after all. Duh. I updated that
'bad' path, and all is well. Sorry for the trouble and confusion.
A question, though: In testing out alphas, betas, etc., OR while running the
original 3.7.0, should I make ONE master POVRAY.INI file and always use that, no
matter what program version I'm running? Up until now, I've always thought that
each version should keep its own INI file intact. (Uh, which obviously led to my
problem!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2018 um 19:08 schrieb jr:
> 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. :-)
Oops, I didn't see the "make and" there.
(*scratches head*)
I'd have to dig deep and embark on an extensive investigation to make a
reliable statement about this.
If you're talking about dropping the new executable into a v3.7
installation, then I would recommend against it. IIRC the Unix/Linux
incarnation wasn't designed to live piggyback on a v3.7 installation;
that's only done on Windows, because full-fledged installation is
difficult there.
If you're talking about replacing an existing v3.8-alpha binary with the
new one, that shouldn't be a problem.
>> 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.
Sky's the limit now. Whatever fits into your memory.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.09.2018 um 04:15 schrieb Kenneth:
> A question, though: In testing out alphas, betas, etc., OR while running the
> original 3.7.0, should I make ONE master POVRAY.INI file and always use that, no
> matter what program version I'm running? Up until now, I've always thought that
> each version should keep its own INI file intact. (Uh, which obviously led to my
> problem!)
The plan is as follows (for Windows at any rate):
(A) Final Releases
==================
Final releases of different "generations" (e.g. v3.7 vs. v3.8) are
intended to live separately from each other without interfering. The
only intentional point of contact would be the new generation copying
settings from the older generation (if detected) when first started.
(This means that, among other things, they each have their own POVRAY.INI.)
Final releases of the same generation (e.g. v3.7.0 vs. v3.7.1, though
this is hypothetical) are intended to replace each other. The only
reasonably sane way for different binaries of the same generation to
live alongside each other would be to rename one of the binaries, and
have both binaries share everything (most notably the POVRAY.INI, but
also registry settings and other stuff.)
(B) Release Candidates
======================
Release candidates are intended to behave exactly like the respective
final release (except for showng a different version number); this
extends to where they choose to live and how to (not) cooperate or
interfere with other versions.
(C) Beta Releases
=================
In order to allow for installing a beta release while also keeping an
earlier final release of the same generation (e.g. v3.7.0 proper and
v3.7.1-beta.1), beta releases are intended to live in their own happy
place, without interfering with any non-beta versions (but replacing or
interfering with other betas of the same generation).
(D) Development (Alpha) Releases
================================
While all of the above come with an installer, alpha releases don't;
therefore, to make installation reasonably easy, they need to piggyback
on an existing installation, and interfere with it extensively. It is
presumed that alpha users are experienced enough not to mess up their
nice final release, and are willing to accept the (small) risk of the
alpha accidently screwing something up.
New alpha releases of an existing generation (e.g. v3.7.1-alpha) will
piggyback on an earlier final release of the same generation (any v3.7
in the example case.
Alpha releases of a brand new generation (e.g. 3.8.0-alpha) have to
piggyback on a final release of the previous generation (again any v3.7
in the example case).
(E) Experimental Releases
=========================
Same deal as with alpha releases.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> If you're talking about replacing an existing v3.8-alpha binary with the
> new one, that shouldn't be a problem.
perfect.
> > ... the new, relaxed upper limit for strings?
> Sky's the limit now. Whatever fits into your memory.
ok.
thank you.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> The plan is as follows (for Windows at any rate):
>
Thanks for the excellent description and detail of the various releases and what
they mean. You probably posted some of this before (but which had not yet
impinged on my brain, I admit).
>
> (C) Beta Releases
> =================
>
> In order to allow for installing a beta release while also keeping an
> earlier final release of the same generation (e.g. v3.7.0 proper and
> v3.7.1-beta.1), beta releases are intended to live in their own happy
> place, without interfering with any non-beta versions (but replacing or
> interfering with other betas of the same generation).
>
>
> (D) Development (Alpha) Releases
> ================================
>
> While all of the above come with an installer...
I'm still just a little confused about this: I have an older 3.7.1 beta
release...
3.7.1-beta.4+msvc14.win64
.... that *AFAIK* is supposed to be installed into "an existing 3.7.0 binary"
(piggybacked, in other words.) I just tested this again, and the scheme works.
But that seems to go against the idea that betas always(?) come with their own
installer. Sorry to throw a small monkey-wrench into the discussion, but this
particular situation is a bit mysterious. Or maybe I'm simply misreading your
beta release info.
BTW, my idea of using only ONE 'master' POVRAY.INI file for *all* releases was
rather half-formed; sorry about that. I had a panicky notion that there were
*multitudes* of those INI files in various places, that had to be dealt with--
but of course that's not the case. (On my system, there are only two-- for my
3.7 and 3.7.1 beta 9 installs.) In any case, for such a scheme to work, I would
need to make the one master file, place it *somwewhere* (permanently), then make
Windows 'shortcuts' to place into the respective POV-Ray 'bin' folders. Being
the curious person that I am, I actually tried that. It doesn't work (as I
suspected) but I'm wondering why. Are 'non-functioning' shortcuts a general
Windows limitation for ALL such 'configuration files', or is it something
specific to POV-Ray by design? I'm certainly no expert about this stuff, which
is why I ask.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.09.2018 um 22:09 schrieb Kenneth:
>> The plan is as follows (for Windows at any rate):
>>
> Thanks for the excellent description and detail of the various releases and what
> they mean. You probably posted some of this before (but which had not yet
> impinged on my brain, I admit).
I may have mentioned some of it, maybe; but only in passing.
> I'm still just a little confused about this: I have an older 3.7.1 beta
> release...
> 3.7.1-beta.4+msvc14.win64
> ..... that *AFAIK* is supposed to be installed into "an existing 3.7.0 binary"
> (piggybacked, in other words.) I just tested this again, and the scheme works.
- Says who?
- How do you install it into "an existing 3.7.0 [installation]"?
- No; ever since v3.7.1-beta.2, it was intended to install in a separate
directory; the only exception was v3.7.1-beta.1, and that was by
mistake, and the reason that beta was never actually made public.
> BTW, my idea of using only ONE 'master' POVRAY.INI file for *all* releases was
> rather half-formed; sorry about that. I had a panicky notion that there were
> *multitudes* of those INI files in various places, that had to be dealt with--
> but of course that's not the case. (On my system, there are only two-- for my
> 3.7 and 3.7.1 beta 9 installs.) In any case, for such a scheme to work, I would
> need to make the one master file, place it *somwewhere* (permanently), then make
> Windows 'shortcuts' to place into the respective POV-Ray 'bin' folders. Being
> the curious person that I am, I actually tried that. It doesn't work (as I
> suspected) but I'm wondering why. Are 'non-functioning' shortcuts a general
> Windows limitation for ALL such 'configuration files', or is it something
> specific to POV-Ray by design? I'm certainly no expert about this stuff, which
> is why I ask.
I would suspect that it has something to do with Windows shortcuts not
really being proper links - not even soft links.
BTW, Windows /can/ manage genuine hard and soft links, and they work far
more reliably. But you need to use shell commands or 3rd party tools to
create them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 01.09.2018 um 22:09 schrieb Kenneth:
> > I'm still just a little confused about this: I have an older 3.7.1 beta
> > release...
> > 3.7.1-beta.4+msvc14.win64
> > ..... that *AFAIK* is supposed to be installed into "an existing 3.7.0 binary"
> > (piggybacked, in other words.) I just tested this again, and the scheme works.
>
> - Says who?
> - How do you install it into "an existing 3.7.0 [installation]"?
I did the usual trick of removing (sequestering) the original 3.7.0 pvengine64
file and simply dropping in the beta4 version of the file instead (all within
the 3.7.0 folder, or rather 3.7; I also have a separate 3.7 beta 9 folder.)
Seems to run just fine. I don't *remember* it being a 'stand-alone'/installable
version when I downloaded it. (I *hope* that I would have noticed that!) But
I'll take another look at the Github download page for the beta4 version, to see
if I screwed up.
I guess you mean that the beta4 is/was supposed to be a 'complete' standalone
install, like 3.7.1 beta 9. Makes me wonder why or how it works in my scheme,
when apparently it shouldn't! (BTW, I did double-check the running program to
make sure it IS beta4 that I'm running. AND to make sure that the beta4 engine
is indeed in my 3.7 folder and not in my 3.7 beta 9 folder by mistake.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I did the usual trick of removing (sequestering) the original 3.7.0 pvengine64
> file and simply dropping in the beta4 version of the file instead (all within
> the 3.7.0 folder, or rather 3.7; I also have a separate 3.7 beta 9 folder.)
> Seems to run just fine.
Here's a little caveat though, which just occured to me: On my desktop, I have a
"POV-ray 3.7.0" shorcut (icon) which I always use to start it (regardless of the
*particular* pvengine64 file that I'm currently running there-- the original, or
various alphas, or beta4.) I've never changed that shorcut (meaning, as I remove
or drop in various pvengines to test things, I don't make a 'new' shorcut for
the current version; it never seems to be necessary.) But the shortcut still
starts up the correct current pvengine (as I can see when querying POV-Ray's
'Help/About POV-ray for Windows' menu.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 01.09.2018 um 22:09 schrieb Kenneth:
>
> > > I'm still just a little confused about this: I have an older 3.7.1 beta
> > > release...
> > > 3.7.1-beta.4+msvc14.win64
> > - How do you install it into "an existing 3.7.0 [installation]"?
>
Well, from looking at Github, I see that beta4 is/was indeed a 'complete'
install, not a simple drop-in 'pvengine'. I have no idea how I actually obtained
*just* the engine itself-- I must have downloaded and installed the complete
package, then 'extracted' the engine file to use (with 3.7.0) while discarding
the rest, in some fit of madness or ignorance. :-O But it works, strangely (or
*appears* to!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.09.2018 um 05:34 schrieb Kenneth:
>>>> I'm still just a little confused about this: I have an older 3.7.1 beta
>>>> release...
>>>> 3.7.1-beta.4+msvc14.win64
>
>>> - How do you install it into "an existing 3.7.0 [installation]"?
>>
>
> Well, from looking at Github, I see that beta4 is/was indeed a 'complete'
> install, not a simple drop-in 'pvengine'. I have no idea how I actually obtained
> *just* the engine itself-- I must have downloaded and installed the complete
> package, then 'extracted' the engine file to use (with 3.7.0) while discarding
> the rest, in some fit of madness or ignorance. :-O But it works, strangely (or
> *appears* to!)
I've just taken a few minutes to dig a bit deeper, and it seems that
binaries can be used in three different modes:
(A) Stand-alone - in this mode, the binary maintains its own registry
entry and has its own support files.
(B) Piggyback - in this mode, the binary shares both the registry entry
and support files with another binary.
(C) Semi-Piggyback - in this mode, the binary maintains its own registry
entry but shares support files with another binary.
Only modes (A) and (B) are really intentional, with (A) being the
intended mode if the binaries are from different "generations" or one is
a beta and the other isn't, and (B) being the intended mode for alpha
releases.
Mode (C) _can_ indeed be achieved by dropping a "raw" binary into an
existing installation that differs in "generation" and/or beta status,
_if_ no version of same "generation" and beta status is currently
installed. (If such a version is installed, the dropped-in binary will
enter into mode (B) with that version, despite the binary being located
elsewhere.)
There is one very big caveat to this however: This will totally screw up
any subsequent proper installation of the dropped-in version (or any
other version of same generation and beta status); such a subsequent
installation will fail to enter mode (A), and continue to share support
files with that other installation, while its own support files will lie
dormant.
Uninstalling and re-installing would probably solve this problem.
Another thing worth mentioning in this context is that the location of a
binary doesn't matter at all - except in the process to enter mode (C).
During normal operation, a binary will find its support files through
the registry, not through its own location.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> I've just taken a few minutes to dig a bit deeper, and it seems that
> binaries can be used in three different modes:
> ....
>
> There is one very big caveat to this however: This will totally screw up
> any subsequent proper installation of the dropped-in version (or any
> other version of same generation and beta status...
To be safe, I'll re-install a clean v3.7.0 (and discard the offending beta4.) I
can only hope that I haven't screwed up my registry in some way.
Thanks for the detective work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.09.2018 um 17:03 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> I've just taken a few minutes to dig a bit deeper, and it seems that
>> binaries can be used in three different modes:
>> ....
>>
>> There is one very big caveat to this however: This will totally screw up
>> any subsequent proper installation of the dropped-in version (or any
>> other version of same generation and beta status...
>
> To be safe, I'll re-install a clean v3.7.0 (and discard the offending beta4.) I
> can only hope that I haven't screwed up my registry in some way.
Just for the records: It's the v3.7-beta installation you've screwed up,
not the v3.7 proper installation. There /may/ have been interference
from the beta, but I doubt it.
And re-installing v3.7 proper won't clean up the v3.7-beta detritus. So
should you ever again install a v3.7-beta, even if you use the proper
installer, and even if you now un-install and re-install v3.7.0, that
beta will /again/ interfere with the v3.7.0.
A proper install of the /beta/, followed by an uninstall of it, should
be the way to clean up this issue.
Or run "regedit" and throw out `HKCU\Software\POV-Ray\v3.7-beta` and/or
`HKLM/Software/POV-Ray/v3.7-beta`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
> Am 30.08.2018 um 21:38 schrieb jr:
> > ... the keys of a dictionary? ...
another question regarding dictionaries.
I try (in a to be included file):
#local A = array [4] { ... };
...
#declare D = dictionary {
.arr: (A),
...
};
and get a "Parse Error: Expected 'numeric expression', array identifier found
instead"
when I try
.arr: A,
I get a parse error in the using scene: "Attempt to access uninitialised
dictionary element". (3.8.0-alpha.9606898) can arrays not be used in a
dictionary?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 02.09.2018 um 17:03 schrieb Kenneth:
>
> Just for the records: It's the v3.7-beta installation you've screwed up,
> not the v3.7 proper installation...
>
> A proper install of the /beta/, followed by an uninstall of it, should
> be the way to clean up this issue.
>
> Or run "regedit" and throw out `HKCU\Software\POV-Ray\v3.7-beta` and/or
> `HKLM/Software/POV-Ray/v3.7-beta`.
Thanks a bunch for the clarification! I may go both routes, if I can get up the
gumption to monkey around with the registry ;-)
Seems that I did something really dumb... :-(
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 02.09.2018 um 17:03 schrieb Kenneth:
>
> >
> > Just for the records: It's the v3.7-beta installation you've screwed up,
> > not the v3.7 proper installation...
> >
> > A proper install of the /beta/, followed by an uninstall of it, should
> > be the way to clean up this issue.
> >
> > Or run "regedit" and throw out `HKCU\Software\POV-Ray\v3.7-beta` and/or
> > `HKLM/Software/POV-Ray/v3.7-beta`.
>
> I may go both routes...
Just to follow up:
It all worked out very smoothly.
In case you're curious...
First thing I did was to take a look at the registry; there was lots of detritus
in HKCU\Software\POV-Ray\ , including some *old* stuff from a previous defunct
hard drive (labeled a "G" drive, for reasons that I understand but are hard to
explain, ha.) No POV-Ray entry at all at HKLM\Software\.
Leaving that stuff alone for the time being, I took a 'brute-force' approach and
un-installed BOTH (all) my current versions of POV, including any and all
app-specific folders. Going back to the registry, I then deleted the *entire*
POV-Ray 'folder', instead of picking and choosing individual entries in it. Then
rebooted. Taking another look there, it was nice and clean re: POV-ray, no trace
of it remaining (that I know of.)
I did download and install beta 4 at this point, for curiosity's sake; then
uninstalled it, and re-cleaned the registry. Then another reboot.
Then I re-downloaded and installed v3.7.0, the newest 3.8 'alpha' engine, and
3.7.1 beta 9, in that order. Just like my previous set-up. After a little
updating of POVRAY.INI and quickres.ini, everything works fine now.
No vestige of beta 4 remains!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Just to follow up:
https://i.imgur.com/cAFOwQ3.gif
https://g1rm.files.wordpress.com/2017/12/akira2018.gif?w=584
https://media.giphy.com/media/uRKhHCvfOdUmQ/giphy.gif
It's the only way to be sure.
#NeverPissOffKenneth
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > Just to follow up:
>
> https://i.imgur.com/cAFOwQ3.gif
> https://g1rm.files.wordpress.com/2017/12/akira2018.gif?w=584
> https://media.giphy.com/media/uRKhHCvfOdUmQ/giphy.gif
>
> It's the only way to be sure.
>
> #NeverPissOffKenneth
Funny! Yeah, that's about the way I felt.
....and THEN, I hired three super-sensitive bomb-sniffer dogs, to root out any
remaining beta4 molecules...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.09.2018 um 20:37 schrieb jr:
> I try (in a to be included file):
>
> #local A = array [4] { ... };
>
> ...
>
> #declare D = dictionary {
> .arr: (A),
> ...
> };
>
> and get a "Parse Error: Expected 'numeric expression', array identifier found
> instead"
That's only natural: There is no meaning associated with the expression
`( ARRAY_IDENTIFIER )`.
> when I try
>
> .arr: A,
>
> I get a parse error in the using scene: "Attempt to access uninitialised
> dictionary element". (3.8.0-alpha.9606898) can arrays not be used in a
> dictionary?
Nope - can't confirm with...
... wait, what?! - You're replying to a thread titled "POV-Ray
alpha.9811560" to report a problem you're seeing with alpha.9606898?
Never mind - can't confirm with either of the versions. Not with the
Windows incarnation, nor with the Linux incarnation. So apparently some
information is missing from your story.
- Are you sure you're using genuine original unmodified source code?
- Can you provide a minimal yet complete scene file that exhibits the
problem?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 02.09.2018 um 20:37 schrieb jr:
> > I try (in a to be included file):
> > and get a "Parse Error: ...
>... (3.8.0-alpha.9606898)
> Nope - can't confirm with...
very sorry to have wasted your time with this. when I put together a minimal
example, using only 'foo's and 'bar's, it works. not sure what I did (the array
is now separate), but the fault's all mine.
> ... wait, what?! - You're replying to a thread titled "POV-Ray
> alpha.9811560" to report a problem you're seeing with alpha.9606898?
ill thought out too (the replied to post touched on 'dictionary'), sorry.
noted.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-08-31 à 16:47, Kenneth a écrit :
> "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 :-(
>
>
>
To me, it look like you want to write the files into the POV-Ray install
directory instead of the .POV file location.
Make sure that the output paths all point to the correct locations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotronca> wrote:
> Le 18-08-31 à 16:47, Kenneth a écrit :
> >
> > Seems that *something* must have gotten corrupted in the 'problem' POV-ray
> > folder (my only guess right now.) Woe is me :-(
>
> To me, it look like you want to write the files into the POV-Ray install
> directory instead of the .POV file location.
> Make sure that the output paths all point to the correct locations.
I probably confused you with a lack of detail; sorry. My original two 'complete'
POV-ray installs (3.7.0 and 3.7.1 beta 9) had their various folders in two
places, as usual: "Documents", and "Programs". My scene files are in a separate
folder in "Documents", outside the 'master' "POV-RAY" folder there, for safety's
sake. The folder I send renders to is also a separate one, and also in
"Documents." My main problem was that both versions of the program have there
own POVRAY.INI files-- with the library path to my image-output folder in both--
but I forgot to update one of those with a *change* I made to the name of that
folder.
All is well now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> No vestige of beta 4 remains!!
[even further off-topic]
I'm curious: Is there a way to do an automated word search (and/or partial word
search-- "beta4" for example) of the ENTIRE Windows registry, all at once? In
other words, to find a particular registry entry (or multiple ones) when you
only know part of its name beforehand?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.09.2018 um 21:34 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>>
>> No vestige of beta 4 remains!!
>
> [even further off-topic]
>
> I'm curious: Is there a way to do an automated word search (and/or partial word
> search-- "beta4" for example) of the ENTIRE Windows registry, all at once? In
> other words, to find a particular registry entry (or multiple ones) when you
> only know part of its name beforehand?
You mean something like a "find all" that spits out a list of
occurrences, rather than a find first / find next mode of operation?
Sure - albeit not with regedit, but a lesser known command-line tool,
`reg.exe`.
For instance, to search for anything in "HKEY_LOCAL_MACHINE" containing
"v3.7-beta", open a command prompt and run:
reg.exe HKLM /s /f "v3.7-beta"
then go and make yourself a fresh cup of your favourite hot beverage.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-09-03 à 15:34, Kenneth a écrit :
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>>
>> No vestige of beta 4 remains!!
>
> [even further off-topic]
>
> I'm curious: Is there a way to do an automated word search (and/or partial word
> search-- "beta4" for example) of the ENTIRE Windows registry, all at once? In
> other words, to find a particular registry entry (or multiple ones) when you
> only know part of its name beforehand?
>
>
>
>
In regedit, you can only find matches one by one. You can use F3 to find
the next occurance.
It can be very long and tedious.
There are some third party replacements, like Registry Workshop, that
will find all occurances in one swoop and let examine all hits in any order.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
