> Philippe Debar schrieb:
 >> [...]
 >>
 >> But anyway if I want to do any of these, I can always use the CLI.
 >
 > Well - you can't with WinPOV.  The point is having the choice - this 
is what Unix is all about.

I thought there was a Cygwin Pov (but maybe this requires compilation 
under Windows?)... But I never felt the need for it.

 >> Agreed, but couldn't the editor provide a pause function that calls 
the OS one?
 >
 > Sure it could, but - as with various other features there has not 
been sufficient need to add such a feature to any editor i know of 
apparently.
 >
 > If you think a bit about it - there is very rarely a need for 
actually pausing a render.  If you have another task that is more urgent 
the best way (apart from stopping the render) is to set priorities 
accordingly ('renice').

Could be done in the editor too. IIRC Povwin does.

 > The wish to actually completely suspend a render probably results 
from the common (but wrong) assumption that a computer is inefficient if 
occupied with several tasks simultaneously (in most cases it is more 
that those operating the computer have troubles with that ;-)).

Well, it can be really unresponsive, even if efficient.


 >> BTW, I think I'll try (again) to grok (X)Emacs. Wish me luck ;)
 >
 > That's of course one of the tougher choices (but not a bad one).

Well, while thinking about the specialized/general editor stuff, I 
figured that one -- I for instance -- has to be not totally "perfectly 
normal" to do 3D with a text editor and not a 3D gui ;)

Povingly

//Philippe

PS: Sorry everybody for the private mails, I keep hitting the wrong menu 
item. Maybe I drink too much coffee...

Post a reply to this message

>  > The wish to actually completely suspend a render probably results 
> from the common (but wrong) assumption that a computer is inefficient i
f 
> occupied with several tasks simultaneously (in most cases it is more 
> that those operating the computer have troubles with that ;-)).
> 
> Well, it can be really unresponsive, even if efficient.


You'll see that on Linux, your computer will be much more responsive 
than on windows so you might not worry about that :)

Post a reply to this message

>
>> Well, it can be really unresponsive, even if efficient.
> 
> 
> You'll see that on Linux, your computer will be much more responsive 
> than on windows so you might not worry about that :)


In general, that is true. But... on my Ubuntu box, PovClipse + a render 
= impossible to do anything else. PovClipse + Pov-Ray + something else 
(like Firefox or Thunderbird or OOo or Gimp) is the only circumstance I 
encountered since I use Ubuntu (2 years) that causes such an 
unresponsiveness that I can call it a gui freeze.

//Philippe

Post a reply to this message

Philippe Debar schrieb:
> 
> In general, that is true. But... on my Ubuntu box, PovClipse + a render 
> = impossible to do anything else. PovClipse + Pov-Ray + something else 
> (like Firefox or Thunderbird or OOo or Gimp) is the only circumstance I 
> encountered since I use Ubuntu (2 years) that causes such an 
> unresponsiveness that I can call it a gui freeze.

I don't know about Java (there might be components of the Java system 
wrongly running with increased priority) but apart from that this would 
be extremely unusual.  Unless you are running out of memory of course - 
since there is nothing like priority for swapping exceeding available 
memory will always slow down the whole system.  Also note Gimp uses its 
own 'virtual memory' system so you should make sure its settings are 
appropriate.

You can easily test if a slowdown you experience during a POV-Ray render 
is due to POV-Ray 'eating up' CPU time - run it with lowest priority 
('nice -19 povray' instead of 'povray') and see if this changes 
anything.  If not a hypothetical pause function in POV-Ray would not 
help either.

-- Christoph

Post a reply to this message

> Philippe Debar schrieb:
> I don't know about Java (there might be components of the Java system 
> wrongly running with increased priority) but apart from that this would 
> be extremely unusual.  Unless you are running out of memory of course - 
> since there is nothing like priority for swapping exceeding available 
> memory will always slow down the whole system.  Also note Gimp uses its 
> own 'virtual memory' system so you should make sure its settings are 
> appropriate.


It's at least the combination of swap (Eclipse is very memory-hungry and 
nearly eats up all of my 768Mo by itself), and 100% CPU usage (Pov).

But even then, I already ran into these conditions without getting such 
a slowdown. Eclipse/Java must be doing something, but I will not spend 
any more time trying to guess what. I'll consider this a major defect 
and will make my choice among the other editors.


> You can easily test if a slowdown you experience during a POV-Ray render 
> is due to POV-Ray 'eating up' CPU time - run it with lowest priority 
> ('nice -19 povray' instead of 'povray') and see if this changes 
> anything.  If not a hypothetical pause function in POV-Ray would not 
> help either.


Thanks for the tip.


//Philippe

Post a reply to this message

Java is something really bad for any system which uses it. At work, I 
develop using netbeans and I have everybody as the same feeling : it's 
heavy ... very very very heavy. This is due to the memory managment 
model of the java technology itself : there is no memory managment.

The best thing you can do is not to use something based on java :-/

Thierry



>> Philippe Debar schrieb:
>> I don't know about Java (there might be components of the Java system 

>> wrongly running with increased priority) but apart from that this 
>> would be extremely unusual.  Unless you are running out of memory of 
>> course - since there is nothing like priority for swapping exceeding 
>> available memory will always slow down the whole system.  Also note 
>> Gimp uses its own 'virtual memory' system so you should make sure its 

>> settings are appropriate.
> 
> 
> It's at least the combination of swap (Eclipse is very memory-hungry an
d 
> nearly eats up all of my 768Mo by itself), and 100% CPU usage (Pov).
> 
> But even then, I already ran into these conditions without getting such
 
> a slowdown. Eclipse/Java must be doing something, but I will not spend 

> any more time trying to guess what. I'll consider this a major defect 
> and will make my choice among the other editors.
> 
> 
>> You can easily test if a slowdown you experience during a POV-Ray 
>> render is due to POV-Ray 'eating up' CPU time - run it with lowest 
>> priority ('nice -19 povray' instead of 'povray') and see if this 
>> changes anything.  If not a hypothetical pause function in POV-Ray 
>> would not help either.
> 
> 
> Thanks for the tip.
> 
> 
> //Philippe

Post a reply to this message

Philippe Debar <phdebarAscarlet.be> wrote:
> Hi!
>
Hi Philippe

> What is your favorite editor for povray in Linux? Which one would you
> recommend? Coming from Windows, I was spoiled with the built-in Pov
> editor and I am searching for something similar.
>
> I use Ubuntu.
>
> I already tried with Gedit (not enough), Scite (the best so far),
> PovClipse (much too much resource hungry) and wxPyvon (unfinished and no
> longer active?), but none have all the nice features of the window version.
>


dans la vie).
One thing though : when I miss a Povwin editor feature, I use wine

> I'd like to have:
> * Easy pov options editing
> * Code completion
> * Insert menu
> * Contextual pov help
> * Hide and show image, with partial rendering
> * Auto indent
> * Open include files
>
> Would no such editor exist in the Linux world? I am not very happy at
> the thought that I'll have to run WinPov in Wine =_=' I might even have
> to reboot Windows >_<
>
>
> Povingly,
>
> Philippe


Fabien

Post a reply to this message

Philippe Debar <phd### [at] rletbe> wrote:
> It's at least the combination of swap (Eclipse is very memory-hungry and
> nearly eats up all of my 768Mo by itself), and 100% CPU usage (Pov).

Hi Philippe,

Open Source lives from the user base and from their response to the project
team. This is especially true for bug reporting and general feedback.

In terms of PovClipse:

If you find something you consider a major defect please create a bug
tracker using the PovClipse bug tracking mechanism at
http://sourceforge.net/tracker/?group_id=172199&atid=860832 .


You wrote you would like to see the following features in a POV editor, I
added in round brackets the current support state:

* Easy pov options editing (supported by render configurations)
* Code completion (supported, including templates)
* Insert menu (standard editor functions, but no POV-related things)
* Contextual pov help (supported, press Shift+F2)
* Hide and show image, with partial rendering (supported, but not for
partial renderings. Turn on the Povray flag for displaying the image
instead)
* Auto indent
* Open include files (supported, the Strg key activates hyperlinks on the
include file names)
* pause and stop rendering (can not be supported as Povray itself does not
offer this functionality, at least not to my knowledge)
* jump to / highlight error line
* autosave before render and one-keypress render (autosave: suported as of
0.7.1, one-keypress render: supported using the launcher)
* column selection and manipulation
* multiple splitview (supported, both horizontally and vertically)
* block indent/dedent and block comment/uncomment (both supported)


