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

oh, boomer!  How have I missed such fun thread! :D

BTW, code completion works best in the editors you mentioned than in the
WinPov editor itself:  it completes not only keywords, but also
identifiers, like user-defined function, macro and variable names... and
because it's a simple and efficient text-completion mechanism, it doesn't
take huge amounts of memory by cramming a whole parser and semantic
analyser into the editor, like Windows-minded IDEs do...

About Povclipse:  hey, it's java!  Shouldn't it run anywhere for granted?

My best bet is vim.  Or emacs if you don't mind developing finger dextery
like a pianist...

Post a reply to this message

This is an old thread, but I kept seeing it when I would refresh this 
group, so I figured I'd read it.


>  > One central thing is that Unix users tend to insist using the same
>  > editor for most editing tasks.

> Philippe Debar wrote:
> It is a tendency and not rule, isn't it? I know some hardcore unix guru 
> will use the same editor for everything :

I wonder if that tendency did not develop as a result of not having a 
proper "clipboard" for some time. Whatever the reason, this tendency has 
contributed to the survival of interface paradigms which thrive despite 
rejection by the majority - or merely plurality. Try one of these[1] and 
you might find you like it even more than the Win-Pov editor.

  -Shay

[1] If you haven't after all of these months.

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> I wonder if that tendency did not develop as a result of not having a
> proper "clipboard" for some time.

clipboard, CUA standards, whatever... we should be thankful such things didn't
exist back then, or else we'd be all pretty much immersed in sterile
notepad-thinking sameness... like using several different editors from several
IDEs which are actually all the same thing.

IDEs and need for different editors is a thing of a utility-poor environment
like Windows, where any significant tools are only provided by commercial
vendors...

Post a reply to this message

nemesis wrote:
> 
> IDEs and need for different editors is a thing of a utility-poor
> environment like Windows, where any significant tools are only
> provided by commercial vendors...

Is that really the case? I thought all of the more significant freeware 
projects (Emacs, Vim, Firefox, Latex, Eclipse, etc.) worked on Windows 
as well.

  -Shay

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> nemesis wrote:
> >
> > IDEs and need for different editors is a thing of a utility-poor
> > environment like Windows, where any significant tools are only
> > provided by commercial vendors...
>
> Is that really the case? I thought all of the more significant freeware
> projects (Emacs, Vim, Firefox, Latex, Eclipse, etc.) worked on Windows
> as well.

sorry, I meant what comes out of the box, like Notepad, DOS console, javascript
interpreter inside IE etc... it's a poor environment and commercial providers
thrived by their all-in-one solutions.  Specially in the past, without internet
connection.

Post a reply to this message