I'm using MegaPov (still 0.5a) as a testbed for some of the
platform-specific enhancements I've been playing with.  Since the
changes are Unix-specific, I decided it made the most sense to announce
it here.

- configure script.  Should be simple: ./configure; make; su; make
install
Please let me know if you have any problems! This is a pretty rough
draft, and I'd like to get the bugs out of it.  If you have a Unix
system you can test this on, you would be doing me a favor by trying
this out and letting me know how it goes.

- one big executable.  There's now just one binary that generates the
right kind of display based on the context in which it is executed.  
Specifics: 
--if you have $DISPLAY set or pass --display on the command line, you
get X preview.
--if you're at the console, and either you're root or you have MegaPov
suid root, you get SVGA preview.
--if none of the above (you're at the console as pondscum, you're in a
telnet session without specifying a --display, etc.), you get ASCII.
Let me know if anyone has any other needs not met by this.
This is conditionally compiled, so it should compile fine on machines
that don't have X or SVGAlib.

- I'm leaving out the libpng and zlib source code, since libpng
especially doesn't play well with the configure script.  Maybe if I find
a way (lots of m4 and shell scripts, I suppose), I'll put it back later.

- The precompiled binary requires X and SVGA libraries.  If you don't
have these, you'll have to either get them or compile your own from the
source.  I'll look into ways around this in the future.

- RPM's available for those using Red Hat and related Linux
distributions.  I'm going to look into .deb versions.

- The source code has been rearranged a bit to make it easier to use
autoconf and automake.  The arrangement is also a bit more GNUish, for
similar reasons.

- automake provides all the GNU-standard Makefile targets.

- The docs and sample scenes now come with the source or binaries, as
appropriate.

As usual, the files live at
http://www.mailbag.com/users/mtgordon/megapov.html

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> - one big executable.  There's now just one binary that generates the
> right kind of display based on the context in which it is executed.
> Specifics:
> --if you have $DISPLAY set or pass --display on the command line, you
> get X preview.
> --if you're at the console, and either you're root or you have MegaPov
> suid root, you get SVGA preview.
> --if none of the above (you're at the console as pondscum, you're in a
> telnet session without specifying a --display, etc.), you get ASCII.
> Let me know if anyone has any other needs not met by this.
> This is conditionally compiled, so it should compile fine on machines
> that don't have X or SVGAlib.

Maybe a stupid (and selfish ;-) idea: would it be possible to have
something that would continue running if you log out and shut down the X
server even if povray was started with X display and without nohup?

-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

On Mon, 26 Jun 2000 03:09:33 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>Let me know if anyone has any other needs not met by this.

Hmm... I ssh into my blind Linux box and have a X server for Windows
with DISPLAY being export-ed upon logon accordingly. My brother and I
usually log on as root in order to use updatecvs to keep track of gcc
and avr-gcc updates and do other stuff not available to the mere user.

This setup requires that long renders are left in the background so
that they are unaffected when (not 'if') Windows crashes. Because of
this, I use the unix target and redirect the output to a file which is
then analyzed by a perl script available through CGI that converts the
partial output to jpg and sends it back along with the stats and
current progress reports.

My question is, will the new Unix addition work for me?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Francois Dispot wrote:

> Maybe a stupid (and selfish ;-) idea: would it be possible to have
> something that would continue running if you log out and shut down the X
> server even if povray was started with X display and without nohup?

My advice at this point is to kill the render and continue it nohup
without display when you decide to log off.  In theory I could try
hacking some of the signal-handling code, but I'm pretty sure it would
involve some major surgery.  Also, most users would expect logging out
and shutting down the X server to kill POV-Ray, so I'd have to find a
way for the user to request this behaviour.  I'm trying to keep this as
simple as possible; POV-Ray already has a confusing number of
command-line switches.  I might look into this for 4.0, but unless I
have some sort of epiphany, I don't see it coming in 3.5.

BTW, I plan on implementing frame numbering in X display of animations,
but that's going to wait for a future test release.  No promises for
3.5, but I haven't abandoned the project.

-Mark Gordon

Post a reply to this message

Peter Popov wrote:

> My question is, will the new Unix addition work for me?

The X display will only come up if you've said you want display.  If you
have display turned off, you're fine.  Do you want to use the ASCII
display in these cases?  If so, running POV-Ray (MegaPov for now)
through a script that nukes $DISPLAY might do the trick.  I'm trying to
avoid the need for users to specify what they want to happen.  Is this
reasonable?

-Mark Gordon

Post a reply to this message

