 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
run POV 3.6 on win XP
failing to save file "<filename here>"
some thing else using file???
just before rendering
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"RTRT buff" <tom### [at] yahoo com> schreef in bericht
news:40fa5904@news.povray.org...
> run POV 3.6 on win XP
> failing to save file "<filename here>"
>
> some thing else using file???
>
> just before rendering
but while parsing, right?
cu!
--
ZK AKA Gaeriel
http://www.povplace.be.tf
"Spin the planet!"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This has something to do with 3.6 using threads. I have this when I abort a
long parse and try to save after that. What I do: I copy the code into the
buffer and restart pov-ray without saving. I paste the code over the old
code that POV-Ray opens with and THEN I save.
I haven't had the patience yet, but maybe waiting for a while before
retrying to save might help. This might be a bug but I haven't delfed into
that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Apache" <apa### [at] hotmailcom> wrote in message
news:40faa534$1@news.povray.org...
> This has something to do with 3.6 using threads. I have this when I abort
a
> long parse and try to save after that. What I do: I copy the code into the
> buffer and restart pov-ray without saving. I paste the code over the old
> code that POV-Ray opens with and THEN I save.
> I haven't had the patience yet, but maybe waiting for a while before
> retrying to save might help. This might be a bug but I haven't delfed into
> that.
>
I don't want to get into the "this is a bug or not" argument, but I find it
annoying, and this "feature" was not in 3.5. In fact, I've returned to
3.5, as this seems to happen to me every few minutes when using 3.6. I
guess it just has to do with the way some of us stop renders/parses.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fc182d$1@news.povray.org> , "Jeremy M. Praay"
<jer### [at] questsoftwarecom> wrote:
> I don't want to get into the "this is a bug or not" argument, but I find it
> annoying, and this "feature" was not in 3.5. In fact, I've returned to
> 3.5, as this seems to happen to me every few minutes when using 3.6. I
> guess it just has to do with the way some of us stop renders/parses.
Well, that attitude is hardly helpful. You refuse to provide any even
remotely useful description how to reproduce a problem you are seeing. Do
you really think this makes it more likely the problem will go away in the
future? Whining does really get nobody anywhere!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40fc1a56@news.povray.org...
> In article <40fc182d$1@news.povray.org> , "Jeremy M. Praay"
> <jer### [at] questsoftwarecom> wrote:
>
> > I don't want to get into the "this is a bug or not" argument, but I find
it
> > annoying, and this "feature" was not in 3.5. In fact, I've returned to
> > 3.5, as this seems to happen to me every few minutes when using 3.6. I
> > guess it just has to do with the way some of us stop renders/parses.
>
> Well, that attitude is hardly helpful. You refuse to provide any even
> remotely useful description how to reproduce a problem you are seeing. Do
> you really think this makes it more likely the problem will go away in the
> future? Whining does really get nobody anywhere!
>
I've seen this mentioned at least a couple of other times in these
newsgroups. I don't feel the need to mention it again and again (or at all
if someone has already mentioned it), but I don't mind saying that I'm
experiencing the same annoying problem, hoping that the more people who
mention it will lead to it getting fixed sooner. I didn't think I was being
whiney. I thought I was just letting someone know that this is not an
isolated case.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fc7542$1@news.povray.org> , "Jeremy M. Praay"
<sla### [at] hotmailcom> wrote:
> I've seen this mentioned at least a couple of other times in these
> newsgroups. I don't feel the need to mention it again and again (or at all
> if someone has already mentioned it), but I don't mind saying that I'm
> experiencing the same annoying problem, hoping that the more people who
> mention it will lead to it getting fixed sooner. I didn't think I was being
> whiney. I thought I was just letting someone know that this is not an
> isolated case.
Well, it should be fairly obvious that only a few of the thousands of people
using POV-Ray for Windows see the problem, so obviously a tiny bit more is
needed than saying "me too". The bug reporting guidelines in the faq group
exist for a reason ... if you do not follow them, we just won't be able to
help you. It is that simple, sorry!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40fcc820@news.povray.org...
> Well, it should be fairly obvious that only a few of the thousands of
people
> using POV-Ray for Windows see the problem, so obviously a tiny bit more is
> needed than saying "me too". The bug reporting guidelines in the faq
group
> exist for a reason ... if you do not follow them, we just won't be able to
> help you. It is that simple, sorry!
>
I'm apologize that I can't provide you with much more information than has
already been posted by others on this matter. I believe that it is a bug,
and I that was my point to Apache. It appears in 3.6 and it is not in 3.5
(in other words, it is not related to a separate change in my operating
system). This seems to be a random occurrence that may be in relation to
the way I (we) stop parses/renders.
I'm sorry that doesn't help you. Like the others, I'm running XP Home with
I/O permissions turned off. As far as I can tell from previous posts, this
is the common theme.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A way to reproduce this thing:
1.
Take any scene that needs a long parse time so that you have the time to
abort it before the rendere kicks in.
2.
While pov-ray is parsing, abort it and change something in the source so
that you can save changes.
POV-Ray won't be liking that because the file is apparently still in use
and/or locked because it's apparently still parsing. Press Abort when
POV-Ray asks you what you want to do now so that you can edit the code again
if you like
3.
When parsing has really stopped and the RUN (alt-g) button is available
again, try to save once again. POV-Ray will refuse to save even now. I
simply copy-paste the code I want to save, close POV-Ray without storing
data. And I'll paste the code into a new instance of POV-Ray
Although I'm pretty sure you guys already know of this kind of behaviour, I
still hope I'm at least helping a bit with this!
Regards,
Eli Jehoel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fd4ec1$1@news.povray.org> , "Apache"
<apa### [at] hotmailcom> wrote:
> 1.
> Take any scene that needs a long parse time so that you have the time to
> abort it before the rendere kicks in.
>
> 2.
> While pov-ray is parsing, abort it and change something in the source so
> that you can save changes.
> POV-Ray won't be liking that because the file is apparently still in use
> and/or locked because it's apparently still parsing. Press Abort when
> POV-Ray asks you what you want to do now so that you can edit the code again
> if you like
>
> 3.
> When parsing has really stopped and the RUN (alt-g) button is available
> again, try to save once again. POV-Ray will refuse to save even now. I
> simply copy-paste the code I want to save, close POV-Ray without storing
> data. And I'll paste the code into a new instance of POV-Ray
I tried the "Tierra (LOTW)" scene posted in p.b.s-f a few weeks ago and used
it with 30000 trees and let it parse to 50 million tokens, then used the
keybord to stop the render and instantly after that save the modified scene
file (in which I had inserted a space). The files was saved as expected.
The system was a P4 3GHz with 1 GB of memory running Win XP Pro (used over
remote desktop) with all available Win patches installed.
Thus, I am afraid more information is needed. A scene for example. And the
system software, processor and physical memory of everone seeing this
problem will surely not hurt either.
> Although I'm pretty sure you guys already know of this kind of behaviour, I
> still hope I'm at least helping a bit with this!
Well, I think you have been told numerous times that this is not the case.
And given that there is no flood of reports in these groups despite
thousands of download, it should be fairly clear that this only happens on
some systems...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
This thread probably belongs in povray.windows.
That being said, I can't replicate the problem either. If I can you can be
sure it will be fixed but at this point I'm not seeing it.
Thorsten, I wonder if this is another example of non-volatile variables causing
problems ? e.g. I could never replicate that 'thread failed to init' problem
either but I know it affected certain machines but not others, just like this
one does.
If so a VC++ compile will probably flush it out.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fddf29@news.povray.org> , "Chris Cason"
<new### [at] deletethispovrayorg> wrote:
> Thorsten, I wonder if this is another example of non-volatile variables
causing
> problems ? e.g. I could never replicate that 'thread failed to init' problem
> either but I know it affected certain machines but not others, just like this
> one does.
I rather suspect it is a race condition somewhere.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm sorry that doesn't help you. Like the others, I'm running XP Home
with
> I/O permissions turned off. As far as I can tell from previous posts,
this
> is the common theme.
I have had the problem using Windows ME, but so far any attempt to replicate
the problem has failed.
Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40fd5fcf$1@news.povray.org...
>
> I tried the "Tierra (LOTW)" scene posted in p.b.s-f a few weeks ago and
used
> it with 30000 trees and let it parse to 50 million tokens, then used the
> keybord to stop the render and instantly after that save the modified
scene
> file (in which I had inserted a space). The files was saved as expected.
> The system was a P4 3GHz with 1 GB of memory running Win XP Pro (used over
> remote desktop) with all available Win patches installed.
I generally use the "Stop Sign" button, if that's at all relevant.
When you say you stopped "the render", do you actually mean "the parse"?
Again, as others have mentioned this does not appear to happen every time.
You could try your test at various intervals during the parse, and after
perhaps 10 or 20 times, see if it eventually causes the problem.
>
> Thus, I am afraid more information is needed. A scene for example. And
the
> system software, processor and physical memory of everone seeing this
> problem will surely not hurt either.
XP Home with all critical updates, AMD XP 3200+, 1GB RAM. I can retest
after making sure that I have ALL XP updates.
>
> > Although I'm pretty sure you guys already know of this kind of
behaviour, I
> > still hope I'm at least helping a bit with this!
>
> Well, I think you have been told numerous times that this is not the case.
This problem was first mentioned on June 16th.
> And given that there is no flood of reports in these groups despite
> thousands of download, it should be fairly clear that this only happens on
> some systems...
>
This may be an underestimate. The fact that a few regular posters to this
newsgroup have reported this problem likely means that a great deal more
people are having this problem and are simply not reporting it.
I'm willing to try anything that you can suggest to narrow this down, but
right now it appears to be completely random.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fec516$1@news.povray.org> , "Jeremy M. Praay"
<jer### [at] questsoftwarecom> wrote:
>> I tried the "Tierra (LOTW)" scene posted in p.b.s-f a few weeks ago and
> used
>> it with 30000 trees and let it parse to 50 million tokens, then used the
>> keybord to stop the render and instantly after that save the modified
> scene
>> file (in which I had inserted a space). The files was saved as expected.
>> The system was a P4 3GHz with 1 GB of memory running Win XP Pro (used over
>> remote desktop) with all available Win patches installed.
>
> I generally use the "Stop Sign" button, if that's at all relevant.
>
> When you say you stopped "the render", do you actually mean "the parse"?
Well, yes, the parse, of course :-)
> Again, as others have mentioned this does not appear to happen every time.
> You could try your test at various intervals during the parse, and after
> perhaps 10 or 20 times, see if it eventually causes the problem.
I tried several times, and other scenes as well. It was suggested to
reproduce it, stopping a "long" parse would be required. So I only stated
the longest I tried.
>> Well, I think you have been told numerous times that this is not the case.
>
> This problem was first mentioned on June 16th.
There was nothing specific in any of the reports so far allowing to
reproduce the problem. As stated in the faq group, we only can say
something about confirmed bugs. If we were to take every bug report
serious, especially but not limited to Windows, we would soon be fixing the
systems of everybody around, randing from removing viruses to replacing
defective RAM. Thus, a single unconfirmed report that cannot be rpeproduced
is exactly as if the problem was never reported.
>> And given that there is no flood of reports in these groups despite
>> thousands of download, it should be fairly clear that this only happens on
>> some systems...
>
> This may be an underestimate. The fact that a few regular posters to this
> newsgroup have reported this problem likely means that a great deal more
> people are having this problem and are simply not reporting it.
It certainly is not. There was a several month long public beta test of
POV-Ray, and none of the beta testers reported this particular problem
either. Yet, many other problems were reported and fixed.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi there,
I encounter similar problems trying to save modifications to files in
POV-Ray after aborting during parsing. I am running POV-Ray version
3.6.0.icl8.win32 under Windows XP Professional (SP1); hardware: 2.6 GHz P4,
512 MB RAM.
I have a scene file which seems to cause this error consistently if POV is
aborted during parsing. The error is produced this way:
* pressing 'Run' (or Alt+G) with the scene file in question;
* aborting while parsing (just 1 second of parsing should be sufficient to
reproduce it, but aborting during the rendering itself or letting the render
finish does not pose any problems at all);
* making a change to the .pov file (try adding a small comment, for
example);
* trying to save the .pov file afterwards (at any time until I exit POV, it
seems).
Trying to press 'Save', POV-Ray displays this message:
POV-Ray Editor
EAccessViolation: EAccessViolation
In this case, POV also fails to rename the original file to .bak. Upon
exiting POV, if I choose to save my changes, Windows tells me that POV has
crashed and the changes are not saved (choosing to discard the changes,
things are just fine). It affects only the .pov file in question; I can save
changes to other files without problems.
I can still use 'Save As...' with the .pov file in question, but trying to
save it with the original name still yields the 'EAccessViolation' error.
I have tried re-downloading and reinstalling POV 3.6, which didn't help the
problem. I wasn't able to reproduce the problem with POV 3.5.
The scene file uses an include file with a macro for outlining a mesh. The
macro uses 1D arrays quite extensively; I'll be posting the scene and
include file in povray.binaries.scene-files shortly.
- Peter
"RTRT buff" <tom### [at] yahoocom> skrev i en meddelelse
news:40fa5904@news.povray.org...
> run POV 3.6 on win XP
> failing to save file "<filename here>"
>
> some thing else using file???
>
> just before rendering
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40fef90b$1@news.povray.org> , "Peter Svendsen"
<pel### [at] hotmailcom> wrote:
> Hi there,
>
> I encounter similar problems trying to save modifications to files in
> POV-Ray after aborting during parsing. I am running POV-Ray version
> 3.6.0.icl8.win32 under Windows XP Professional (SP1); hardware: 2.6 GHz P4,
> 512 MB RAM.
>
> I have a scene file which seems to cause this error consistently if POV is
> aborted during parsing. The error is produced this way:
> * pressing 'Run' (or Alt+G) with the scene file in question;
> * aborting while parsing (just 1 second of parsing should be sufficient to
> reproduce it, but aborting during the rendering itself or letting the render
> finish does not pose any problems at all);
> * making a change to the .pov file (try adding a small comment, for
> example);
> * trying to save the .pov file afterwards (at any time until I exit POV, it
> seems).
>
> Trying to press 'Save', POV-Ray displays this message:
>
> POV-Ray Editor
> EAccessViolation: EAccessViolation
>
> In this case, POV also fails to rename the original file to .bak. Upon
> exiting POV, if I choose to save my changes, Windows tells me that POV has
> crashed and the changes are not saved (choosing to discard the changes,
> things are just fine). It affects only the .pov file in question; I can save
> changes to other files without problems.
>
> I can still use 'Save As...' with the .pov file in question, but trying to
> save it with the original name still yields the 'EAccessViolation' error.
>
> I have tried re-downloading and reinstalling POV 3.6, which didn't help the
> problem. I wasn't able to reproduce the problem with POV 3.5.
>
> The scene file uses an include file with a macro for outlining a mesh. The
> macro uses 1D arrays quite extensively; I'll be posting the scene and
> include file in povray.binaries.scene-files shortly.
Thank you very much! I have now been able to reproduce your problem. We
are going to look into it.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Again, as others have mentioned this does not appear to happen every time.
> You could try your test at various intervals during the parse, and after
> perhaps 10 or 20 times, see if it eventually causes the problem.
In case it helps folks understand things, the way the software works is this:
when you ask the parse/render to stop, the front-end sends a message to the
back-end asking it to stop. Until it stops the input file will remain locked
(if the parse hasn't ended, that is).
For some reason on some occasions the back-end isn't stopping the parse when
asked.
The front-end keeps track of the stop request and if you enter another one and
the previous one hasn't yet been honored, it stamps down a lot harder on the
back-end and abruptly terminates it. This is why a second stop request often
makes a difference.
As for why it's not stopping, well, we'll have to find that ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It certainly is not. There was a several month long public beta test of
> POV-Ray, and none of the beta testers reported this particular problem
> either. Yet, many other problems were reported and fixed.
to be fair to the OP, the 'backend thread failed to init' problem only
briefly emerged during testing (but then went away). Yet it came back with
a vengance after release. given not a lot of users end up in these groups,
it could be some just try and either put up with it, or simply give up.
I personally tend to agree that this problem is probably more widespread
than we in the team currently think.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In this case, POV also fails to rename the original file to .bak.
does the .bak file already exist, and if so, is it either read-only or otherwise
locked ? what happens if you manually delete it ?
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> does the .bak file already exist, and if so, is it either read-only or
otherwise
> locked ?
Yes, there was already a .bak file when I got the problems mentioned before.
I have tried removing the .bak file and reproducing the problem once again,
but I'm still not allowed to save the file, nor can POV create a new .bak
file (unless I haven't aborted parsing). The .bak file is not write
protected.
However, while POV cannot rename the file to .bak, I can edit the existing
.bak file from POV and save it.
Exiting POV seems to be the only way to get around the problem; closing the
.pov file after an aborted parse and re-opening it, I still can't save
changes to the file.
>what happens if you manually delete it ?
I can delete, move etc. the .bak file from Windows Explorer without
problems. However, I am not allowed to move or delete the .pov file until I
exit POV, as Windows claims it's in use, even though I've pressed 'Close'
with the file in POV. I suspect the problem may be an issue of closing the
.pov file when aborting the parse.
- Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am having a similar problem. Aborting a parse on certain .pov files
(every one I have had problems with has called a macro...) can somehow lock
the file. I get the unusal error "Failed to save file: operation completed
successfully". It seems that many of the times I have had this problem the
status bar had read "Parsed 5002 tokens" for quite a while, but the clock
in the lower right corner continues to count. This time when I tried to
replicate it, the last message was "Parse Error: Out of memory. Cannot
allocate 156 bytes for pigment", but it still refuses to stop parsing. I
have hit "the stop sign" several times. It finally quit after almost
fifteen minutes.
My system is POV 3.6 under Windows XP Pro fully patched, AMD 2100+, 512MB
PC2700 Kingston Value Ram, ASUS A7N8X (Nforce 2) Motherboard, Radeon 7500LE
video.
I called a macro which I wrote which creates interesting fractal objects and
the higher the order, the more complex the object. I bumped up the order
until it generates a couple million objects, and have this problem. I was
having the same problem with much more reasonable renders, though.
Alex Wollangk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Sounds like you're running out of memory and starting to swap.
Yup. Actually, running out of memory, swapping, running out of swap space
and crashing. That is fine and expected. It was just that it then
wouldn't let me save the file giving me the error "Can't save file:
operation completed successfully" which is an extremely odd error.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been having the same problem, but just so you know this problem also
occurs if there is a syntax error in a macro in the include file.
This means that the error occurs more frequently than it would otherwise- it
can't be prevented by simply avoiding stopping the render at parse time.
I'm having to restart POVray rather often as a result of this. It's just a
blessing that it opens and closes so quickly ;)
Cheers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