In your posting from 20 Mar 2007 you wrote:

> * Developed for Windows ; Linux is "Not tested yet, but reported to
> run". Can't find any plan to change this state.

This is because I'm the only one developing PovClipse. PovClipse is not
developed **FOR** Windows, it is developed **WITH** Windows and is
therefore tested with windows.

The choice of using Eclipse is based on the fact that all parts (Povray /
MegaPOV, Eclipse and Java) are available on most Operating Systems,
including Windows, Linux, Mac and others.

Back to your statement above: the plan of supporting Linux is based on
somebody joining the development / testing team being concerned with this

PovClipse runs on Linux but is not officially supported. But if you find a
(Linux related) bug I will try to fix it anyway.

> * I had to fight a bit too much to my taste to make it work.
Using a new tool is always a bit inconvenient until you are used to it.

> * I cannot get code completion to work at all.
Please fill a bug report and please include the PovClipse log file.

> * Why doesn't the delete key want to work?!?
Please fill a detailed bug report

> * The render settings dialog is rather temperamental.
What exactly do you mean with that?

> * No forum (the author doesn't seem to check those on Sourceforge very
>   often and they are not advertised on the main site), no community.

and is linked from the main site. PovClipse is a young product, the
community is evolving.

> * It is sooo sloooowww and resource heavy.
Depends on the machine. Yes, I totally agree with you, Eclipse **IS** memory
consuming like hell, but it offers a great framework in turn. I guess

tried PovClipse using a virtual machine (SuSE 10.2) with a setting of 512M
RAM and have not seen anything like your UI freeze. Maybe your machine runs

lots of ram?


Please consider a re-test using the new 0.7.1 version. There were lots of
features added since you had a look on PovClipse (sounds like it was 0.6.3
or prior). Since 0.7.0 the PovClipse log contains also the time taken by
the most time-consuming methods, it would be helpful if you post it in a
bug report.


Cheers,

Wolf

Post a reply to this message

i use Kate for most (if not all of my scripting =]

Post a reply to this message

Hi,

I apologise for the loooong delay... I thought I was going to have some 


All that follows is IIRC.

Overall, I found PovClipse to be one of the best Pov Gui for Linux, with 
the most annoying problem being his resource-hunger.


> Philippe Debar <phd### [at] rletbe> wrote:
>> It's at least the combination of swap (Eclipse is very memory-hungry and
>> nearly eats up all of my 768Mo by itself), and 100% CPU usage (Pov).
> 
> Hi Philippe,
> 
> Open Source lives from the user base and from their response to the project
> team. This is especially true for bug reporting and general feedback.

Yes. At the time, bug reporting seemed to be essentialy through email, 
which meant that user had no way of knowing what bugs were already 
reported. I filled almost no bug because I did not want to bother a lone 
and courageous dev' with bugs under an OS that seemed unavailable to him.


>> * I had to fight a bit too much to my taste to make it work.
> Using a new tool is always a bit inconvenient until you are used to it.

Yes. I dit make it work. Well, most of.


>> * I cannot get code completion to work at all.
> Please fill a bug report and please include the PovClipse log file.

I sure will if/when I go back to poving.

>> * Why doesn't the delete key want to work?!?
> Please fill a detailed bug report

Here it is : "Pressing the del in the editor key does nothing".


>> * The render settings dialog is rather temperamental.
> What exactly do you mean with that?

The dialog did not always appeared or did nothing.


> 
>> * It is sooo sloooowww and resource heavy.
> Depends on the machine. Yes, I totally agree with you, Eclipse **IS** memory
> consuming like hell, but it offers a great framework in turn. I guess
> upgrading your memory

Not possible right now.


> tried PovClipse using a virtual machine (SuSE 10.2) with a setting of 512M
> RAM and have not seen anything like your UI freeze. Maybe your machine runs

> lots of ram?

No. Nothing special, only desktop apps.

> Please consider a re-test using the new 0.7.1 version. There were lots of
> features added since you had a look on PovClipse (sounds like it was 0.6.3
> or prior). Since 0.7.0 the PovClipse log contains also the time taken by
> the most time-consuming methods, it would be helpful if you post it in a
> bug report.

Try as I might, I could never make Eclipse update PovClipse :(

If/When ever I go back to poving, I'll check PovClipse again and give 
feedback.

Povingly,

//Philippe

Post a reply to this message