<div><div dir="auto">I am not sure if Andreas’ proto expander duplicates embedded scripts or not.  It at least seems like state and routes to/from scripts should be copied.  Opinions?  Should we meet?  Leonard made the point that scripts should come before Protos.<br></div><div dir="auto"><br></div><div dir="auto">John.</div><div dir="auto"><br></div></div><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 26, 2022 at 3:25 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Thanks, I updated the wiki page.<br>
<br>
I took a look and found the issue in x3dom. For externprotos it will<br>
only process the first protodeclare as instructed in the spec, and<br>
ignore everything else including earlier externprotos for which a<br>
specific exception is made in the spec. Hopefully, I will find the<br>
strength to dive into this morass at some point later. It may suffice<br>
to specifically look for earlier, outside externprotos in externprotos<br>
since this seems to be a special case. Or it may be necessary to load<br>
the complete scene in an externproto. For example, it may be ok to DEF<br>
a node outside the ProtoDeclare used for an externproto and then USE<br>
it as a default value for a SFNode field in the default<br>
ProtoInterface. Hopefully, there is no use case for such things. This<br>
would require loading the complete scene.<br>
<br>
Cheers, Andreas<br>
<br>
> Date: Tue, 26 Apr 2022 11:34:39 -0600<br>
> From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>
<br>
> InstantPlayer was made at Fraunhaufer IDG. Here's how it renders:<br>
> <a href="http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_stack_push_and_pop_InstantPlayer.jpg" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.net/web3d/tests/protos/Proto_context_stack_push_and_pop_InstantPlayer.jpg</a><br>
><br>
><br>
><br>
> On Tue, Apr 26, 2022 at 10:57 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
><br>
> ><br>
> > <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules</a><br>
> ><br>
> > "A prototype may be instantiated in a file anywhere after the completion<br>
> > of the prototype definition."<br>
> > If the specs meant what you are suggesting --protos are self contained<br>
> > including proto definitions-- then it would have said "context" rather than<br>
> > "file"<br>
> > "Prototype definitions appearing inside a prototype definition ( i.e.,<br>
> > nested) are local to the enclosing prototype. "<br>
> > - refinement of the above file order rule.<br>
> ><br>
> ><br>
> > On Tue, Apr 26, 2022 at 9:51 AM GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>> wrote:<br>
> ><br>
> >> "I really do<br>
> >> not think that proto declarations should be required to inherit<br>
> >> existing declarations from parent execution contexts"<br>
> >><br>
> >> If C++ required each class definition to be self-contained --to redefine<br>
> >> all the types it depends on-- it would be a very messy and onerous system.<br>
> >> If you want a system that can build up types - types on top of types to<br>
> >> make more complex types - then you need a way for a type to use previously<br>
> >> defined types.<br>
> >> In x3d -a prototyping language- that looks like a new type being able to<br>
> >> use a type defined previously in the file. Extern ProtoDeclares are stored<br>
> >> in scene files as ProtoDeclares. As such they should be able to use type<br>
> >> defined previously in their host file.<br>
> >><br>
> >><br>
> >> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> > Date: Tue, 26 Apr 2022 07:56:47 -0600<br>
> >>> > From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>
> >>> > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> >>><br>
> >>> > When I started with freewrl around 2009, it had a text-based system for<br>
> >>> > protos:<br>
> >>> > - when parsing a scene, if it found a proto declare, it would scrape<br>
> >>> the<br>
> >>> > text into a buffer. Then as it continued parsing, when it hit a proto<br>
> >>> > instance it pasted, and continued parsing over the pasted text as<br>
> >>> though it<br>
> >>> > had been there all along. Extern protos similar, it would pause<br>
> >>> parsing, go<br>
> >>> > to the file referenced, look for the proto declare by name, and scrape<br>
> >>> out<br>
> >>> > the text of the ProtoDeclare, for pasting in-scene.<br>
> >>> > And it worked a bit. But especially extern protos weren't working<br>
> >>> reliably.<br>
> >>> > As a casual volunteer I decided to fix the bugs. How hard could it be?<br>
> >>> A<br>
> >>> > little debugging and presto, I'd be a hero. As I got into it and saw<br>
> >>> more<br>
> >>> > scene failure examples there were several emotional stages like<br>
> >>> grieving<br>
> >>> > denial, shock, sadness, resistance etc. And a slow dawning realization<br>
> >>> the<br>
> >>> > whole system needed a rework.<br>
> >>> > And I didn't have support from others -just silence, perhaps they knew<br>
> >>> it<br>
> >>> > was a mess and wanted to stay clear.<br>
> >>> > It was a sickening feeling, and I needed to think for a few weeks<br>
> >>> whether I<br>
> >>> > even wanted to be a volunteer programmer if the system was rotten from<br>
> >>> the<br>
> >>> > core.<br>
> >>> > So it can not only be a monster task, but precisely because it's a<br>
> >>> monster<br>
> >>> > there's little support for those brave enough to tackle it.<br>
> >>> > (After a few weeks I got to the Acceptance stage of grieving, and<br>
> >>> spent 6<br>
> >>> > months of hobby time building the new proto system).<br>
> >>><br>
> >>> Thanks for the story, and for engaging. To me, I became interested<br>
> >>> when I realized that x3dom is probably flexible enough to allow for<br>
> >>> parameterized definition and registration of new nodes dynamically<br>
> >>> which behave then exactly like native nodes. This is different from<br>
> >>> filling in templates. For example, there is no performance penalty<br>
> >>> during tree traversal and it enables instancing using xml nodes with<br>
> >>> the new names, just as in x3dv.<br>
> >>><br>
> >>> I am pretty happy with how it came out. An additional complication is<br>
> >>> asynchronous loading of remote resources which is standard on the web.<br>
> >>> X3D should rely less on how nodes or statements are ordered in a<br>
> >>> scene.<br>
> >>><br>
> >>> It is just frustrating that there are ill defined corners. I really do<br>
> >>> not think that proto declarations should be required to inherit<br>
> >>> existing declarations from parent execution contexts ( DEF/USE name<br>
> >>> scopes are different but there is still a separated execution context<br>
> >>> ). That means the protos array of a new execution context should be<br>
> >>> empty initially. The SAI spec. actually says so.<br>
> >>><br>
> >>> Best, Andreas<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> x3d-public mailing list<br>
> >>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> >>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> >>><br>
> >><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220426/ad3376aa/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220426/ad3376aa/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Tue, 26 Apr 2022 14:37:25 -0400<br>
> From: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] ProtoBody completeness in nested Protos<br>
> Message-ID:<br>
>         <<a href="mailto:CAKdk67t-xRu%2BPkL4nRAM9NOn8DrMznORyhwYaeG4fweBYgFwvw@mail.gmail.com" target="_blank">CAKdk67t-xRu+PkL4nRAM9NOn8DrMznORyhwYaeG4fweBYgFwvw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="UTF-8"<br>
><br>
> > Date: Tue, 26 Apr 2022 10:57:10 -0600<br>
> > From: GPU Group <<a href="mailto:gpugroup@gmail.com" target="_blank">gpugroup@gmail.com</a>><br>
> ><br>
> > <a href="https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules</a><br>
> ><br>
> > "A prototype may be instantiated in a file anywhere after the completion of<br>
> > the prototype definition."<br>
> > If the specs meant what you are suggesting --protos are self contained<br>
> > including proto definitions-- then it would have said "context" rather than<br>
> > "file"<br>
> > "Prototype definitions appearing inside a prototype definition ( i.e.,<br>
> > nested) are local to the enclosing prototype. "<br>
> > - refinement of the above file order rule.<br>
><br>
> Ok. thanks ! There it is. Time to look into this, then.<br>
><br>
> -Andreas<br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of x3d-public Digest, Vol 157, Issue 107<br>
> ********************************************<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>
</div>