Closed agureev closed 2 months ago
I talked to @agureev and @juped about this. We came up with a strategy for parametrising the Hoon stdlib Nock indices by layer. I will implement this in Juvix:
Kudos to @agureev for taking the initiative (as usual) to solve this problem for Juvix!
As such I'm happy to consider this issue closed.
Great glad to see this work out.
Thanks @agureev.
Also thank you @paulcadman for keeping the issue up to date!
customer: @mariari @paulcadman performer: deadline: estimated: started: actual: completed: confirmed: dependencies:
After discussions with @paulcadman, it is apparent that we have an extra dependency on Hoon in our process of coordination.
In particular: the Node Engineering dept ought to be the one creating an appropriate Nock library to be used in our transaction computations. The code Juvix needs to write is Nock code, of course.
However, Node team does not provide the appropriate library for how to call and define gates with needed functionality in Nock. The closes we have are the
Examples.ENock
module, yet it is incomplete. This makes Juvix folks compute things and indices by hand in the dojo.In other words, the process currently looks like this:
1) Juvix team asks to implement function X 2) Node implements X by writing it in Hoon library and then compiling down to Nock 3) Juvix team know the Hoon implementation but do not know the Nock code for appropriate function. 4) Juvix team uses dojo to check indices and how to do function calling
What the process should be:
1) Juvix team asks to implement function X 2) Node implements X by writing it in Hoon library and then compiling down to Nock 3) Node team writes out all the component of calling X using solely Nock, including it's arm code in the standard library environment, the API to evaluating it. 4) Juvix team simply copies the needed info from said module and does not do any computations themselves
This will result in a separate module with core functions:
define_core(arm, sample)
which creates a core in standard library environentevaluate_core_with_args(core, args)
this callsNock.nock(core, [9, 2, 10, [6, 1 | args], 0 | 1])
Then for each gate, e.g. for gate
dec
we create a series of functionsdec_arm()
- the logic of the arm in the standard library context, unformatted, e.g. "[8 [9 342 0 2.047] 9 2 10 [6 0 14] 0 2]"dec_arm_core()
- callsdefine_core(dec_arm, 0)
dec_arm_call(arg)
- callsevaluate_core_with_args(dec_arm_core(), arg)