 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, as an offshoot from another thread here, perhaps an even simpler
solution to the problem exists. What if, everytime you #declare an
object which has already been #declare'd, the parser gives you a warning
telling you what was re#declare'd and where?
This would not apply to #local items, only to globals. It would take
some work to convert a lot of the current include files, but it would be
much safer overall.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguy com> wrote:
> OK, as an offshoot from another thread here, perhaps an even simpler
> solution to the problem exists. What if, everytime you #declare an
> object which has already been #declare'd, the parser gives you a warning
> telling you what was re#declare'd and where?
>
> This would not apply to #local items, only to globals. It would take
> some work to convert a lot of the current include files, but it would be
> much safer overall.
>
> ...Chambers
file this idea under that thread too, Ben. :)
but then, suppose this works: people actually look at the warnings if
things go noticeably wrong. What happens next is that they will have then
to rename some stuff in their own files or, if they are out of luck, in
someone else's file if they include 2 or more files which happen to share
some names but are not related.
This is too much of a problem and a simple alias together with the include
declaration in the first place would not permit that to happen. Giving a
unique prefix identifier of your own to include files is much better than
having to go through the files renaming stuff. That and local scoping for
included items should go a long way into making povray SDL a lot more
sturdy and capable for handling large catalogues of objects and textures...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> OK, as an offshoot from another thread here, perhaps an even simpler
> solution to the problem exists. What if, everytime you #declare an
> object which has already been #declare'd, the parser gives you a warning
> telling you what was re#declare'd and where?
#declare Index = 0;
#while(Index < 10000)
#declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
... (do something with TheObject) ...
#declare Index = Index+1;
#end
How many warnings do you get?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> #declare Index = 0;
> #while(Index < 10000)
> #declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
> ... (do something with TheObject) ...
> #declare Index = Index+1;
> #end
>
> How many warnings do you get?
>
#local index = 0;
#while (index < 10000)
#local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
... (do something with TheObject) ...
#local index = index+1;
#end
No warnings at all :)
That's why I said it would take some work to get a lot of the current
include files to work with this; of course, the behavior could be
switched off via a command-line option (or an ini file option).
Basically, you would only use #declare for items that truly need to be
global in scope, rather than using it out of habit. Of course, I also
like the idea I put forward of container objects, but this seemed like
an easier solution to implement.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Warp wrote:
> > #declare Index = 0;
> > #while(Index < 10000)
> > #declare TheObject = sphere { <Index, 0, 0>, 1 pigment { rgb 1 } };
> > ... (do something with TheObject) ...
> > #declare Index = Index+1;
> > #end
> >
> > How many warnings do you get?
> >
> #local index = 0;
> #while (index < 10000)
> #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
> ... (do something with TheObject) ...
> #local index = index+1;
> #end
> No warnings at all :)
The problem is that my version is completely valid and there's nothing
wrong with it, and there's no reason why someone wouldn't write code like
that. Issuing ten thousand warnings on it makes no sense.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi!
> #local index = 0;
> #while (index < 10000)
> #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
> ... (do something with TheObject) ...
> #local index = index+1;
> #end
This is not always possible: Imagine calling a include file inside a
loop, where the include file uses a global variable that has to be
changed for every run:
#local index = 0;
#while (index<10000)
#declare This_Is_Used_By_The_Include = Some_Function(index);
#include "someinclude.inc"
#local index = index + 1;
#end
You'll always have to rely to some extent on the 3rd-party programmer,
even if you use real OOP-languages like C++ or Java.
Regards,
Florian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The problem is that my version is completely valid and there's nothing
> wrong with it, and there's no reason why someone wouldn't write code like
> that. Issuing ten thousand warnings on it makes no sense.
That's true, it IS completely valid, which is why the warnings could be
disabled. The real question is not what is valid now, but what
practices would work best to discourage namming conflicts.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
> This is not always possible: Imagine calling a include file inside a
> loop, where the include file uses a global variable that has to be
> changed for every run:
>
> #local index = 0;
> #while (index<10000)
> #declare This_Is_Used_By_The_Include = Some_Function(index);
> #include "someinclude.inc"
> #local index = index + 1;
> #end
>
> You'll always have to rely to some extent on the 3rd-party programmer,
> even if you use real OOP-languages like C++ or Java.
>
>
> Regards,
> Florian
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 ;)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker nous apporta ses lumieres en ce 06/12/2006 14:13:
> Hi!
>> #local index = 0;
>> #while (index < 10000)
>> #local TheObject = sphere { <index, 0, 0>, 1 pigment {rgb 1} };
>> ... (do something with TheObject) ...
>> #local index = index+1;
>> #end
> This is not always possible: Imagine calling a include file inside a
> loop, where the include file uses a global variable that has to be
> changed for every run:
> #local index = 0;
> #while (index<10000)
> #declare This_Is_Used_By_The_Include = Some_Function(index);
> #include "someinclude.inc"
> #local index = index + 1;
> #end
> You'll always have to rely to some extent on the 3rd-party programmer,
> even if you use real OOP-languages like C++ or Java.
> Regards,
> Florian
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.
--
Alain
-------------------------------------------------
Al Gore is proof that Tennessee has a sense of humor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> I'll be downloading the source-code tonight to see things for myself and
> perhaps implement a demo for my #includeas proposal...
Nice :)
I think some friendly competition would be beneficial to the whole POV-Ray
project. I have a feeling that we - the community - are on our way to
discovering some amazing new implementations in the SDL, whatever it ends
up looking like. If my "retroactive aliasing" model ends up being nothing
more than a pipe dream, then so be it.
I'm looking forward to seeing what you come up with.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I'm looking forward to seeing what you come up with.
i'll have to actually get down to C level because it was with much sadness
that i witnessed for the first time how limited file I/O is in the SDL:
#read don't work as expected, it's actually more akin to C's scanf. This
is sad because i was trying to write a includeas macro which would scans
the included files line-by-line to search for #declares and rewrite them
with prefixes... no way to do it... so, C we go!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW to nemesis and anyone else whose been following the the topic of
'aliasing':
I recently made reference to "cork" and "tungsten" (Includes - Standards
#53). If you didn't already know I was referring to, here it is:
Legend has it that Thomas Edison already knew that the electric light bulb
was possible in principle before he actually made one that worked. All he
needed was to find the right material for the element. Instead of ruling
out any possibility, he decided to try every material he could think of -
even the ones he knew wouldn't work - including cork. Eventually he
settled on tungsten - it worked the best.
Alchemically speaking: Of all the metals in the periodic chart, tungsten
has the highest melting-point. I feel that well-made software should be
like tungsten. It should glow white-hot without burning out when you put a
high current through it. I'll leave the gold to the user in posession of
the software that's made of tungsten.
-Randall
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?
As far as I know, nothing specific has been discussed yet. However, it has
been long been a simple fact that the current SDL is a bunch of kludges over
older kludges and it just doesn't scale. Adding more and more new features
to the current SDL just makes it worse, not better.
A "new SDL" doesn't necessarily mean a new scripting language which will
look completely different from the current SDL, although I'm sure that
whatever will be developed, there will be some differences, but only for
the better.
The user-defined functions in POV-Ray (which form their own syntax space,
separate from the SDL, and which are about 100 times more efficient than
#macros because they are byte-compiled) is a step towards the ultimate goal.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Alchemically speaking: Of all the metals in the periodic chart, tungsten
> has the highest melting-point. I feel that well-made software should be
> like tungsten. It should glow white-hot without burning out when you put a
> high current through it. I'll leave the gold to the user in posession of
> the software that's made of tungsten.
Povray is culture too. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp 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.
I knew this, but I never realized one of the implications before: If
you're working on writing macro code, and you start a render, you may
break the render by editing the file the macro is in before the render
is done, yes?
(Of course, on decent operating systems, and even Windows, reading the
same file a bunch of times in a row isn't all that much overhead,
compared to reading it the first time.)
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I knew this, but I never realized one of the implications before: If
> you're working on writing macro code, and you start a render, you may
> break the render by editing the file the macro is in before the render
> is done, yes?
Only during parsing.
> (Of course, on decent operating systems, and even Windows, reading the
> same file a bunch of times in a row isn't all that much overhead,
> compared to reading it the first time.)
Even in decent OSes it is a lot of overhead compared to eg. having
the macro in memory. Or even in the same file.
You can test this in practice: Make a loop which calls a macro which
is located in another file and measure how long it takes. Then move the
macro to the current file (where the loop is) and measure again. You will
probably get a significant increase in speed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Only during parsing.
Oh yes. That makes sense. Most of my scenes parse pretty quickly, even
the big ones.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp 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.
Would it be possible for POV-Ray to hold all already-parsed files in a
memory buffer, so it wouldn't have to open them multiple times? I
realize this might take a bit of work to deal with potential rewrites of
the macro via the file I/O options, but it would be shedloads faster
than the current method, I think.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers nous apporta ses lumieres en ce 07/12/2006 06:45:
> 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
There already are some backward compatibility breakages. Try rendering a scene
that use "athmosphere" or "hallo". NO version setting can make them work!
Any scene using radiosity or spline may render differently in future versions,
maybe needing editing as some keywords can be dropped or replaced.
--
Alain
-------------------------------------------------
After any salary raise, you will have less money at the end of the month than
you did before.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis nous apporta ses lumieres en ce 07/12/2006 07:42:
> 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...
What you can do is #declare MyMacro = IncludedMacro
Then, if you need many instances of the macro, you work on the copy, saving you
from having to open and read the include file each time.
--
Alain
-------------------------------------------------
Are you a Klingon, or is that a turtle on your head?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker nous apporta ses lumieres en ce 07/12/2006 10:21:
> 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
An example of an include that can need 50+ parameters: blob man. Most parameters
have default values, you only change those you need using many #declare.
--
Alain
-------------------------------------------------
'I never met a piece of chocolate I didn't like.'
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> There already are some backward compatibility breakages. Try rendering a
> scene that use "athmosphere" or "hallo". NO version setting can make
> them work!
> Any scene using radiosity or spline may render differently in future
> versions, maybe needing editing as some keywords can be dropped or
> replaced.
>
Yes, but those features cause a warning in the output that backwards
compatibility will not necessarily be maintained.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> A "new SDL" doesn't necessarily mean a new scripting language which will
> look completely different from the current SDL, although I'm sure that
> whatever will be developed, there will be some differences, but only for
> the better.
Indeed, examples of things that will certainly change are all those little
bits and pieces where the language itself is inconsistent. I.e. in some
places we use [ ... ] for maps and in others we don't. And then there are
those objects where the syntax specifies the number of elements in advance,
which isn't (always) necessary at all, and in various cases just makes
hand-editing a scene hard. Then there are the bits and pieces where you
cannot actually use dot (aka ".something") syntax as expected. And so on,
and so on.
Plus of course, various directive issues, like the fun stuff you can do with
macros writing to files including macros (a kind of self-modifying code),
which makes parsing a mess, slow, and can even make it unreliable. And while
this may go, certainly there will be a way to parse from user-generated
strings instead (which is much easier to deal with). Oh, and even in 3.7 the
way (user generated) files are handled will, before the last beta, will
become more secure and predictable.
> The user-defined functions in POV-Ray (which form their own syntax space,
> separate from the SDL, and which are about 100 times more efficient than
> #macros because they are byte-compiled) is a step towards the ultimate goal.
Plus, at long last there is a good and reliable VM technology available as
true open sources, in form of llvm (see llvm.org). So count on seeing that
as new backend for functions to appear the the (distant) future. At long
last we can then even support the famous "plug ins", *if* (AND ONLY IF!!!)
we decide we want that.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Indeed, examples of things that will certainly change are all those little
> bits and pieces where the language itself is inconsistent. I.e. in some
> places we use [ ... ] for maps and in others we don't. And then there are
> those objects where the syntax specifies the number of elements in advance,
> which isn't (always) necessary at all, and in various cases just makes
> hand-editing a scene hard. Then there are the bits and pieces where you
> cannot actually use dot (aka ".something") syntax as expected. And so on,
> and so on.
Splines? :-) I use them a LOT now knowing they may change. It'd be really
cool though if the same variable could simultaniously be treated as an
array of the defining vectors (4d format) & as a spline. I.e MySpline[5]
returns a 4D vector where t was the value along the spline & MySpline(0.5)
would do what it does now.
> Plus of course, various directive issues, like the fun stuff you can do with
> macros writing to files including macros (a kind of self-modifying code),
> which makes parsing a mess, slow, and can even make it unreliable. And while
> this may go, certainly there will be a way to parse from user-generated
:-( No more arbitrary text output? Does that mean quotation mark
encapsulated & comma-separated output only?
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C <nomail@nomail> wrote:
> > Plus of course, various directive issues, like the fun stuff you can do with
> > macros writing to files including macros (a kind of self-modifying code),
> > which makes parsing a mess, slow, and can even make it unreliable. And while
> > this may go, certainly there will be a way to parse from user-generated
> :-( No more arbitrary text output? Does that mean quotation mark
> encapsulated & comma-separated output only?
No, it doesn't mean that.
One of the (very many) problems in the current SDL is precisely the
limitations on file handling (both writing and especially reading),
which is something I am sure will be made a lot more generic and versatile.
(One application I envision is an include file which imports/exports from/to
another format, eg 3DS.)
It just means that writing a file using SDL and then including it may
need to be limited.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> What you can do is #declare MyMacro = IncludedMacro
> Then, if you need many instances of the macro, you work on the copy, saving you
> from having to open and read the include file each time.
I think you have a fundamental misconception about how macros work.
You didn't even test if that #declare even works.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Would it be possible for POV-Ray to hold all already-parsed files in a
> memory buffer, so it wouldn't have to open them multiple times? I
> realize this might take a bit of work to deal with potential rewrites of
> the macro via the file I/O options, but it would be shedloads faster
> than the current method, I think.
Of course it would be possible, but that's a really low-priority issue
right now, and will probably become obsolete with pov4.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
