Some times (or better: many many times) I use an include file or a macro
(mainly those made by Colefax :) ) and I set parameters for it by #declaring
identifiers but I make a typing mistake (like typing Deform_Mesh or
defor_mesh or whatever instead of deform_mesh) and then I wonder why it
doesn't work. Then I have to search through all the 30 #declares to
see if one of them is incorrect.
  Wouldn't it be nice to have a warning option in povray just like in
most C (or whatever language) compilers? This option would turn on
warnings of the type "Identifier declared but never used" and I would
immediatly see if I mistyped an identifier.
  Of course there's one big problem with this: If you include, for
example, colors.inc, you will get a few warnings...
  There should be a way to exclude parts of the code from being tested
for this kind of warnings. Something like this:

#no_warnings
#include "colors.inc"
#include "textures.inc"
#end

#include "coolmacro.inc"
...

  The warning code could also test other things. It would be nice to see
warning messages like:

Warning: CSG object has coincident surfaces.
Warning: The output image file is used in image_map
etc...

-- 
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

Nieminen Mika wrote:
> 
>   Some times (or better: many many times) I use an include file or a macro
> (mainly those made by Colefax :) ) and I set parameters for it by #declaring
> identifiers but I make a typing mistake (like typing Deform_Mesh or
> defor_mesh or whatever instead of deform_mesh) and then I wonder why it
> doesn't work. Then I have to search through all the 30 #declares to
> see if one of them is incorrect.

  This may not be germain to your observations and desired behavior but
I will share this with you. I stopped making a lot of repetitave typing
mistakes in pov the day I learned how to record macros in the new editor.
It has been a real saver for me in both the ease of declaring commonly
used statements as well as not having to find my fumbling mistakes. It has
a reasonably large buffer and I would not choose to be without it now that
I have learned to use it.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

I guess you're on a UNIX version. On the Mac, the includes are added through a
menu so there is no typing. New includes are added to the menu. This cures the
typo prob for the includes.

Also, on the Mac, we can link an external text editor to the regular POV Mac
Unofficial editor. BBEdit supports keyword color coding and custom dictionaries
and can check hundreds of separate text files at once. I have special
preferrences saved in BBEdit to check large POVscripts and collections of
includes for typos. BBEDit then uses the POV raytracer accessed through an
AppleEvent command set. POV has an extremely limited aete resource to allow
external control but the Unofficial team is adding the support. When this is
achieved, I'll probably just use the high ocatane BBEdit all the time with
POV-Ray functioning like a plug-in.

It would be very nice if POV supported color keyword custom dictionaries
directly. Maybe my C++ education will progress to the point that I can do it
someday.

The coincident surface warning is a good one. It doesn't seem very difficult to
test for the condition. Testing for unused includes doesn't appear too
difficult, either.

steve


Nieminen Mika wrote:

>   Some times (or better: many many times) I use an include file or a macro
> (mainly those made by Colefax :) ) and I set parameters for it by #declaring
> identifiers but I make a typing mistake (like typing Deform_Mesh or
> defor_mesh or whatever instead of deform_mesh) and then I wonder why it
> doesn't work. Then I have to search through all the 30 #declares to
> see if one of them is incorrect.
>   Wouldn't it be nice to have a warning option in povray just like in
> most C (or whatever language) compilers? This option would turn on
> warnings of the type "Identifier declared but never used" and I would
> immediatly see if I mistyped an identifier.
>   Of course there's one big problem with this: If you include, for
> example, colors.inc, you will get a few warnings...
>   There should be a way to exclude parts of the code from being tested
> for this kind of warnings. Something like this:
>
> #no_warnings
> #include "colors.inc"
> #include "textures.inc"
> #end
>
> #include "coolmacro.inc"
> ...
>
>   The warning code could also test other things. It would be nice to see
> warning messages like:
>
> Warning: CSG object has coincident surfaces.
> Warning: The output image file is used in image_map
> etc...
>
> --
> 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

Steve <ste### [at] puzzlecraftcom> wrote:
: I guess you're on a UNIX version. On the Mac, the includes are added through a
: menu so there is no typing.

  I don't understand how can this help to correct typing mistakes in
#declared identifiers.

-- 
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

On Sun, 18 Apr 1999 05:29:06 -0600, Steve <ste### [at] puzzlecraftcom>
wrote:

>The coincident surface warning is a good one. It doesn't seem very difficult to
>test for the condition.

Unfortunately, it is in fact quite difficult to test for that
condition.  It'd be easier to fix the code so coincident surfaces
weren't a problem any more, but even that doesn't look too easy.  I
posted some observations on a possible fix some time ago, if anyone
cares to look.