On Mon, 26 Jun 2000 18:50:35 -0500, Mark Gordon <mtg### [at] mailbagcom>
wrote:

>The X display will only come up if you've said you want display.  If you
>have display turned off, you're fine.  Do you want to use the ASCII
>display in these cases?  If so, running POV-Ray (MegaPov for now)
>through a script that nukes $DISPLAY might do the trick.  I'm trying to
>avoid the need for users to specify what they want to happen.  Is this
>reasonable?

Good enough for me. As far as I understand, I should make a script
that undefs $DISPLAY, launches megapov and exports $DISPLAY again in
case I want to start a X app from the same console (though logging on
is three keystrokes away :) ).

Perhaps a small set of scripts would be handy? I know many users of
Unix POV-Ray have their own, maybe we could share and include the most
useful ones in the next (un)official release of (Mega)POV?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Francois Dispot <woz### [at] club-internetfr> wrote:
: Maybe a stupid (and selfish ;-) idea: would it be possible to have
: something that would continue running if you log out and shut down the X
: server even if povray was started with X display and without nohup?

  Why code this into povray when you can do it with Unix itself?
  You can use nohup or screen for this.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hey Peter,
if I remember your box right, it doesn't have the X or SVGA libs, right?
Then, as far as I groked Mark, you will compile the no-fancy-display
version, so setting the DISPLAY variable or stuff won't be neccessary.

Axel

Post a reply to this message

On Wed, 28 Jun 2000 15:42:32 +0200, Axel Hecht
<ah### [at] numerikuni-kielde> wrote:

>Hey Peter,
>if I remember your box right, it doesn't have the X or SVGA libs, right?
>Then, as far as I groked Mark, you will compile the no-fancy-display
>version, so setting the DISPLAY variable or stuff won't be neccessary.

It does not have them as it does not need them due to the lack of an
extra monitor. I do however use X apps quite often by means of a
remote X server. You're right, though, the generic unix target suits
me the most.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Tue, 27 Jun 2000 07:51:16 +0300, Peter Popov wrote:
>On Mon, 26 Jun 2000 18:50:35 -0500, Mark Gordon <mtg### [at] mailbagcom>
>wrote:
>
>Perhaps a small set of scripts would be handy? I know many users of
>Unix POV-Ray have their own, maybe we could share and include the most
>useful ones in the next (un)official release of (Mega)POV?
>

Something I really miss from my VMS days is the sequential numbering
of saved files, so that if I'm working on a scene file and save it
it would save it as something like roundabout.pov;0000 and the next
time I save it would write to roundabout.pov;0001 etc if I set my 
directory history to 20 that means that I'll always have the 20 most
recent saves, a simple purge on the commandline will leave me with 
only the most recent files.  I'm sure that in bash it's possible to
write something that will do the same job though the file naming
will be slightly different to the way it is on VMS.  

It'd be good if such a script could be called from pov's command line
to let it usse the most recent for the current render you'd also need
your editor to be able to understand this so maybe it's not going to 
be all that easy to implement.  I'll look into this myself but I don't
promise to be able to come up with anything.  

-- 
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

 12:57am  up 38 min,  2 users,  load average: 1.30, 1.34, 1.13

Post a reply to this message

Steve wrote:
> 
> Something I really miss from my VMS days is the sequential numbering
> of saved files, so that if I'm working on a scene file and save it
> it would save it as something like roundabout.pov;0000 and the next
> time I save it would write to roundabout.pov;0001 etc if I set my
> directory history to 20 that means that I'll always have the 20 most
> recent saves, a simple purge on the commandline will leave me with
> only the most recent files.  I'm sure that in bash it's possible to
> write something that will do the same job though the file naming
> will be slightly different to the way it is on VMS.
> 
> It'd be good if such a script could be called from pov's command line
> to let it usse the most recent for the current render you'd also need
> your editor to be able to understand this so maybe it's not going to
> be all that easy to implement.  I'll look into this myself but I don't
> promise to be able to come up with anything.

Why not use something like RCS (CVS would probably be overkill)? 
Depending on the editor you are using, you could probably configure it
to check in the file every time it saves, and you can easily delete the
archived versions if you decide you don't need them.  Using RCS won't
clutter up your directory with lots of copies of the same file either. 
I haven't used plain RCS recently, but here's some basic tips:

Make a directory called RCS (all in caps) in the directory where you
have your file.

The following command will see if the file filename.pov has changed at
all from the last copy saved, and if so, it will archive it.
ci -l -q -mauto -t-auto filename.pov

To view a list of all the copies which have been archived, use
rlog filename.pov

