Displaying 3 results from an estimated 3 matches for "mp_obj".
Did you mean:
tmp_obj
2008 May 13
0
[LLVMdev] Python bindings available.
...) was that the concept of the ownership
of the module getting transferred to the module provider was not reflected
in the design. Initially, there was a module, which owned a LLVMModuleRef:
module_obj has-a LLVMModuleRef
After transferring ownership to the module provider, the situation becomes:
mp_obj has-a LLVMModuleProviderRef
mp_obj has-a module_obj
module_obj belongs-to-a mp_obj
and also:
LLVMModuleProviderRef has-a LLVMModuleRef
All relations are necessary to satisfy the use cases. The only way for the
module_obj to get the LLVMModuleRef *should* be via
mp_obj->LLVMModuleProviderRef-&g...
2008 May 13
2
[LLVMdev] Python bindings available.
On 2008-05-13, at 02:12, Mahadevan R wrote:
>>> That's not how the object works...
>
> Gordon, I think I can make it work if we have the following additional
> function in LLVM-C:
>
> LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) {
> return wrap(unwrap(MP)->getModule());
> }
Can I ask, how general is your solution? I only intended to use this
2008 May 13
2
[LLVMdev] Python bindings available.
...getting transferred to the module provider was not
> reflected
> in the design. Initially, there was a module, which owned a
> LLVMModuleRef:
>
> module_obj has-a LLVMModuleRef
>
> After transferring ownership to the module provider, the situation
> becomes:
>
> mp_obj has-a LLVMModuleProviderRef
> mp_obj has-a module_obj
> module_obj belongs-to-a mp_obj
>
> and also:
> LLVMModuleProviderRef has-a LLVMModuleRef
>
> All relations are necessary to satisfy the use cases. The only way
> for the
> module_obj to get the LLVMModuleRef *shoul...