Hi Luis-san, thanks to quick response!
I have investigated your new patch.
(Sorry, I can't try it yet. It is working time in Japan.)
I have new several questions.
Q1. upvalue is available on 5.1 too. Why don't you use it for 5.1?
Q2. What is host object of upvalue?
I have to write additional for Q2.
In my understanding, upvalue is generated for each C functions which
registered to Lua, is it right?
So there are different upvalues for different C functions.
if_lua register many C functions (for window/buffer) to Lua.
Those functions expect that upvalue is a same object.
I'm afraid it can't be worked...
Can you point out my understanding is wrong or right?
> I understand the problem, but not the reason for your solution.
For future maintainance (not you nor me).
I like to make source code be easy to read, and represents its logic
directry. ;-)
2012/1/10 Luis Carvalho <lexcarva...@gmail.com>:
> MURAOKA Taro wrote:
>> >> Point of my patch is separeting two tables for its purpose.
>> >> * A table for interned check, it has very short lifetime.
>> >
>> > IMO this is overkill: you are creating a table at every conversion of list
>> > and
>> > dict values and then discarding the table. A simpler solution is to only
>> > intern them while converting the values to Lua. Please see the attached
>> > patch.
>>
>> Because, interned objects are distinuguished by C native pointer
>> as light userdata you know.
>> The C native pointer be able to reused.
>> And when it is reused, there are posibility that its contents are not same.
>> This is a cause of the bug which I pointed out at top of this thread.
>
> I understand the problem, but not the reason for your solution. What do you
> think about mine? I think it's much simpler and efficient. Moreover, see
> below.
>
>> >> * A table to manage lifecycle's buffer/window, it has long lifetime.
>> >
>> > Why do you need a table for that? A simple reference, as it was before,
>> > would
>> > work, no?
>>
>> It is too complicated.
>>
>> Those buffer/window objects are stored in the ENVIRON table twice.
>> Like this:
>>
>> a) env[lightudata] = udata
>> b) env[udata] = true
>>
>> a) is very reasonable, it represent lifetime of the vim's object.
>> If env[lightudata] == nil, that buffer/window is deleted on vim and it
>> is invalid for Lua.
>> This is very simple and reasonable.
>>
>> The problem is b). It is too difficult.
>> Describing what is happen, is difficult too... it releated with cache
>> of interned object.
>>
>> As I wrote, cache of interned objects should have short lifetime.
>> if_lua manages its short lifetime by using "value weak table".
>> It is the reason that the ENVIRON table is marked as "value weak table",
>> and also why b) is required.
>>
>> So, my understanding is like below:
>>
>> 1. Marked ENVIRON table as "value weak table" for interned cache.
>> 2. Reuse the table for managing lifetime of buffer/window (see a).
>> 3. OMG, a) is garbage collected automatically (by "value weak")!
>> 4. Ah we can avoid to be garbage collected when store it as key too (see
>> b).
>>
>> ...it is too complex, isn't it?
>> If buffer/window objects are stored in normal table (not "weak table"),
>> b) is not required.
>
> Ok, (b) was required since the environment table was weak valued, which was
> required for the cache tables for list/dicts. Since by my solution I'm only
> interning lists/dicts temporarily, there is no need for the environment table
> to be weak valued anymore.
>
> I've simplified the code; (b) is not required now. Please check attached
> patch.
>
>> BTW: As Bram wrote, we need some test set for if_lua.
>> Luis, can you wrote those?
>
> It depends on how much work it would entail; unfortunately I don't know if
> I'll have enough time. However, if there's already a testset for some other
> language interface, say, if_python, then it shouldn't be hard to translate the
> testset to if_lua. But I have no idea where to look for these testsets, or
> even how to build one...
>
> Cheers,
> Luis
>
> --
> Computers are useless. They can only give you answers.
> -- Pablo Picasso
>
> --
> Luis Carvalho (Kozure)
> lua -e 'print((("lexcarva...@no.gmail.spam.com"):gsub("(%u+%.)","")))'
>
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
--
MURAOKA Taro <koron.kaor...@gmail.com>
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
