Gabriel Charette a écrit:
>>>
>>> Hence, given that they only depend on start_location, I just have to
>>> calculate an offset between the serialized start_location and the
>>> start_location as it would be (highest_location + 1) in the C file
>>> including the header, and offset all of the sourc
>>
>> Hence, given that they only depend on start_location, I just have to
>> calculate an offset between the serialized start_location and the
>> start_location as it would be (highest_location + 1) in the C file
>> including the header, and offset all of the source_locations on each
>> token comi
Gabriel Charette a écrit:
> Actually from my understanding, highest_location is not equal to the
> last start_location, but to the last source_location returned by
> either linemap_line_start or linemap_positition_for_column (which is
> >>= to the start_location of the current line_map).
Right,
I think I wasn't clear in the way I expressed my assumptions in my last email:
On Wed, Jul 27, 2011 at 1:11 AM, Dodji Seketeli wrote:
>
> Gabriel Charette a écrit:
>
> > From what I understand, the source_locations allocated for
> > everything in a given set of headers (from the LC_ENTER for the
Gabriel Charette a écrit:
> From what I understand, the source_locations allocated for
> everything in a given set of headers (from the LC_ENTER for the
> header in the line_table up to, and including everything in between,
> the corresponding LC_LEAVE) is dependent on only one thing; the
> value
As mentionned in my previous email, I'm now thinking of serializing
the linemap from the header by pph'ed, here is how I think this could
work:
From what I understand, the source_locations allocated for everything
in a given set of headers (from the LC_ENTER for the header in the
line_table up to,
On Tue, Jul 26, 2011 at 4:25 AM, Dodji Seketeli wrote:
> Gabriel Charette a écrit:
>
>> Alright, so after looking even more at the linemap code, here is what
>> I'm thinking now:
>>
>> So the main problem is:
>> with the linemap logic is that linemap_line_start adds a new table
>> entry if line_d
Gabriel Charette a écrit:
> Alright, so after looking even more at the linemap code, here is what
> I'm thinking now:
>
> So the main problem is:
> with the linemap logic is that linemap_line_start adds a new table
> entry if line_delta < 0 (I don't understand why this is needed, my
> assumption
Alright, so after looking even more at the linemap code, here is what
I'm thinking now:
So the main problem is:
with the linemap logic is that linemap_line_start adds a new table
entry if line_delta < 0 (I don't understand why this is needed, my
assumption is that it is because the rest of the log
On Sat, Jul 23, 2011 at 8:51 AM, Dodji Seketeli wrote:
> Gabriel Charette a écrit:
>
>>> Gabriel> @tromey: I hear you are the person in the know when it comes down
>>> to
>>> Gabriel> linemaps, do you have any hint on how we could rebuild a valid
>>> Gabriel> line_table given we are obtaining th
Gabriel Charette a écrit:
>> Gabriel> @tromey: I hear you are the person in the know when it comes down to
>> Gabriel> linemaps, do you have any hint on how we could rebuild a valid
>> Gabriel> line_table given we are obtaining the bindings from the last one in
>> Gabriel> the file to the first o
Gabriel> We are tying to keep pph as "pluginable" as possible (Diego correct me
Gabriel> if I'm wrong), so changing the actual implementation of the linemap
Gabriel> would be our very last resort I think.
Gabriel> However since source_location aren't pointers per se, this wouldn't
Gabriel> work (a
Thanks for the quick reply Tom,
On Fri, Jul 22, 2011 at 1:39 PM, Tom Tromey wrote:
>> "Gabriel" == Gabriel Charette writes:
>
> Gabriel> @tromey: We have a question for you: the problem is detailed
> Gabriel> here and our question to you is at the bottom. Thanks!
>
> Sure. I have not follow
> "Gabriel" == Gabriel Charette writes:
Gabriel> @tromey: We have a question for you: the problem is detailed
Gabriel> here and our question to you is at the bottom. Thanks!
Sure. I have not followed PPH progress very closely and after reading
your message I am not sure I have much to offer
Hi,
@tromey: We have a question for you: the problem is detailed here and
our question to you is at the bottom. Thanks!
So the line problem we are having in pph is much bigger then we
originally thought.
The problem is:
As we've had issues with before: the chain of name bindings in any
cpp_bindi
15 matches
Mail list logo
