 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina, I just realized that I failed to respond to one of your concerns in
my last post.
Sabrina Kilian wrote:
> Making the user
> include each subfile just to have access to it seems like a good way to
> increase parse time and annoy the user.
I have given this some consideration.
First of all, will it actually be a common occurence that a POV-Ray author
will want to include both an include file and one-or-more of the include
files which that include file also includes? It's question worth
considering, especially if the library is made up of files with fairly
discrete contents.
For arguments sake, I'll assume that this is indeed going to happen
frequently. One idea I have is that each include file would be parsed to
the point of containing raw-code-tokens only before it is actually included
into the next file up the chain.
Otherwise, perhaps there is a way to modify the aliasing algorithm to allow
for 'membrane namespaces' to overlap, thus demanding that each include file
in the tree be accessed only once. Of course, if an author includes a file
which is also included by another include file, then its namespace will
have to be restored before the parser includes it in the root file.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoo com> wrote:
> Otherwise, perhaps there is a way to modify the aliasing algorithm to allow
> for 'membrane namespaces' to overlap, thus demanding that each include file
> in the tree be accessed only once. Of course, if an author includes a file
> which is also included by another include file, then its namespace will
> have to be restored before the parser includes it in the root file.
Yes, that's it.
When you 'run' POV-Ray, it would first have to scan your file, then its
'#include'd files and then those files' '#include'd files and so on,
building a map of the 'includes tree'.
Then, it would run an algorithm to generate an 'alias table' based on the
'includes tree' - accounting for any redundant includes.
Then, as each include file is loaded into the buffer, its 'declaration
space' and 'implementation space' (if appropriate) would be aliased
according to the values in the 'alias table'.
The 'declaration space' of any immediate includes would not receive any
aliases (That would still be the author's responsibility). Finally, the
whole assemblage would be parsed.
Now, you're good to go.
Did I overlook anything?
Well, talk is cheap. I'd better get to work on a mock-up.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm on it!
I call this method "Retroactive Aliasing".
Input and questions welcome.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I submitted the following to the tag group today via war### [at] tagpovrayorg:
Begin File
********************************************************************************
* Retroactive Aliasing:
*
* A Low Impact Method to Eliminate Identifier Name Collisions
*
* within an Extended POV-Ray Includes Library
*
********************************************************************************
Description of need:
Until now, the avoidance of identifier name collision in POV-Ray script-
writing has been solely the responsibility of the authors of the scene
files.
This may need to change, however, since the POV-Ray community has recently
expressed an interest in creating an extended library of include files.
Once the users of POV-Ray have such a library at their disposal, then it
is
forseeable that new include files will be written that will in turn include
previously written include files. The potential combinations of include
files
in the formation of new ones is as completely unpredictable as the
imaginations
of the POV-Ray community. Therefore, in order to make such a library a
reality,
it is necessary to establish a means for avoiding unforeseeable identifier
name
collisions.
Prior use and legacy:
POV-Ray script is a descriptive language. Although it has some
functionality which makes it seem like a programming language - such as
loops,
functions and variables - it is important to remember that it is not one.
Many
POV-Ray users are not programmers. If POV-Ray were to adopt a method of
namespace management similar to that of a programming language (such as
Perl's
use of modules), then the users of POV-Ray might be required to radically
change the way in which they use POV-Ray as a condition to having use of the
extended library.
Authors of POV-Ray scenes are accustomed to managing the names of
identifiers when they include files with known contents. If two files
included
into the same scene file happen to each have an identifier by the same name,
then the author has options: A) S/he can choose the order in which each
file is
included. B) S/he can protect one of the named items by declaring it as
something else before including the second file. C) S/he can edit the scene
file or one of the include files. Until now, users of POV-Ray have enjoyed
broad freedom in the naming of original macros and objects.
From the user's standpoint, the easiest transition into using POV-Ray
with
an extended includes library would be to treat any included file the same
way as
any other, without regard for the identifiers named in any indirectly
included
(i.e. inherited) file.
Description of remedy - Retroactive Aliasing:
Scenario 1:
If no method of identifier name management is provided, then a user
would
need to trace each include thread back to its source - reading every file
along
the way - in order to avoid name collisions. This method would put the
highest
level of responsibility upon the user.
Scenario 2:
A conventional method of identifier name management is aliasing, whereby
users would have to rename identifiers - typically with prefixes. If
POV-Ray
were to adopt this method, additional syntax would be required from its
users,
increasing the users' responsibility in avoiding name collisions.
Scenario 3:
A third method - called "retroactive aliasing" - would not increase the
POV-Ray users' responsibility at all. Retroactive aliasing is the complete
inverse of the first scenario. The principle behind this method is to give
the
end-user the broadest freedom possible in the naming of identifiers while
putting the greatest limitation on the names assigned to preexisting
identifiers. No aliases would be given to identifiers declared in the
user's
scene file. Nor would they be given to any declared in any files included
directly by the scene file. Aliasing would be applied to all identifiers
declared in all included files which are not also directly included by the
scene
file.
What makes this possible is the fact that, even given their broad
freedom,
users have only sixty-three characters at their disposal when naming
identifiers.
The one-byte numerical values (ascii values) of these characters, as well as
those of the special characters used in POV-Ray script, are all below 128.
That
leaves the character values of 128 through 255 as an available resource for
the
assignment of non-conflicting aliases. [Note: Use of utf8 not addressed
here.]
Implementation:
End File
[Note: For easier reading, copy and paste and view @ 80 columns.]
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 06 Dec 2006 15:26:48 -0500, Randall Sawyer wrote:
> conflicts may occur. To address this issue, I propose the following
replace "to address this issue" with "to fix this problem".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
bob <bob### [at] almostbestwebnet> wrote:
> replace "to address this issue" with "to fix this problem".
Thank you, Bob. Duly noted.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.457745f5315c6ef0e81faf070@news.povray.org>,
sra### [at] yahoocom says...
> Patrick - Thank you for your response
>
> Patrick wrote:
> > The problem is, this "breaks" current implementation. Now, that doesn't
> > mean you couldn't write a failure simply recursive system to "find and
> > fix" such references, or even eventually design the editor to
> > "recognize" them and automatically give you MS Studio style recall, lik
e
> > typing "jed." and having a pop-up list of thing "in" jed.inc, including
> > fred.jed.<blah>.
>
> I had been thinking along these lines before. However, once I started
> asking myself the rhetorical question "What is POV-Ray?", I realized that
> the word "editor" does not appear in the answer. POV-Ray - as it exists
> now - does not require the use of a specific editor. To add that
> requirement to its use would make it more costly and less accessible.
>
Umm. Not sure the idea is "That" serious. Sure, the "native" editor
could be expanded to handle it, but I can code VB in notepad, just not
with the bells and whistles available in the VB editor. We are talking
about a GUI element that "helps" deal with a "language" specification.
The editor used doesn't have to do that, but it does help things if it
does. Its just means that someone using:
#include "fred.inc"
**must** treat anything in fred like fred.<blah>.
Its not going to make things any more complicated than trying to fix
naming conflicts is already and, you could even make it so that the
parser itself warns about conflicts, but "tries" to run anyway. I.e., if
you don't have one, it uses the correct object anyway. If it does have
one, it generates a warning about the conflict and what file its in,
then tries to use the "local" named item. The only issue this causes is
maybe needing to state me.<blah> or local.<blah> as a means to saying,
"Yes, I **really** did intend to use the local one, so don't warn me."
> > In other words, its not trivial, but hardly impossible
> > to write a function like "Convert this scene and its includes to new
> > naming system", and automatically fix all of it, saving the new files
> > under slightly different names, to preserve the originals.
>
> What I am proposing would actually rewrite the deeper includes (those cal
led
> by other includes). The rewriting would occur in the buffer - not in the
> files themselves, thus protecting the contents of the original includes.
> The rewriting would follow a fail-safe algorithm, applied the same way on
to
> every includes-tree. There would be no need to "ask" to reuse an identif
ier
> from a deeper include.
>
But, that doesn't do anything different than I suggest and it means
**extra** time is taken "every" parse, to fix conflicts. Better to
specify a system, then provide a means to update non-compatible scenes
to the new standard.
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you for your contribution, Patrick.
Patrick Elliott <sel### [at] rraznet> wrote:
> The only issue this causes is
> maybe needing to state me.<blah> or local.<blah> as a means to saying,
> "Yes, I **really** did intend to use the local one, so don't warn me."
>
> But, that doesn't do anything different than I suggest and it means
> **extra** time is taken "every" parse, to fix conflicts. Better to
> specify a system, then provide a means to update non-compatible scenes
> to the new standard.
>
Did you actually read the most recent posting I made to this thread? (aside
from response to Bob) What did I have to say about any changes to user
responsibilities? I would prefer that questions and suggestions in this
thread be limited to discussion about the algorithms needed to implement
"retroactive aliasing" and the C++ code needed to make the model a reality.
Discussing whether or not such an idea is a good one in theory is not
enough. People need to be able to try it out - and to try out other models
- and to decide what works the best for their needs.
I would love to have some other users show up at this site with whom to
colaborate.
Please, if you share my vision, then help me to stop beginning my sentences
with the word "I", and to start beginning them with the word "we".
A couple of asides:
I want to help make a suit of clothes for us to "grow into" - not one made
of patches that are added over time. I have a strong feeling that
"retroactive aliasing" could occur on the fly - thus, reducing parse time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I want to help make a suit of clothes for us to "grow into" - not one made
> of patches that are added over time.
Patches are inevitable in software development. It doesn't matter if they
are called add-ons, plugins, hooks, components or whatever... you may begin
from scratch, but on time it'll be plenty patched...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.457b13e2315c6ef0adb4e0ea0@news.povray.org>,
sra### [at] yahoocom says...
> Thank you for your contribution, Patrick.
> Patrick Elliott <sel### [at] rraznet> wrote:
> > The only issue this causes is
> > maybe needing to state me.<blah> or local.<blah> as a means to saying,
> > "Yes, I **really** did intend to use the local one, so don't warn me."
> >
> > But, that doesn't do anything different than I suggest and it means
> > **extra** time is taken "every" parse, to fix conflicts. Better to
> > specify a system, then provide a means to update non-compatible scenes
> > to the new standard.
> >
>
> Did you actually read the most recent posting I made to this thread? (asi
de
> from response to Bob) What did I have to say about any changes to user
> responsibilities? I would prefer that questions and suggestions in this
> thread be limited to discussion about the algorithms needed to implement
> "retroactive aliasing" and the C++ code needed to make the model a realit
y.
> Discussing whether or not such an idea is a good one in theory is not
> enough. People need to be able to try it out - and to try out other mode
ls
> - and to decide what works the best for their needs.
>
I am not sure what your complaint is about though. This isn't like
deciding if we want to include some new object, because the number of
people that might need object A instead of object B means that A won't
work for the B people. The point is likely mute anyway, since the only
place this is likely to show up is in MegaPOV. POV-Ray 4 will
"probably" implement something more like I am talking about anyway, so
any converter that does it in the background, where no one can see it,
won't conform to the new specs anyway when that comes out. Nothing we do
know is likely to either, unless its adopted into the new specs. Your
idea is a stop gap, and a mostly unneeded one imho, given that it can be
more easily handled, if someone really needs it, with a separate
application.
While I tend to sort of agree with the principle of letting people
figure out what works best, that's not going to happen on a project like
you suggest. The effort of redoing the parser to do what you want would
take more then sufficient time to accomplish to leave no time for anyone
to consider an alternative. And ironically, the *only* major differences
seem to be a) you thinking that "on the fly" is some magic solution that
won't spend extra time every parse and b) doing it all internally,
instead of exporting a copy that doesn't need "on the fly" modification
to work. Then again, there is no practical reason why extra flags can't
be included, like, "Export_Adjusted_Scenes = T/F", and,
"Use_Exported_Scenes = T/F". In other words, give people the option of
having the first pass, like in an animation, export a fixed version of
all the files, then also have the option in the next frame to look to
see if that file(s) exist and use "it/them" for the next parse. Any "on
the fly" solution "must" take extra time to make those corrections. Its
silly to do it once for every 500 frames in an animation. And the code
needed to rework POV-Ray's internals to cache the scene and reuse it,
with appropriate changes each frame, is going to be "more" complex than
just exporting it once and reusing that result. At least I predict it
would be.
Anyway, was just dropping a suggestion and trying to state a few
problems I saw with your solution, not start a big argument over it.
Good luck trying to figure it out.
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