Post a reply to this message

The second part of my message explains the workaround to this specific problem -
custom dictionaries and color coded keywords in an external text editor plus adding
the keyword from a custom menu.

I use 3 of the Colefax macros quite a lot. I have added my keywords to the BBEdit
dictionary, color coded them and added them to a menu. I can then insert the
keywords by 1) typing it in and seeing if it is the right color, 2) selecting it
from a menu with the mouse, 3) adding it with an assigned keystroke.

My POVscripts are written in BBEdit which then uses the POV-Ray debugger and
raytracer.

I don't know first hand, but I'm pretty sure that UNIX has customizeable text
editors similar to BBEdit. BBEdit is used for authoring C, C++, PASCAL, JAVA, HTML,
AppleScript, PERL. etc. Setting it up for POVscript is pretty easy. The only
shortcoming is BBEdit does not have a built-in debugger for POVscript similar to
the debugger support for the other scripting/programming languages.

Of course, it would valuable to be able to accomplish the color keywording and
custom dictionaries directly in POV.

steve



Nieminen Mika wrote:

> Steve <ste### [at] puzzlecraftcom> wrote:
> : I guess you're on a UNIX version. On the Mac, the includes are added through a
> : menu so there is no typing.
>
>   I don't understand how can this help to correct typing mistakes in
> #declared identifiers.
>
> --
> 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

Steve wrote:
> 
> The second part of my message explains the workaround to this specific problem -
> custom dictionaries and color coded keywords in an external text editor plus adding
> the keyword from a custom menu.

  Fortunatly for the windows users of the program the new CodeMax editor
has program language specific color syntax highlighting included with
it's available options. When you type a keyword that is on the list it
is automaticly highlighted in your color of choice. What I don't think
you can do on the other hand is specify new key words for the highlighting
function. That is probably addressed in the Pov specific editor .dll
file.
   Either way this still does not address the issue of human typo's when
declaring unspecified words in your current work session.

 Suggestion for Mr. Warp: Take a typing class.



-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

While this is true, I point out that SOMEBODY will have to add the keywords to the
dictionary. In my case it's me. In an ideal world it would be the programmer that does
the adding. For now, we cannot auto-check keywords that do not exist in the
dictionary.

It seems like a possibility to write a utility that would automatically add keywords
from an include file to a color coded syntax dictionary. Then, when you type the
keywords, the color will tell you if they are spelled correctly.

In fact, this is standard procedure in Mac applications. The scripting keywords are
listed in the aete resource ( along with the required syntax). The scripting
application
looks up the aete resource and lists all the scripting keywords available to it. At
least 1 group of POV developers is working on adding the aete resource to POV-Ray for
Mac. Some similar type of resource could also be added to generic include files if POV
supported such a thing. If the resource is written in C++, which POV 3.5 for Mac will
be, one can simply look up the function prototypes without need for a special
resource.

Once POV is rewritten in C++, adding a dynamic dictionary will be fairly
straightforward. It's already been done in many other Mac applications. In this
manner,
the keyword dictionary would change each time the include files were changed.

Until then, we're stuck with adding our keywords ourselves.

Ken, it addresses the typo problem in exactly the same way the POV editor does - if
you
spell it wrong it shows up the wrong color!

Steve Strickland

Ken wrote:

> Steve wrote:
> >
> > The second part of my message explains the workaround to this specific problem -
> > custom dictionaries and color coded keywords in an external text editor plus
adding
> > the keyword from a custom menu.
>
>   Fortunatly for the windows users of the program the new CodeMax editor
> has program language specific color syntax highlighting included with
> it's available options. When you type a keyword that is on the list it
> is automaticly highlighted in your color of choice. What I don't think
> you can do on the other hand is specify new key words for the highlighting
> function. That is probably addressed in the Pov specific editor .dll
> file.
>    Either way this still does not address the issue of human typo's when
> declaring unspecified words in your current work session.
>
>  Suggestion for Mr. Warp: Take a typing class.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net

Post a reply to this message

Hi Mika (Terve! :) )

I think these kind of user errors should be taken care of by the include file. For my
SmokeGen include, I did a section that checks if the reserved words are declared, and
#debugs to the message window all those words that have not been declared. Example:

#if(DebuggingIsOn)
  #ifndef(reserved_word)
    #debug "reserved_word is not declared."
  #end
#end

This is on the include file creator level though, but you could add some lines to the
include files yourself that does this if the include files you use not already does
this.

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science


http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)