 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As a result of some discussion on the IMP
technical discussion list, there has been
some preliminary investigation into
supporting TAR archives from POV.
The advantages are:
Minimal POV installation - povray.exe, includes.tar
Modularisation of large pov scenes.
Modularisation of libraries.
Download-and-render without extraction.
Technical Issues
Support compression?
Parsers that use fseek?
I've attached more detailed discussion.
Your comments or interest are invited.
------------------------------------------------------
Date: Tue, 02 Feb 1999 15:15:40 +1100
From: Nigel Stewart <nig### [at] eisa netau>
Subject: Re: [TECH] Proposal - PVA Fileformat Specification
>>> The PVA (PovRay Archive) fileformat is proposed
>>> as a means of modularisation of POV scene
>>> files.
TarFs, ExTar
----------------------------------------------------
TarFs is a C++ class representing a tar archive.
FILE *TarFs::file(char *filename,const char *mode = "rt")
Create a C FILE pointer to read a file from the
tar archive.
istream *TarFs::istream(char *filename,ios_base::openmode mode = ios::in)
Create a C++ input stream object to read a file from
tar archive.
----------------------------------------------------
Extar is a command-line program to extract a file
within tar archive to standard output.
For Example:
C:\Data\Nigel\devel\tarlib>tar cvf test.tar tmp
tmp/
tmp/test.txt
tmp/test2.txt
C:\Data\Nigel\devel\tarlib>extar test.tar
tmp/test.txt
tmp/test2.txt
C:\Data\Nigel\devel\tarlib>extar test.tar tmp/test.txt
Hello World
C:\Data\Nigel\devel\tarlib>
----------------------------------------------------
Applications -
PovRay support for concept of library.
IMP datafile encapsulation.
Game datafile supporting read-only random access.
Email datafile supporting arbitrary append.
Virtual read-only filesystem for Linux.
Tar archive browsing for WWW. (CGI ExTar)
-------------------------------------------------------------------------
Date: Thu, 04 Feb 1999 01:17:49 +1100
From: Nigel Stewart <nig### [at] eisanetau>
Subject: [TECH] POV Support for TAR Filesystem
I had a quick-hack attempt at supporting tar
files from POV-ray. It works nicely, except
for TTF fonts, which are parsed using fseek. (**)
POV, INC and PNG files within tar files have
worked without a hitch.
What does all this mean?
Well, it means that a 'minimalist' POV install
is one .exe file, plus one .tar file with all
the include files. There is no dependency on
environment variables, or registry settings
to find libraries - which makes it easy to
install, zero configuration, and no
interaction with other POV installations.
Also, a renderfarmer only needs to download
ONE tar archive into the directory to
start rendering. (Plus a command line,
which can be in the TAR as well...)
So, my conclusion is that having a custom
IMP POV compilation is feasible, has real
advantages, (we can use any patches that we
like) and is likely to have minimal impact
on render farmers. It is also very portable.
My 0.02 for today.
(Oh, and hacking around in the POV source
is pretty educational/interesting too!)
(**) TarLib provides a file pointer
offset to the correct location in
the TAR file, but using fseek
can depend on offset zero being
at the start of the file, rather
than start of Tar file.
---------------------------------
| | scene.pov | ...
----------------------------------
^
\ beginning of "scene.pov"
^
\ fseek is relative to tar file
--------------------------------------------------------------------
Date: Thu, 04 Feb 1999 20:54:29 +1100
From: Nigel Stewart <nig### [at] eisanetau>
Subject: Re: [TECH] POV Support for TAR Filesystem
TAR Files
---------
Generic. Tar has a long history, is well supported,
and well understood. The actual format of
the headers are weird, but proven.
Simple. Tar is a "chunked" format, files are stored
contiguously and uncompressed.
Compression
-----------
Directly supporting compressed archives is undesirable
in terms of simplicity and efficency. Fancy languages
like Java or C++ allow you filter streams, so that
decompression is hidden from the parser. I do not
know of a clean and efficient way of doing this in
C. (Either parse from memory buffer, or extract file
to temporary directory on the fly).
Also, it's worth considering that POV already supports
compressed files such as PNG.
Also, do we want to spend CPU time on decompression
for every frame of animation?
Also, would it more appropriate to support POV parsing
of .pov.gz (".pgz") or .inc.gz (".igz"), independent
of tar file support?
In summary - We can do it, but do we WANT to do it?
Portability of JAR
-------------------
JAR is portable in the sense that it works on any
Java supported platform. TAR is portable in the
sense that things like WINZIP support it. My
impression is that the average raytracer is going
to be equally unfamiliar with TAR and JAR.
If compression is appropriate to the application,
let's use JAR. However, I do not think there
will be a good return on the investment of time
and energy.
Perhaps there is someone from the broader
POV community who would do the work on
zlib-based compression. Would anyone
object to making a report to pov.programming?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> As a result of some discussion on the IMP
> technical discussion list, there has been
> some preliminary investigation into
> supporting TAR archives from POV.
>
>
>
> Portability of JAR
> -------------------
>
> JAR is portable in the sense that it works on any
> Java supported platform. TAR is portable in the
> sense that things like WINZIP support it. My
> impression is that the average raytracer is going
> to be equally unfamiliar with TAR and JAR.
>
> If compression is appropriate to the application,
> let's use JAR. However, I do not think there
> will be a good return on the investment of time
> and energy.
>
> Perhaps there is someone from the broader
> POV community who would do the work on
> zlib-based compression. Would anyone
> object to making a report to pov.programming?
Just to help clarify things a little, JAR files are mainly just ZIP files
that are constrained not to use the patented compression. They only use the
zlib compression (which happens to be included in POV-Ray already). Thus any
JAR file is a valid ZIP file, and can be created and accessed with standard
tools.
To further help things, although there is no RFC or such on .ZIP files, but
PKWare does have an application note describing the format.
See http://www.pkware.com/appnote.html
Just use that along with the info on the JAR format itself:
http://java.sun.com/products/jdk/1.2/docs/guide/jar/index.html
One issue to note is the manifest file that is optionally present.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I guess I missed something. For the most part I don't see the point.
There are shell-out calls that you can use for this stuff in your ini
files. I do it all the time for animations. Most of what you described
can be done with pre- and -post -frame and -scene commands.
The cool thing is the idea of putting all the standard .inc files, etc.
into
one big file (kinda like a library file?) But then you'd either have to
have
a double call (#include "textures.inc" from pov_official.jar vs.
#include "cooltext.inc" from funky_stuff.jar) or else still have a
library path
type thing, only make it intelligent enough to search through all the
.jar's,
tar's, tgz's, tar.gz's, tar.bz2's, .zip's and God knows what else people
might
come up with that is public domain.
It seems that most of what you want is already there with the
shell-outs, and
people can use whatever they have on their system that way.
But then, I've probably missed the point, as I often do.
My 2 Canadian cents worth.
--
Carl Bartels, Department of Chemistry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I guess I missed something. For the most part I don't see the point.
Okay, here are the major advantages:
* Totally portable file-names, time/date, integrity checking.
* Easier management for 3rd party modules.
* Ability to take a fully-functional pov source snap-shot.
* Simpler installation, less registry/variable dependence. (*)
The filename resolution issue is not yet resolved.
At the moment, POV simply looks in the current
directory and treats each tar file as an entry in
the library path. This might not be the best policy -
I'm still thinking about it... The intention is to support
this transparently - it should make no difference
if you are rendering from a real filesystem or a
tar filesystem.
Compression is under consideration - Pov already
includes the zlib library, so gzip or JAR support would
not introduce much new code. My feeling is that
a case needs to be made for the parse-time expense
vs. space savings. Also, it might be cleaner to support
compressed pov/inc as preferrable to compressing an
entire archive.
(*) I'm considering a way to include the standard includes
and a few test scenes into the povray binary, so that the
minimal povray install is one file. Copy-and-run. Delete to
uninstall. (Life should always be so simple.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I did miss something. sorry.
Nigel Stewart wrote:
>
> Okay, here are the major advantages:
>
> * Totally portable file-names, time/date, integrity checking.
This would be great.
> * Easier management for 3rd party modules.
> * Ability to take a fully-functional pov source snap-shot.
> * Simpler installation, less registry/variable dependence. (*)
I'm tempted to start a flame war but won't. Lets just say that I
strongly agree with any move to reduce the use (direct or indirect) of
registry files Regedit on the few occasions when I do boot my computer
into Windows. Of course, .rc files can be a pain on Linux too.
> The filename resolution issue is not yet resolved.
> At the moment, POV simply looks in the current
> directory and treats each tar file as an entry in
> the library path. This might not be the best policy -
> I'm still thinking about it... The intention is to support
> this transparently - it should make no difference
> if you are rendering from a real filesystem or a
> tar filesystem.
OK. If you tar a directory tree, do the subdirectory levels get
searched. If so, are they treated as subdirs? Here's what I mean...
You want to make a tar of a whole tree you've made and nicely organized
that looks like this:
/include
/include/incs
/include/pots
/include/maps
/include/maps/hot
/include/maps/cold
/include/ttfs
/include/df3s
Would a file in /include/maps/hot be treated as being in a subdirectory
of a subdirectory or would it just get treated as a file with /'s in
it's name? I'd advocate the later. It may sound nuts to have subdirs
in a library tar like that, but I'm sure someone will try it.
BTW, how does tar (gpl'd I think) get along with POV license-wise?
> Compression is under consideration - Pov already
> includes the zlib library, so gzip or JAR support would
> not introduce much new code. My feeling is that
> a case needs to be made for the parse-time expense
> vs. space savings. Also, it might be cleaner to support
> compressed pov/inc as preferrable to compressing an
> entire archive.
There was an earlier thred about making a binary file format of parsed
scenes. It would be kinda cool if that goes of to put parsed .inc files
into the tar. That way, you kill a whole pile of parse time for anyone
who includes a lot of stuff from these.
Three more potential problems...
1) Documentation: If all the includes come as one big tar (or
whatever) file, then people won't be able to peruse them the way they
can now so a whole new pile of documentation will have to made available
stating what's in each include file. (Big PITA when it comes to stuff
like shapes.inc) It may require some sort of standardization of the
include files. (I'd be willing to volunteer for that). Personally, I
don't use the standard includes much anymore, but they were an
increadable help when I was learning back on POV 2.whateveritwas. The
loss of the ability to see their guts would be a big blow to new users.
2) Home-brews: There'd have to be some sort of utility (hardwired into
POV or released separately) so that people could make their own
modules. And of course, it would have to work on several platforms.
3) Conflicts: Suppose you define Big_red_texture in one .inc file and
then redefine it in another one later. You then put both of them in the
tar. Depending on how you do file resolution this could confuse either
pov or the user (either pov will freak, or else 50% of the time the user
will not get what they wanted because it took Big_red_texture from the
other .inc)
Well, now that I've said all that...I like the idea afterall. If you
want someone else to test a patch on Linux, let me know.
Cheers!
--
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 09 Feb 1999 19:12:44 -0500, Carl Bartels
<cab### [at] bravo436chemmcgillca> wrote:
>BTW, how does tar (gpl'd I think) get along with POV license-wise?
GPL doesn't get along well with POV at all. GLPL looks like it might
be compatible. But IIRC, the idea was to start with the documentation
for the tar file format and go from there, not using any preexisting
code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>BTW, how does tar (gpl'd I think) get along with POV license-wise?
As Ron Parker suggests, TAR is simple enough that the parsing code
is pretty simple. My licencing terms are even lefter than GPL - basically
no restrictions at all - Pov team can treat my work as they see fit.
I've used C++, which may be an issue - But I'm working in a
experimental/prototype mindset - I'll surrender STL only
for a real good reason.. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The filename resolution issue is not yet resolved.
>
>OK. If you tar a directory tree, do the subdirectory levels get
>searched. If so, are they treated as subdirs?
Yes, as it stands, subdirectories are treated properly.
For example, I've bundled the Galaxy include file
into a tar:
N:\devel\Pov31b>tar tvf galaxy.tar
drwxrwxrwx 0/0 0 Feb 07 00:56 1999 galaxy/
-rw-rw-rw- 0/0 2242 Aug 09 00:00 1998 galaxy/AllObjs.pov
-rw-rw-rw- 0/0 885 Aug 09 00:00 1998 galaxy/DnmcOpts.pov
-rw-rw-rw- 0/0 11395 Aug 09 00:00 1998 galaxy/GALAXY.BG
-rw-rw-rw- 0/0 42412 Aug 09 00:00 1998 galaxy/Galaxy.htm
-rw-rw-rw- 0/0 9780 Feb 05 14:51 1999 galaxy/GALAXY.INC
-rw-rw-rw- 0/0 35742 Aug 09 00:00 1998 galaxy/GALAXY.OBJ
-rw-rw-rw- 0/0 3884 Aug 09 00:00 1998 galaxy/GALAXY.SF
-rw-rw-rw- 0/0 1025 Feb 07 00:58 1999 galaxy/Rand.ini
-rw-rw-rw- 0/0 339 Feb 07 00:21 1999 galaxy/Rand.pov
-rw-rw-rw- 0/0 1048 Aug 09 00:00 1998 galaxy/Readme.txt
-rw-rw-rw- 0/0 1481 Aug 09 00:00 1998 galaxy/Trifid.pov
From the command line:
povray +Igalaxy/Trifid.pov +w630 +h480 +OTrifid
There is a bit of a catch though, to put files in a subdirectory,
each pov/inc needs to look for "galaxy/galaxy.inc" rather than
just for "galaxy.inc". It's my thought that POV should also
search the directory of the _current file_ to more easily
support this kind of modularisation.
>1) Documentation: If all the includes come as one big tar (or
>whatever) file, then people won't be able to peruse them the way they
>can
Yes I agree this is a draw-back. You can browse the tar with
Winzip.... But what would be really nice would be a hyperlinked
and indexed version of the standard includes, as HTML or
windows HLP. It makes me grumpy to search for the include
directory in windows, and a man page or java-doc style solution
would be much more useful. (And complement the
existing documentation very nicely)
>2) Home-brews: There'd have to be some sort of utility (hardwired into
>POV or released separately) so that people could make their own
>modules. And of course, it would have to work on several platforms.
Any port of command-line tar will. It's not a job
we need to worry about.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nigel Stewart" <nigels> wrote:
: There is a bit of a catch though, to put files in a subdirectory,
: each pov/inc needs to look for "galaxy/galaxy.inc" rather than
: just for "galaxy.inc". It's my thought that POV should also
: search the directory of the _current file_ to more easily
: support this kind of modularisation.
Section 6.2.3.2
Library Paths
Library_Path=path Add path to list of library paths
+Lpath Same as Library_Path=path
POV-Ray looks for files in the current directory. If it does not find a
file it needs it looks in various other library directories which you
specify. POV-Ray does not search your operating system path. It
only searches the current directory and directories which you
specify with this option. For example the standard include files are
usually kept in one special directory. You tell POV-Ray to look
there with...
Library_Path=c:\povray3\include
You must not specify any final path separators ("\" or "/") at the end.
Multiple uses of this option switch do not override previous
settings. Up to ten unique paths may be specified. If you specify the
exact same path twice it is only counts once. The current directory
will be searched first followed by the indicated library directories in
the order in which you specified them.
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11 Feb 1999 15:06:30 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>"Nigel Stewart" <nigels> wrote:
>: There is a bit of a catch though, to put files in a subdirectory,
>: each pov/inc needs to look for "galaxy/galaxy.inc" rather than
>: just for "galaxy.inc". It's my thought that POV should also
>: search the directory of the _current file_ to more easily
>: support this kind of modularisation.
>
>POV-Ray looks for files in the current directory. If it does not find a
>file it needs it looks in various other library directories which you
>specify.
There's a difference between "directory of the current file" and
"current directory". If I have this directory structure:
.:
-rw------- foo.pov
drwx------ Includes/
Includes:
-rw------- bar.inc
-rw------- baz.inc
and foo.pov #includes "Includes/bar.inc" and bar.inc #includes
"baz.inc", it would be nice if POV would first look in the
directory in which bar.inc resides (i.e. ./Includes/) when looking
for baz.inc. I believe this is how my C compiler does it, except
that it probably doesn't look in ./ at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>There's a difference between "directory of the current file" and
>"current directory".
Yes, that is exactly what I'm talking about. POV currently
has a policy that everything should be in the library include
path, but if you have a filename collision, the resolution
strategy is not well defined. I think using
#include "std/colors.inc"
#include "foo/colors.inc"
Is better than being careful to name files carefully to avoid
collision. Files included from "std/colors.inc" should be
taken from the "std" directory in preference to anywhere
else. This improves the prospect of proper modularisation
of POV scenes and libraries.
I don't think C works this way, but I think it is the way
that POV-ray _should_ work... :-)
In order of preference, POV searches the following
directories for an included file:
1. The directory of the current file.
2. The current directory.
3. Each directory in the list of library directories.
Which is the same policy as present, with (1) inserted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here is an example run of povray on Windows NT,
using tar filesystems, and determining the
complete dependency set of the scene. You can
see some recent screen shots on:
http://www.imp.org/members/scene/test_a/scripta.html
-------------------------------------------
bash-2.02$ ls *.tar
galaxy.tar planets.tar planetss.tar spline.tar
include.tar planetsl.tar scenes.tar
bash-2.02$ ls *.exe
ExTar.exe Pal2PovColour.exe PovRay.exe PovRayD.exe
bash-2.02$ nice ./povray -Iscripta
Persistence of Vision(tm) Ray Tracer Version 3.1a.unsupported
Unofficial version compiled by:
Nigel Stewart (nig### [at] eisanetau)
The POV-Ray Team(tm) is not responsible for supporting this version.
Copyright 1998 POV-Ray Team(tm)
[snip]
Parsing.........
[snip]
Rendering...
[snip]
Dependencies:
------------------------------------------------------
ScriptA.spl
SolarSys.inc
colors.inc
galaxy/GALAXY.BG
galaxy/GALAXY.OBJ
galaxy/GALAXY.SF
milkyway.inc
planets/EthMapS.png
planets/JupMapS.png
planets/MarMapS.png
planets/MerMapS.png
planets/MooMapS.png
planets/NepMapS.png
planets/PluMapS.png
planets/SatMapS.png
planets/UraMapS.png
planets/VenCldS.png
planets/VenMapS.png
planets/planets.inc
scripta.pov
skies.inc
spline/Spline.inc
title2.inc
------------------------------------------------------
Reclaiming memory
bash-2.02$
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is now a web-page describing "Imp Pov", a povray 3.1
compilation with a few extra features for network rendering.
http://www.imp.org/members/tech/rcast/rcast.html
Binaries for Win32 and Linux are available.
Features:
* Passive render-farm mode "+N" for rendering farming
The network rendering mode waits for configuration files in INI
format to be placed in the incoming directory. Outputs are placed
in the outgoing directory.
* TAR file as read-only file-system
Packing scene files into a TAR archive allows long filenames, and
case sensitive filenames across every platform. It also simplifies
scene distribution, and allows modules to be packaged and
distributed conveniently.
* Automatic scene dependency reporting
Pov-ray will report the set of files required to render a scene.
Ultimately, this feature will be developed to provide render
farmers with the minimal set of files required for a each frame of
animation.
* Command-line interface
No user interface is included for the sake of portability. It
should be simple to layer a GUI on top of the network rendering
mode, by manipulating the file queues and writing some state
information to a file from povray.
* Different directory searching policy
Currently, pov requires every directory to be included in the
library search path in order to find include files. IMP POV
implements a 'relative to current file' search, so that files in
the same directory as the current one are found first. This means
you can include a module using an absolute path: #include
"galaxy/galaxy.inc" and files it depends on this will be expected
in the galaxy directory.
This reduces the amount of library configuration, and also reduces
the chances that included filenames will collide. (For example, a
local "colors.inc" vs the global "colors.inc")
--
Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is now a web-page describing "Imp Pov", a povray 3.1
compilation with a few extra features for network rendering.
http://www.imp.org/members/tech/rcast/rcast.html
Binaries for Win32 and Linux are available.
Features:
* Passive render-farm mode "+N" for rendering farming
The network rendering mode waits for configuration files in INI
format to be placed in the incoming directory. Outputs are placed
in the outgoing directory.
* TAR file as read-only file-system
Packing scene files into a TAR archive allows long filenames, and
case sensitive filenames across every platform. It also simplifies
scene distribution, and allows modules to be packaged and
distributed conveniently.
* Automatic scene dependency reporting
Pov-ray will report the set of files required to render a scene.
Ultimately, this feature will be developed to provide render
farmers with the minimal set of files required for a each frame of
animation.
* Command-line interface
No user interface is included for the sake of portability. It
should be simple to layer a GUI on top of the network rendering
mode, by manipulating the file queues and writing some state
information to a file from povray.
* Different directory searching policy
Currently, pov requires every directory to be included in the
library search path in order to find include files. IMP POV
implements a 'relative to current file' search, so that files in
the same directory as the current one are found first. This means
you can include a module using an absolute path: #include
"galaxy/galaxy.inc" and files it depends on this will be expected
in the galaxy directory.
This reduces the amount of library configuration, and also reduces
the chances that included filenames will collide. (For example, a
local "colors.inc" vs the global "colors.inc")
--
Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Um, Nigel, sir? Did you forget this needs a ID and password to get in?
Or did you realize that when you posted this URL...? ;)
Nigel Stewart wrote:
>
> There is now a web-page describing "Imp Pov", a povray 3.1
> compilation with a few extra features for network rendering.
>
> http://www.imp.org/members/tech/rcast/rcast.html
>
> Binaries for Win32 and Linux are available.
>
> Features:
>
> * Passive render-farm mode "+N" for rendering farming
> The network rendering mode waits for configuration files in INI
> format to be placed in the incoming directory. Outputs are placed
> in the outgoing directory.
> * TAR file as read-only file-system
> Packing scene files into a TAR archive allows long filenames, and
> case sensitive filenames across every platform. It also simplifies
> scene distribution, and allows modules to be packaged and
> distributed conveniently.
> * Automatic scene dependency reporting
> Pov-ray will report the set of files required to render a scene.
> Ultimately, this feature will be developed to provide render
> farmers with the minimal set of files required for a each frame of
> animation.
> * Command-line interface
> No user interface is included for the sake of portability. It
> should be simple to layer a GUI on top of the network rendering
> mode, by manipulating the file queues and writing some state
> information to a file from povray.
> * Different directory searching policy
> Currently, pov requires every directory to be included in the
> library search path in order to find include files. IMP POV
> implements a 'relative to current file' search, so that files in
> the same directory as the current one are found first. This means
> you can include a module using an absolute path: #include
> "galaxy/galaxy.inc" and files it depends on this will be expected
> in the galaxy directory.
> This reduces the amount of library configuration, and also reduces
> the chances that included filenames will collide. (For example, a
> local "colors.inc" vs the global "colors.inc")
>
>
> --
> Nigel Stewart (nig### [at] eisanetau) http://www.eisa.net.au/~nigels/
> Postgrad Research Student, RMIT University, Melbourne, Australia
> All extremists should be taken out and shot.
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aolcom?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Carl Bartels wrote:
> type thing, only make it intelligent enough to search through all the
> .jar's,
> tar's, tgz's, tar.gz's, tar.bz2's, .zip's and God knows what else people
AFAIK future zlibs will understand .bz2.
IIRC the tar interface (which I don't know) would just have
to call "gzopen" instead of "open", the [de]compression would
then happen transparently. I have no idea whether zlib provides
all the other stream-related functions that the tar interface
needs.
I'd say that .jar and .zip are not necessary - just tell the users
with nonstandard machines how to get and install tar and gzip.
Non-programmers on PCs might be happier with winzip, which can
only extract tar, but not create it - but this is not a problem
for them.
Besides, pkzip is only shareware, not completely free, which might
cause legal problems in strange circumstances.
I'm not aware about the legal status of .jar.
I'd keep the #include statements as they are, and have them
search unpacked files first, then look into archives (this way
users can unpack single files, modify them and have them used
automatically).
Another possibility would be a syntax like
#include "[includes]/metals.inc"
where [includes] means to look for a file includes.tar
or includes.tar.gz and find /metals.inc inside of that.
(I intentionally wrote [includes], not [includes.tar]
in order to have this resolved automatically).
To save space, I add an answer to some more postings of
this thread here as well:
> 1) Documentation: If all the includes come as one big tar (or
> whatever) file, then people won't be able to peruse them the way they
> can now so a whole new pile of documentation will have to made available
> stating what's in each include file.
Since everybody is supposed to have tar and gzip installed on
his machine, he can unpack the individual files. This also solves
the second topic (Home-brews).
Definition conflicts are a problem already now - somebody
recently reported funny effects when including both golds.inc
and metals.inc (which define slightly different things with the
same name).
CPU time needed for decompression is IMHO not a problem:
People with slow machines can decompress them manually
and use a big includes.tar instead of a small includes.tar.gz.
I'd leave the decision to the user.
Ralf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ralf Muschall wrote:
> Carl Bartels wrote:
>
> > type thing, only make it intelligent enough to search through all the
> > .jar's,
> > tar's, tgz's, tar.gz's, tar.bz2's, .zip's and God knows what else people
>
> AFAIK future zlibs will understand .bz2.
>
> IIRC the tar interface (which I don't know) would just have
> to call "gzopen" instead of "open", the [de]compression would
> then happen transparently. I have no idea whether zlib provides
> all the other stream-related functions that the tar interface
> needs.
>
> I'd say that .jar and .zip are not necessary - just tell the users
> with nonstandard machines how to get and install tar and gzip.
> Non-programmers on PCs might be happier with winzip, which can
> only extract tar, but not create it - but this is not a problem
> for them.
>
> Besides, pkzip is only shareware, not completely free, which might
> cause legal problems in strange circumstances.
> I'm not aware about the legal status of .jar.
Yes, but there are completely free implementations of .zip file handlers.
.jar files are open. They just take the .zip format, add an optional file
(manifest.mf), and specify that you can only use the non-patented compression
(thus avoiding legal issues). Any valid .jar file is a valid .zip file.
BTW, tar on Windows platforms (especially winzip) can cause big headaches
with EOL conversions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz wrote:
> Ralf Muschall wrote:
> BTW, tar on Windows platforms (especially winzip) can cause big headaches
> with EOL conversions.
Agreed, but this only requires POVray to understand the EOLs of the
other system. Hackers who want to edit the manually extracted files
will probably be able to say something like :%s/^V^M// or M-% C-q C-m
in their editor.
Thats also why I think it is not necessary to care much about the
existence of tar.exe, gzip.exe etc. on DOSen or MACs - non-hackers
simply won't need it (since povray does all the work), hackers will
know how to obtain it, and the GPL absolutely excludes any kind of
legal hassles that might occur with other archivers (except .zip and
.jar, as I learned from your response).
Ralf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ralf Muschall wrote:
> Jon A. Cruz wrote:
> > Ralf Muschall wrote:
>
> > BTW, tar on Windows platforms (especially winzip) can cause big headaches
> > with EOL conversions.
>
> Agreed, but this only requires POVray to understand the EOLs of the
> other system. Hackers who want to edit the manually extracted files
> will probably be able to say something like :%s/^V^M// or M-% C-q C-m
> in their editor.
But there are some other problems. Such as Windows versions of tools doing
automatic EOL conversion as a default, and on files that it should not be
doing it to (I've had problems with .BMP files extracted from a tar before).
Once you've done EOL conversions on a binary, kiss the 'restore' goodbye.
Mangling textures for renderings is not a nice thing.
Not that I'm saying this is likely to cause widespread massive riots, but it
does exist and should be considered.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
