I want to create this thread to discuss issues with the current program development process in Anoma.
I believe both d2d annoyances (uncertainty of errors in the stack, feedback, etc) and bigger architectural issues (having to use many different systems, writing resource machine transactions is hard etc) would be good to document.
I will post my own personal issues later in the thread
This is a bunch of notes on how I tried to figure out how to write a Juvix application in Anoma.
I have a bit of dusty knowledge on Haskell programming from during uni, but thats it.
I know that to “run” an application, I compile the Juvix code to nockma, and then I submit this to the node with a bunch of parameters that get passed into the main function. I assume that most people who come into contact with Anoma applications for the first time don’t know this. Anoma does not have a traditional computational model.
When I want to see output of the execution of a Juvix program (or nockma program, to be correct) for debugging, I put in traces everywhere that print to console.
What could be done to improve: This is probably not something that can be done in a short time frame, but the holy grail of debugging is obviously a stepping debugger, or even an interactive inspecting debugger, or praise all that is interactive, a reversible debugger. This is not something we can trivially build, because the execution environment of the nockma code is on a node, and not at the client side. Compounding to that is that the execution happens at the level of nock code, and not juvix code.
That being said, it would be nice to have a way for application designers to write a piece of Juvix code, submit it to the node, and in case of error, get back error messages at the level of the juvix code. So not “nock noun cell 123232324 tried 2323232 and failed with jet jam bir bor boo”, but rather “execution in function foo failed at line X”, at least. Maybe even a dump of the environment (similar to what binding() does in elixir), to further inspect things in a juvix repl.
I also don’t understand really well at this point (this is on me) how I can take some values I get back from traces, and use those in the Juvix REPL.
The compiler version of Juvix is a finicky beast. But this is probably due to it being so actively developed. So I’m fine with this.
The compiler warnings/errors in vscode make no sense, sometimes.
After creating my very own spacebuck, I thought I did everything right. I had created the Spacebuck.juvix resource, submitted a transaction, but nothing happened. I expected to see at least 1 resource when I queried for resources on the node, but I didn’t see any.
So now I’m left figuring out why the transaction is submitted, but not creating my resource. I want my spacebuck so bad.
This is tricky, because there is nothing to go on. The Anoma node doesn’t print anything useful (and Juvix app developers will probably not run their own node locally), the Anoma Client request doesn’t return any useful information either.
I am assuming here that all Anoma applications revolve around resources; creating, consuming, transferring them.
The developer documentation could add a section that shows a simple way to list all resources in a very basic way. But, assuming that this would also return an empty list, this would not have helped me figure out the problem.
A convenience API to test whether a transaction has been executed, or when it failed, a way to get back the reason of failure.
This ties in with my explanation of debugging Juvix. An potential API could be, and I know I bring shame to the family, Jeremy forgive me, the future api in JS.
Submitting a transaction returns a handler that can subsequently be used to poll the node “what happened to this transaction?”, or “has this transaction been put in a block already?”.
Not sure if the notion of “in a block” is the right terminology, but you get the idea.
When going through the Dev Docs for Anoma, I did not know how to figure out how to use the mkResource function. The developer docs import a lot of things as “open”, so it’s hard to figure out which lib contains which data structures and functions.
The files you’re writing during reading of the developer docs do not compile. I understand why this is so, but I wanted to try and compile them anyway. I have very little patience when it comes to reading documentation when I want to build something.
Traces are useful to debug, but they are also pretty obscure. I can, for example, add a trace in my Juvix code that prints out a value:
Debug.trace "execution here" >-> ...
This is somewhat useful as it allows you to pinpoint where exactly in the code your program fails. But besides that, you’re on your own. You can go deeper and deeper to figure out where exactly your program fails, but each new trace means:
Base.decode64!(hint) |> Noun.Jam.cue!()That being said, it would be nice to have a way for application designers to write a piece of Juvix code, submit it to the node, and in case of error, get back error messages at the level of the juvix code. So not “nock noun cell 123232324 tried 2323232 and failed with jet jam bir bor boo”, but rather “execution in function foo failed at line X”, at least. Maybe even a dump of the environment (similar to what binding() does in elixir), to further inspect things in a juvix repl.
Once we have stack traces returned, it should in principle be possible to convert the nockma stack traces to Juvix stack traces, provided enough info is included in them (maybe some additional info needs to be stored as hints in compiled functions for this). That would be a first step.
Basically you just need to, when emitting a debug-mode build, emit [11 ["trace" [1 "whatever"]] [...] (wrap the function body) to push “whatever” onto the trace stack (and pop it when we exit that 11); though you can get more precise than just “a function body” if you want. We can come up with a standard together for line and column numbers and other information like that.