If you're not already familiar with RCS, take a look at the man pages
for rcs, ci, rlog, and co.  The commands I gave you above should be
enough to get you started though.

Ken

Post a reply to this message

On Thu, 29 Jun 2000 19:30:32 -0700, Ken Cecka wrote:
>
>If you're not already familiar with RCS, take a look at the man pages
>for rcs, ci, rlog, and co.  The commands I gave you above should be
>enough to get you started though.

Thanks Ken I'll look into this, didn't know it existed. 

-- 
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

  8:17am  up 8 days,  7:58,  2 users,  load average: 1.05, 1.13, 1.07

Post a reply to this message

Don't want to start a version control system war here, but I would like
to mention my experience about the subject.
  In the project we are working we used RCS at the very beginning and it
was a real pain in the a** to use it. Every directory have to have its own
RCS directory and trying to share the files with all the other members of
the project was really tedious and difficult. RCS also doesn't allow for more
than one person to modify the files at the same time. You can't have a
local copy of the project, which you can modify and then check in to the
version controlling system, but you have to edit them in a shared file system
(of course you can copy the files to yourself, but since RCS doesn't support
this, it's a pain). The locking of files is tedious because you have to
always remember to unlock the files that others may want to change.
  Then we changed to PRCS. What a heaven! All the directory structure could
be checked in to one single project file. You can have many sub-projects so
that you can work with intermediate versions that do not interfere with the
main version. More than one person can edit the same files at the same time
and PRCS can merge the files afterwards without problems (the problems only
arise if the persons edited the same lines of the files, which should be
avoided, but if they edit different lines, there's no problem at all).
Sharing the files with all the other members is very easy (every member
can have the latest version of all the subprojects with one single checkout).
Every member can have a local copy of the project (or any number of copies
if wished), only the main project file has to be shared. You don't have to
worry about locking and unlocking files; you just edit them and check them
in, that's it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I pretty much agree with your views on RCS.  I don't think I've ever run
into a group who uses RCS on its own for a large project.  I use
Rational's ClearCase at work which is wonderful.  I thought RCS might be
a good choice in this instance based on how Steve described what he
wanted to do.  If you're just working on a project on your own and are
just maintaining revisions of files, it might not be worth the trouble
of learning and setting up a full-blown cvs repository or something
similar.  But lots of options are always good.

Incidentally, what's PRCS?  I've only used ClearCase and CVS (RCS).  Is
it commercial?  CVS seems to be the system of choice at the moment for
opensource development, but there's a lot of functionality it's missing
that ClearCase has which makes life a lot easier.

Ken

Warp wrote:
> 
>   Don't want to start a version control system war here, but I would like
> to mention my experience about the subject.
>   In the project we are working we used RCS at the very beginning and it
> was a real pain in the a** to use it. Every directory have to have its own
> RCS directory and trying to share the files with all the other members of
> the project was really tedious and difficult. RCS also doesn't allow for more
> than one person to modify the files at the same time. You can't have a
> local copy of the project, which you can modify and then check in to the
> version controlling system, but you have to edit them in a shared file system
> (of course you can copy the files to yourself, but since RCS doesn't support
> this, it's a pain). The locking of files is tedious because you have to
> always remember to unlock the files that others may want to change.
>   Then we changed to PRCS. What a heaven! All the directory structure could
> be checked in to one single project file. You can have many sub-projects so
> that you can work with intermediate versions that do not interfere with the
> main version. More than one person can edit the same files at the same time
> and PRCS can merge the files afterwards without problems (the problems only
> arise if the persons edited the same lines of the files, which should be
> avoided, but if they edit different lines, there's no problem at all).
> Sharing the files with all the other members is very easy (every member
> can have the latest version of all the subprojects with one single checkout).
> Every member can have a local copy of the project (or any number of copies
> if wished), only the main project file has to be shared. You don't have to
> worry about locking and unlocking files; you just edit them and check them
> in, that's it.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ken Cecka <cec### [at] alumniwashingtonedu> wrote:
: Incidentally, what's PRCS?

http://www.xcf.berkeley.edu/~jmacd/prcs.html

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thanks to your earlier reply Ken I've got RCS up and running now,
it was a bit confusing at first as I've moved over to emacs at
the same time, and didn't understand how their bookmarks worked and
was opening other files and thinking that they were the same file and
wondering why emacs couldn't find the rcs entry etc etc.  But I've 
got it all sorted out now. 

-- 
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

 11:29pm  up 14 days, 23:10,  2 users,  load average: 1.36, 1.36, 1.25

Post a reply to this message