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
> For instance, in the foo/bar scenario, where foo is an empty package but has a native implementation defined in imports.go, and bar is a standard package containing gno files. Previously, this would have triggered a panic on foo import due to the empty package name rather than appropriately using the native foo fallback.
The panic is expected behavior. We do not want to change it.
for foo/bar, only one package node created. pn.Name = bar pn.PkgPath = gnoland/xxx/foo/bar.
No package node is created for foo.
Try to inject native method at foo should should panic in stdlibs/stdlib.go ( for on chain ) and tests/import.go ( for off chain testing).
The native method can only be injected in a valid PackageNode.
Hello @Kouteki Is this still necessary ?
I was looking and the historic and would like to take a look but before I wanted to be sure that it is still needed thanks 👍
The panic is expected behavior. We do not want to change it.
for foo/bar, only one package node created. pn.Name = bar pn.PkgPath = gnoland/xxx/foo/bar.
No package node is created for foo.
Try to inject native method at foo should should panic in stdlibs/stdlib.go ( for on chain ) and tests/import.go ( for off chain testing).
The native method can only be injected in a valid PackageNode.
Originally posted by @piux2 in #1076 (comment)
The text was updated successfully, but these errors were encountered: