nemesis wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
>> This is certainly possible now, however it goes back to the old practice
>> of using an include file as a macro, rather than including a file once,
>> and calling a macro inside of it.  IMNSHO, this practice should be
>> discourage anyway, so I would consider it a bonus ;)
> 
> i double that! :)
> 
> 
> 

Tripled.

 #declared several times, and What about implementing a command like
MegaPOV's #set? You could still have globally used #declare variables,
reasonably warn when something is only make moderate changes to scenes
that need it and the POV-Ray source?

Even disable warnings by default, and only show them if the right flag
is present. To the average user nothing has changed, and to someone who
wants to track down an obscure problem between their includes and
someone elses it would make things a little easier.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> What HORRIBLE piece of code! Do that then wonder why your scene takes so much 
> time to parse and why it gobbles up your memory. Beter to use a real macro.

  Rather ironically, if such #macro is in an include file, it won't be
much faster than the given code (which explicitly #includes the file in
each loop).
  This is because, if the #macro is indeed in an included file, POV-Ray will
open that file, seek to the macro, parse it and close the file, and this each
time the macro is called. Thus the overhead is about as bad as an explicit
#include call.

  I'm not saying this is a good thing, I'm just stating a fact.
  (This, among other things, is a direct consequence of the history of
the SDL, which is just one kludge over another over the years, and a big
reason why pov4 is intended to be written from the scratch and with a
much better SDL.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   (This, among other things, is a direct consequence of the history of
> the SDL, which is just one kludge over another over the years, and a big
> reason why pov4 is intended to be written from the scratch and with a
> much better SDL.)
> 

Has it been decided that SDL will get a complete overhaul, then?  And 
what about backwards compatibility - is POV-Ray finally giving up on it?

(Not that it would necessarily be a bad thing, I just don't remember 
hearing that).

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Has it been decided that SDL will get a complete overhaul, then?  And
> what about backwards compatibility - is POV-Ray finally giving up on it?

I don't believe he is talking to the SDL language itself (the interface),
but to the kludgy implementation.  No need to fear no backwards
compatibility.

I think we all agree the SDL is the very heart and crown jewel of povray.
It's simple, unobstrusive and get things done in a much more practical and
declarative way than most programming languages.  The SDL needs no fix, but
some nice feature addons are a plus and the implementation behind getting a
facelift is great news. :)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   This is because, if the #macro is indeed in an included file, POV-Ray will
> open that file, seek to the macro, parse it and close the file, and this each
> time the macro is called. Thus the overhead is about as bad as an explicit
> #include call.

oh, man! This is freakish bad!  It really read the include file each time
the macro is called?!  Is it an easy way to get local scoping for the macro
by using the stabilished local file for the include files?... that hurts...

I'll be downloading the source-code tonight to see things for myself and
perhaps implement a demo for my #includeas proposal...

Post a reply to this message

Alain wrote:
> What HORRIBLE piece of code! Do that then wonder why your scene takes so much 
> time to parse and why it gobbles up your memory. Beter to use a real macro.

There *are* situations when using a macro is not the best solution. I
regularly have include files which depend on a *lot* (i.e. 50+)
parameters - you don't want to pass all these everytime you call a
macro. Normally you'd use structs to encapsulate those settings, but as
the SDL does not support custom data types this is impossible. It's
therefore much cleaner (i.e. easier to write, read & maintain) to use
declared values.


Regards,
Florian

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> There *are* situations when using a macro is not the best solution. I
> regularly have include files which depend on a *lot* (i.e. 50+)
> parameters - you don't want to pass all these everytime you call a
> macro.

good point.  It is indeed much cleaner than calling a 50+ parameters macro.

OTOH, is there real need for a single file with 50+ parameters?  Must the
user actually set all of those any time they call the include?

If they are needed, then it's not much better than a 50+ parameter macro
call, except parameters are named.

If most are not needed to be set at any one time, i guess your include file
is lacking functional cohesion, that is, it could probably be better
decoupled into several highly cohesive smaller include files with far less
parameters each and which are logically connected by subject.  If such, you
could consider instead just a single include file with several separate
macros with their own parameters.

Anyway, given what Warp just slipped, it doesn't matter much anyway.  But
i'd still go for macros, since the interface can remain the same once we
get a truly good macro implementation for the 4.0 rewrite...

Post a reply to this message

nemesis wrote:
> OTOH, is there real need for a single file with 50+ parameters?  Must the
> user actually set all of those any time they call the include?
> 
> If they are needed, then it's not much better than a 50+ parameter macro
> call, except parameters are named.

Most of them have sensible default values, so normally you don't need to
change all of them for every run. But it depends on the scene which
parameters you have to tweak, so using a fixed declare/parameter
combination is not feasible. If those include files were for public use
I'd create a more userfriendly interface by reducing the possible
parameters. But these are rather experimental files for trying out
different algorithms, so I prefer the freedom over the simplicity :)


Regards,
Florian

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   This is because, if the #macro is indeed in an included file, POV-Ray will
> > open that file, seek to the macro, parse it and close the file, and this each
> > time the macro is called. Thus the overhead is about as bad as an explicit
> > #include call.
>
> oh, man! This is freakish bad!  It really read the include file each time
> the macro is called?!  Is it an easy way to get local scoping for the macro
> by using the stabilished local file for the include files?... that hurts...


This is also part of the reason why I'm not as big of a fan of giving each
macro it's own file.  Most of my macros actually call on other macros and
if there's a #while loop in there, it's nice to already have it there in
the same file.  Of course I haven't done any tests like (was it Warp?)
somebody did a few months ago to see how much time I'm saving.

Charles

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:

> There *are* situations when using a macro is not the best solution. I
> regularly have include files which depend on a *lot* (i.e. 50+)
> parameters - you don't want to pass all these everytime you call a
> macro.


Me too, although there'll be macros in there too likely.

Post a reply to this message