Instrumentation, visualization and autoscoped constructors

[JaroslavTulach]

Pull Request Description

So far reproduces and later will fix #9381.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.

[JaroslavTulach]

The here-in provided changes are not 100% correct. They seem to deliver some instrumentation events, but probably there are corner cases when they don't work well. Anyway, there are some events generated, so hopefully @4e6 can investigate what to do with ProgramExecutionSupport even at current state.

[4e6]

The issue here is that in case of expression

..Cons

first, the instrumentation sees the UnresolvedSymbol node, and reports it as an expression update, and then it sees the FunctionCallInstrumentationNode wrapper containing the method pointer information

It should be the opposite, like, for example, it is done for suspended arguments. First, the instrumentation should see the FunctionCallInstrumentationNode wrapper to capture the method pointer, and then the result of the underlying expression (the UnresolvedSymbol in this case).

[JaroslavTulach]

... the instrumentation sees the UnresolvedSymbol node, and reports it as an expression update, and then it sees the FunctionCallInstrumentationNode wrapper containing the method pointer information. It should be the opposite ...

I am afraid I cannot revert the order easily. Let's do some pair debugging to find out what can be done. Thank you for your investigation.

[enso-bot]

Dmitry Bushev reports a new STANDUP for yesterday (2024-03-25):

Progress: Started working on the issue. Debugging the simple case with the autoscope constructor without the arguments. Debugging the execution support logic to see what happens to function call wrapper after it is captured by the instrumentation It should be finished by 2024-03-29.

Next Day: Next day I will be working on the #9452 task. Continue working on the task

[enso-bot]

Dmitry Bushev reports a new STANDUP for today (2024-03-26):

Progress: Continue working on the issue. Debugging the case with the suspended arguments. Found out that the wrapped value should also be instrumentable. Trying to enable the instrumentation for the value wrapped in the function call instrumentation node. It should be finished by 2024-03-29.

Next Day: Next day I will be working on the #9452 task. Continue working on the task

[4e6]

Autoscope constructor

The instrumentation of autoscope argument currently works this way

type T
    A
    B x
    C y z

main =
    a = test ..A
    a

test t:T = t

The IdExecutionInstrument sees the following calls:

onEnter (UnresolvedConstructor)
onReturnValue (UnresolvedConstructor) // sends expression update
onEnter (FunctionCallInstrumentationNode)
onReturnValue (FunctionCallInstrumentationNode) // captures method pointer

First, it enters the UnresolvedConstructor, and in the onReturnValue (UnresolvedConstructor) it sends the expression update. Then it enters the wrapper node and the onReturnValue (FunctionCallInstrumentationNode) contains the method pointer. But the expression update is already being sent.

Constructor passed as a lazy argument

Here is the updated program that instruments normal constructor call T.A being a lazy argument of the method test ~t:T = t

type T
    A
    B x
    C y z

main =
    a = test T.A
    a

test ~t:T = t

In this case the IdExecutionInstrument sees the following calls:

onEnter (ApplicationNode) // T.A
onEnter (FunctionCallInstrumentationNode) // entering the wrapper
onReturnValue (FunctionCallInstrumentationNode) // capturing the method pointer
onReturnValue (ApplicationNode) // sends expression update containing the method pointer captured earlier

In this case the instrument sees the onReturnValue (FunctionCallInstrumentationNode before the onReturnValue (ApplicationNode) and is able to capture the method pointer info before sending the expression update.

[enso-bot]

Dmitry Bushev reports a new STANDUP for yesterday (2024-03-27):

Progress: Continue working on the issue. Added the ydoc-server FFI interface for Java. Fixed vite build broken by the webpack dependency. Debugging the function call instrumentation node for the suspended arguments. It should be finished by 2024-03-29.

Next Day: Next day I will be working on the #9452 task. Continue working on the task

[enso-bot]

Dmitry Bushev reports a new STANDUP for yesterday (2024-03-28):

Progress: Continue working on the yjs. Replaced webpack with the Vite build. Added ydoc-server bundled artifact to the Vite output. Started working on adding conditional ffi import. It should be finished by 2024-03-29.

Next Day: Next day I will be working on the #9452 task. Continue working on the task

[enso-bot]

Dmitry Bushev reports a new STANDUP for yesterday (2024-03-29):

Progress: Continue working on the issue. Updated the ydoc-server FFI interface. Implemented the bundle assembly for the Java server. Tried to make the conditional build that would switch between java and wasm interfaces. It should be finished by 2024-03-29.

Next Day: Next day I will be working on the #9452 task. Continue working on the task

[JaroslavTulach]

The instrumentation of autoscope argument currently works this way

@4e6, I am turning your examples into test cases in 4eb9494.

[JaroslavTulach]

@4e6, after 1a13084 I am green on:

[info] - should send method pointer updates of constructors (24 milliseconds)
[info] - should send method pointer updates of simple_suspended_constructors (27 milliseconds)
[info] - should send method pointer updates of simple_autoscoped_constructors (19 milliseconds)
[info] - should send method pointer updates of autoscope constructors (23 milliseconds)

the only failing test is should send method pointer updates of partially applied autoscope constructors, can you take a look Dmitry? Can we chat?

[JaroslavTulach]

Right now there are two failures:

• RuntimeServerTest send method pointer updates of partially applied autoscope constructor
• RuntimeVisualizationsTest visualize autoscoped atomconstructor

33d8b6f addresses the RuntimeVisualizationsTest failure. 08043f6 adjusts the RuntimeServerTest expectations.