Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterating over a generator-iterator from a Lua function #243

Open
mfrigerio17 opened this issue Sep 11, 2023 · 0 comments
Open

Iterating over a generator-iterator from a Lua function #243

mfrigerio17 opened this issue Sep 11, 2023 · 0 comments

Comments

@mfrigerio17
Copy link

Ok, this seems convoluted and best illustrated with code that reproduces the problem (Ubuntu 22.04, Python 3.10.12, Lupa 2.0, Lua 5.4)

import lupa
lua = lupa.LuaRuntime(unpack_returned_tuples=True)

luaTable = lua.execute('''return { key1 = "value1" } ''')

class Foo:
    def __init__(self, table):
        self.table = table
        print("Foo():", self.table.key1, "\n")
    
    def getGenerator(self):
        def generator():
            for i in range(1,2):
                print("generator():", self.table.key1, "\n")
                yield i
        return generator()

foo = Foo(luaTable)

# iterate over the generator, prints the right thing
gen = foo.getGenerator()
for i in gen: pass

# using a Lua function to iterate over the generator gives weird result
luaF = lua.execute('''
return function(generator)
  for i in python.iter(generator) do end
end''')

gen = foo.getGenerator()
luaF(gen)

What the code does:

  • create a Lua table, return it into python
  • have a python object that stores the table into self
    • the object returns an iterator-generator that simply prints an element of the table
  • create and run the generator, in python - works fine
  • create and run the generator, via a Lua function - the table is no longer the same

Output:

Foo(): value1 

generator(): value1 

generator(): (<generator object Foo.getGenerator.<locals>.generator at 0x7f4d68a61850>, None, 'value1')

Expected output

Foo(): value1 

generator(): value1 

generator(): value1

When the generator is invoked from within a Lua function (using python.iter) then self.table.key1 mysteriously become a tuple with three elements (<the generator itself>, None, <the actual value>) even though it should just be value1.

Any idea?

mfrigerio17 pushed a commit to mfrigerio17/ctgen that referenced this issue Sep 19, 2023
This is an attempt to simplify the workflow, by avoiding having python
calling lua, calling python, calling lua, etc..

The motivation is also to work around this bug:
scoder/lupa#243

With such purpose in mind, I now use Lua for the generation of the
assignments of the matrix coefficients, rather than Python.

This change breaks the existing code generation backends.
mfrigerio17 pushed a commit to mfrigerio17/ctgen that referenced this issue Oct 26, 2023
This is an attempt to simplify the workflow, by avoiding having python
calling lua, calling python, calling lua, etc..

The motivation is also to work around this bug:
scoder/lupa#243

With such purpose in mind, I now use Lua for the generation of the
assignments of the matrix coefficients, rather than Python.

This change breaks the existing code generation backends.

Also, the code now requires the language-specifics to have an
explicit function to turn a sympy expression into text.
This is used instead of the naive call to Sympy's __str__,
to give the backend more chances for customization.

For example, powers in Sympy (Python) are written with '**',
which is not a valid operator in other languages like C.
Therefore, simply using __str__ would cause invalid code to
be generated.
mfrigerio17 pushed a commit to mfrigerio17/ctgen that referenced this issue Apr 30, 2024
This is an attempt to simplify the workflow, by avoiding having python
calling lua, calling python, calling lua, etc..

The motivation is also to work around this bug:
scoder/lupa#243

With such purpose in mind, I now use Lua for the generation of the
assignments of the matrix coefficients, rather than Python.

This change breaks the existing code generation backends.

Also, the code now requires the language-specifics to have an
explicit function to turn a sympy expression into text.
This is used instead of the naive call to Sympy's __str__,
to give the backend more chances for customization.

For example, powers in Sympy (Python) are written with '**',
which is not a valid operator in other languages like C.
Therefore, simply using __str__ would cause invalid code to
be generated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant