<div dir="ltr">On Fri, Sep 20, 2013 at 3:59 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5">
<div>On Sep 20, 2013, at 3:37 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Rui,</div><div><br>
</div><div>I like this in general, but have a few questions.</div>
<br><div><div><div>On Sep 20, 2013, at 2:30 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
2. We would instead add a new method nextFile() to LinkingContext, which returns a new file from which Resolver should try to resolve undefined symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver calls nextFile() repeatedly to link until nextFile() returns a null value.</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
3. Resolver will notify Linking Context when (A) all undefined symbols are resolved (success), or (B) it detects it's in an infinite loop in which it cannot resolve any symbols anymore (failure). Linking Context will do whatever it thinks appropriate for the event notification.</div>
</blockquote></div><div>How does the Resolver detect an infinite loop? As in the example below, it is supposed to keep getting a,b,c,a,b,c… At some point, no more undefines are being fulfilled by a,b,c,a,b,c…, but how does the resolver know that the files are repeating, to know to tell the InputGraph to move on? </div>
</div></div></blockquote><div><br></div><div>nextFile() should returns the same file objects for the same file, so Resolver can notice if it haven't resolved any symbol since last time it saw the same file.</div></div>
</div></div></blockquote></div></div><div>That is not how groups work. The resolver has to keep checking each file in the group, in order, until there is one full pass of the group and none in the group provided any more content. </div>
<div><br></div><div><br></div><div><div class="im">On Sep 20, 2013, at 3:42 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>> wrote:<br><blockquote type="cite">
nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :-<br><br>nextFile(currentResolverState) :-<br><br>a) Returns the next file if the current node is not a group node<br>
b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added.<br>c) Returns the start file in the group node, if the resolver state states undefined/weak/shared library atoms were added<br>
d) If the state is unchanged, no symbols were added exit the group and move to the next node.<br></blockquote><div><br></div></div><div>What causes the Resolver state to change? I understand the state of “there are undefines remaining”, but the “something was added” is a transient state. Each last file, changes it. </div>
<div><br></div><div>The InputGraph knows how to exit a group, but does not know if it should.</div><div>The Resolver knows which files added content, but does not know which files are in what groups.</div><div><br></div>
<div>
How about this for InputGraph:</div><div><br></div><div><span style="white-space:pre-wrap"> </span>void fileAddedContent(File *);<span style="white-space:pre-wrap"> </span>// asserts that File* param is the same thing nextFile() last returned</div>
<div><span style="white-space:pre-wrap"> </span>File *nextFile();</div><div><br></div><div>The Resolver, also tells the InputGraph which files it used. When in a group, the InputGraph keeps a flag for the group of whether it has contributed anything. It starts as false for the first entry in the group. If fileAddedContent() is called, the flag is updated. When nextFile() is called and the previous entry was the last in the group, if the flag says nothing in that pass contributed, the InputGraph exits the group and moves on to the next file.</div>
</div></div></div></blockquote><div><br></div><div>I don't want to make Resolver to have a reference to input graph. The point of this proposal is to separate input graph handling from Resolver and instead making Linker Context to do that task. Resolver shouldn't have knowledge on how it should iterate over input files, focusing only on core linking. Linking Context should implement the policy and "feed" input files to Resolver. Resolver should blindly consume an input file given by Linking Context, and report its status to Linking Context.</div>
<div><br></div><div>How about this: add integer parameters to nextFile() to report the current number of undefined and defined atoms. With that information, Linking Context is able to decide what file should be fed to Resolver next. For example, it can detect from the atom counts whether Resolver need to exit --{start,end}-group loop or not.</div>
</div></div></div>