Sherry Shaw wrote:

> I wonder if some sort of generic unit conversion code might be posted on 
> the site, to allow coders to use the units they find most appropriate, 
> while simplifying end-users' ability to mix-and-match #include files...?

I tried to whip up a set of macros which allow a model designer to 
specify what units they're using, and another set which allows the scene 
designer to specify the units for the scene.  The two macros would work 
together to properly scale the object for the scene.

But making it sufficiently idiot-proof was too cumbersome, so I 
abandoned it to make time for playing Diablo.

Regards,
John

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Re: CSG fonts

A brief update:
I released an improved (streamlined) version of my CSG Fonts standards
package.  To see it, please go to:

http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.456ff0468ffcc40c7cac52a50%40news.povray.org%3E/

Posting #6

Thank you,
-Randall

Post a reply to this message

Usage Protocol

Chris Cason wrote:
> Recall I mentioned changes to SDL are possible.

John VanSickle wrote:
> Keeping it simple is a must.
>
> Namespaces are probably the best way.  Ideas:
>
> * #namespace LABEL creates the namespace LABEL if it doesn't already
> exist.
.......

Would it be helpful to establish a way to view the 'usage text' of a macro
without having to load its entire include file into an editor?

One solution would be to require a

    #declare foo_usage = 'string literal'
        for each
    #macro foo( 'parameters' )

in every standardized include.
One draw-back to this approach though, is the current 256-character limit.

Some sort of 'usage protocol' would be helpful in the development of
specialized POV-Ray editors too.

Post a reply to this message

Randall Sawyer wrote:
> Would it be helpful to establish a way to view the 'usage text' of a macro
> without having to load its entire include file into an editor?
> 
> One solution would be to require a
> 
>     #declare foo_usage = 'string literal'
>         for each
>     #macro foo( 'parameters' )

A better solution (and avoiding the 256 character limit) is a simple

#declare help = true; // uncomment this to print help text
// #declare help = false; // uncomment this to suppress help text

in the main file.  Then, in your include files, do a

#if (help=true)
  #debug "Macro: make_widgets(PIPES, CHRONOTRONS) by Chris O'Donnell.\n"
  #debug "Usage:\n"
  #debug " PIPES should be a vector representing the color of the 
widgets.\n"
  #debug " CHRONOTRONS should be a string literal to be printed in the 
uppper left corner of the screen.\n"
#end

Or something along these lines, customized for each macro :)

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> #declare help = true; // uncomment this to print help text
> // #declare help = false; // uncomment this to suppress help text

Nice :)

I have something specific in mind though...

I'll post a new thread, since I think I'm about to go a little off-point
from this discussion.  I'll call it "POV Editors".

-Randall

Post a reply to this message

Randall Sawyer wrote:
> Would it be helpful to establish a way to view the 'usage text' of a macro
> without having to load its entire include file into an editor?
> 
> One solution would be to require a
> 
>     #declare foo_usage = 'string literal'

Have a look at perl .pm files. they use a special form of markup to make the
documentation. e.g.

  http://world.std.com/~swmcd/steven/perl/module_pod.html

real-world example:

  http://search.cpan.org/src/WADG/GD-Graph3d-0.63/lib/GD/Graph3d.pm

It also handles things such as dependencies etc. In POV there's no reason why
we could not use specially-formatted comments. (This is already regular
practice for C++, with various docgen tools helping to fill it out).

if a similar system was in place with POV, there's no reason why a POV editor
can't pick up the info automatically and show help for a macro (particularly
when typing in the definition to use it).

-- Chris

Post a reply to this message

John VanSickle wrote:
> * #namespace LABEL creates the namespace LABEL if it doesn't already 
> exist.  Whether new or not, namespace LABEL becomes the active namespace 
> (the former namespace is saved on a stack).
> 
> * #namespace undef pops the current namespace off of the stack, and the 
> former namespace becomes active.
> 
> * All #declare and #local statements affect the variable in the current 
> namespace.  Other variables of the same name in other namespaces are not 
> affected.

my personal opinion is that namespaces should have block scope (so are
delimited by a specific start and end, either with braces or a # declaration
of some sort). preferably with braces.

also namespaces must be properly nested within a source file; if you open a
namespace in a file, it must be closed before EOF in that file. otherwise you
run the risk of loading a include file and finding the current namespace has
changed afterwards.

finally, if we're going to change the way macros work with respect to scope,
we're better off changing them entirely (otherwise we run into compatibility
issues) and coming up with a new name for them (i.e. not #macro).

-- Chris

Post a reply to this message

my 2 cents:

We should not forget povray is heavily used by non-programmers and adding
more stuff -- like more syntax items or heavy-handed standards -- may put
some of these people down...

The main problem is naming collisions.  This problem may not even require
adding more syntax, but just handle the #include more gracefully -- perhaps
as a rewrite rule indeed.

Today, when I #include a file, its declarations may conflict with previous
ones.  When such a thing happens, povray should *warn* the user and suggest
using an alias for the included file and access its contents via the alias.

i.e., supposing both includes declare a make_bike:

#include "nem_bike.inc" #as nem // bike by nemesis
#include "jvs_bike.inc" #as jvs // bike by John VanSickle

object { nem_make_bike() translate -x*5*m }
object { jvs_make_bike() translate x*3*m }

If #as isn't used, it behaves just like regular #include... of course,
include files in the include files repository could be preprocessed like
that to make the uniquely prefixed by the author's login initials...

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:

> We should not forget povray is heavily used by non-programmers and adding
> more stuff -- like more syntax items or heavy-handed standards -- may put
> some of these people down...

I think I've got it!

In our ini files, each of us has default settings for variously-leveled
parameters:
image resolution, render quality, antialias tolerance, etc.

Why not have a tiered system whereby each user can establish how strictly or
loosely they want there includes governed?

Then, when the collection is up-and-running, the subgroups in the collection
could reflect the include regulator levels in the ini file.

If someone with strict standards really wanted to use something from a more
casual source, then it's caveat emptor.

Also, I think that the "#include ... #as" idea is more dynamic and flexible
than the #namespace approach.

-Randall

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Today, when I #include a file, its declarations may conflict with previous
> ones.  When such a thing happens, povray should *warn* the user and suggest
> using an alias for the included file and access its contents via the alias.
>

My worry would be about files that are expecting to see a global variable by
one name and get the prefixed version instead.  It seems like the scope of
#as would have to cover any files that the #included file depends on.

Charles

Post a reply to this message