You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue came up in #4011. Say a user defines a library with function fn and wants to use it in a map. The auxiliary function for chunks in map would also need to run remotely, which means that either it should be added to the library, or be included in the library support code from poncho. When running library functions, their arguments are wrapped in an event json rpc, thus it becomes difficult to compose them.
One solution would be to make the auxiliary functions understand the json rpcs, but that would make further changes to code difficult. Another option is to modify the @remote_execution decorator so that by default it calls the original function, and only calls the version with the rpc json arguments when called like fn.wrapped. With this, only the top call in library_code would use fn.wrapped.
The text was updated successfully, but these errors were encountered:
This issue came up in #4011. Say a user defines a library with function
fn
and wants to use it in amap
. The auxiliary function for chunks in map would also need to run remotely, which means that either it should be added to the library, or be included in the library support code from poncho. When running library functions, their arguments are wrapped in an event json rpc, thus it becomes difficult to compose them.One solution would be to make the auxiliary functions understand the json rpcs, but that would make further changes to code difficult. Another option is to modify the
@remote_execution
decorator so that by default it calls the original function, and only calls the version with the rpc json arguments when called likefn.wrapped
. With this, only the top call inlibrary_code
would usefn.wrapped
.The text was updated successfully, but these errors were encountered: