@widgets for extension functions of Table may not be found
#6955
Comments
|
The method is an extension in the Database module. When the IDE calls through it call with the type and module name correctly and gets passed onto |
|
What is the program to test on? What shall I search for in that program? I tried to create something, but it doesn't work:
|
Looks like a typo in |
|
Also note that the |
|
Thank you for spotting the typo. I got over it. Now I cannot use
What's your import statement? I have no idea how you code works. I had to: enso$ git diff
diff --git distribution/lib/Standard/Visualization/0.0.0-dev/src/Main.enso distribution/lib/Standard/Visualization/0.0.0-dev/src/Main.enso
index 7dbda46d96..ca56cf6f68 100644
--- distribution/lib/Standard/Visualization/0.0.0-dev/src/Main.enso
+++ distribution/lib/Standard/Visualization/0.0.0-dev/src/Main.enso
@@ -9,3 +9,6 @@ from project.File_Upload export file_uploading
export project.Id.Id
export project.Helpers
+import project.Widgets
+export project.Widgets
+I wish bugreports had simple steps to reproduce. But I think I see the problem now. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-07): Progress: - failed to reproduce: #6955 (comment)
Next Day: Bugfixing & Runtime Type Checks
|
|
This is a dirty fix: enso$ git diff engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/GetAnnotationNode.java
diff --git engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/GetAnnotationNode.java engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/GetAnnotationNode.java
index bbd28da286..efc90d9e26 100644
--- engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/GetAnnotationNode.java
+++ engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/GetAnnotationNode.java
@@ -1,7 +1,16 @@
package org.enso.interpreter.node.expression.builtin.meta;
+import com.oracle.truffle.api.CompilerDirectives;
+import com.oracle.truffle.api.Truffle;
+import com.oracle.truffle.api.dsl.Cached;
+import com.oracle.truffle.api.dsl.Specialization;
+import com.oracle.truffle.api.frame.FrameInstance;
+import com.oracle.truffle.api.frame.VirtualFrame;
+import com.oracle.truffle.api.library.CachedLibrary;
+import com.oracle.truffle.api.nodes.Node;
import org.enso.interpreter.dsl.BuiltinMethod;
import org.enso.interpreter.node.BaseNode;
+import org.enso.interpreter.node.EnsoRootNode;
import org.enso.interpreter.node.callable.thunk.ThunkExecutorNode;
import org.enso.interpreter.node.expression.builtin.text.util.ExpectStringNode;
import org.enso.interpreter.runtime.EnsoContext;
@@ -13,12 +22,6 @@ import org.enso.interpreter.runtime.library.dispatch.TypesLibrary;
import org.enso.interpreter.runtime.scope.ModuleScope;
import org.enso.interpreter.runtime.state.State;
-import com.oracle.truffle.api.CompilerDirectives;
-import com.oracle.truffle.api.dsl.Cached;
-import com.oracle.truffle.api.dsl.Specialization;
-import com.oracle.truffle.api.frame.VirtualFrame;
-import com.oracle.truffle.api.library.CachedLibrary;
-
@BuiltinMethod(
type = "Meta",
name = "get_annotation",
@@ -43,6 +46,15 @@ public abstract class GetAnnotationNode extends BaseNode {
Type targetType = types.getType(target);
ModuleScope scope = targetType.getDefinitionScope();
Function methodFunction = scope.lookupMethodDefinition(targetType, methodName);
+ if (methodFunction == null) {
+ methodFunction = Truffle.getRuntime().iterateFrames((FrameInstance fi) -> {
+ if (fi.getCallNode() instanceof Node call && call.getRootNode() instanceof EnsoRootNode ensoRoot) {
+ return ensoRoot.getModuleScope().lookupMethodDefinition(targetType, methodName);
+ } else {
+ return null;
+ }
+ });
+ }
if (methodFunction != null) {
String parameterName = expectStringNode.execute(parameter);
Annotation annotation = methodFunction.getSchema().getAnnotation(parameterName);at least with this fix I get proper result from: from Standard.Base import all
from Standard.Base.Data.Boolean import Boolean
from Standard.Base.Data.Text.Location import Location
from Standard.Database.Connection import Connection_Details
from Standard.Table import all
from Standard.Database import all
from Standard.AWS import all
from Standard.Visualization import Widgets
main =
operator17 = Database.connect (SQLite location=In_Memory)
operator18 = Table.new [ ["Y", ['a', 'b', 'c']] ]
operator19 = operator18.select_into_database_table operator17 temporary=Boolean.True
operator20 = Widgets.get_widget_json operator18 "select_into_database_table" [ "primary_key" ]
operator20 |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-08): Progress: - dirty "fix" found for #6955 (comment)
Next Day: Bugfixing & Runtime Type Checks
|
JaroslavTulach
changed the title
TableTable may not be found
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-09): Progress: - test cases for
Next Day:
|
|
Jaroslav Tulach reports a new STANDUP for the last Saturday (2023-06-10): Progress: - automatic conversions of arguments: #7009
Next Day: Meta.get_annotations
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-12): Progress: -
Next Day: Meta.get_annotations |
|
Jaroslav Tulach reports a new 🔴 DELAY for yesterday (2023-06-14): Summary: There is 7 days delay in implementation of the @widgets for extension functions of Still investigating Delay Cause: The issue crosscuts all the layers we have IDE, LS, compiler. I am still investigating what the proper solution should be. Design and discussion with owners of other parts of the system needed. Possible solutions: The most promising solution right now seems to be to let |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-18): Progress: - Saturday & Sunday coding
Next Day: Meta.get_annotations |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-19): Progress: - debugging
Next Day: Meta.get_annotations |
|
I am trying new approach to propagate the The state is lost in |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-20): Progress: -
Next Day: Meta.get_annotations
|
|
Jaroslav Tulach reports a new 🔴 DELAY for yesterday (2023-06-21): Summary: There is 7 days delay in implementation of the @widgets for extension functions of Got it working somehow Delay Cause: Possible solutions: Take a shortcut, integrate what we have right now. Or investigate better fix. Let's investigate. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-21): Progress: - got
Next Day: Meta.get_annotations |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-22): Progress: - organisation issues: https://discord.com/channels/401396655599124480/1120986567570370651/1121456406915198976
Next Day: Meta.get_annotations
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-23): Progress: - breakthru in
Next Day: Get reviews and QA for
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-26): Progress: - addressing Adam's & Pawel's comments: 15b9639
Next Day: Finish
|
Fixes #6955 by: - using `visualisationModule` to specify the module where the visualization is to be used - referring to method in `Meta.get_annotation` with `.method_name` - e.g. unresolved symbol notation - evaluating arguments to `Meta.get_annotation` in the context of the user module (which can access the extension functions)
github-project-automation
bot
moved this from 👁️ Code review
to 🟢 Accepted
in Issues Board
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-06-27): Progress: - Merged: #7115
Next Day: Investigate performance of node changes
|
As experienced in #6925, the
primary_keyannotation onselect_into_database_tableoperation seems to be not registered.Actual behaviour
The widget on
primary_keyis a Vector Editor but it only allows to add aNothing, not the actual column names as expected. CheckingWidgets.get_widget_jsonwe can see that the annotation for@primary_keyseems to not be applied for some reason.Expected behaviour
The
"primary_key"widget JSON should not benull- it is defined to beWidget_Helpers.make_column_name_vector_selector.The above should then allow the vector editor to display the proper column selector dropdown.
Context
We checked if this may be due to the fact that
select_into_database_tablewas defined on renamed types:but we split the extensions file into separate versions for in-memory and Database Tables, allowing to get rid of the renames and the issue persisted, so it is probably something else.
The text was updated successfully, but these errors were encountered: