setting up pylonsd from zero on win/linux/macos w/o starport dependencies (optimally, from a binary distribution to avoid the go dependency, at least on the win side - doing go stuff on win sucks)
setting up credentials/any post-install environment config to make the thing Work
nice example project w/ a couple of cookbooks and a decent handful (5-6) of recipes interacting in each one, shows off how the modules work (we can adapt the flutter-loud stuff to save some labor, but only to a limited extent, since we need more complexity and a decent number of reusable modules; this is def. gonna be multiple days, but i think it’s really important to provide before we ask people to use these tools)
get together w/ someone who isn’t plugged into this project rn, try to make sure they can actually follow the documentation and deploy a project before we provide it to external consumers
Problem Definition
The DevTool is not ready for external consumption. The fact that you have to have the pylons node installed on your system to run it sucks, and the lack of any features for modularity/reusability means even very simple recipe systems like the current flutter-loud ones can be miserable to debug and consistency check.
Even if something nicer would be out of scope, it'd be well worth looking at trying to put a very simple text preprocessor layer in place so you can store common elements as macros and then just include those instead of making sure twelve recipes that include the same item all agree on what that item is by hand.
Proposal
DevTool Rewrite
Tx broadcasting
Recipe validation
Cookbook validation
put init
put validate
put remote
put create
put update
Arguments/substitution for #include macro
Currently, the #include directive supported by the Pylons dev tools splices some JSON directly and unaltered into a document. It’d be significantly more powerful with some basic templating - so that’s what we’re doing.
The #include directive should take an arbitrary number of tokens, separated by single spaces, after the name of the module to include. Each token should be substituted for the appropriate placeholder in the module - if the tokens are red blue green, %0 is replaced with red, %1 is replaced with blue, etc.
Validate command should provide useful errors in the event validation fails due to a module include
At present, if including a module causes a recipe or cookbook to be invalid JSON, it will fail to validate (which is correct) with some sort of weird JSON parse error, because we don’t validate until after macros are expanded.
This makes it difficult to trace the source of validation failures. We should instead identify that the module is the source of the validation failure and, ideally, tell the user what’s wrong with it.
Additional testing for module import/parse
We have one very simple test case for module importing, but we’ve already managed to hit weird behavior that doesn’t occur in the test on our own. We need a big suite of torture tests that do as many horrible things with our macro system as we can think of, so’s to ensure it behaves as correctly as possible.
Create flag on dev update command
Batch updates can be kind of messy at present; there should be a flag for the update command that makes it fall back to creating the recipes in the case where they don’t exist.
Design note for demo app
This is a single-page note (not really a proper design document - demo app is deliberately incredibly simple anyway, doesn’t really warrant a full design document) covering the goals/flow of the demo app.
Design notes, not really a design document:
Goals
a) adapt existing example project as much as possible (don't get too far out in the weeds)
b) minimal, text-based
c) mechanics must be sophisticated enough to show utility of tools - needn't be more than that
map
a) make a character - this is free
b) punch goblins for coins, spend coins on sword
c) slash trolls for shards, spend shards+sword on lv2 sword
d) slash dragon w/ sword, win
complications
a) enemies each deal damage to character - if you hit 0 hp you are Dead - hp can be recovered by resting (one of three time-delay recipes, recovering 25%/50%/100% over 5min/7min/10min)
losing
a) fight a higher-tier foe than your character+gear can handle - you die, lose everything, must restart
b) hit 0 hp during normal combat - you die, lose everything, must restart
recipes
start game
fight goblin (unarmed)
fight goblin (armed)
fight troll (unarmed)
fight troll (armed)
fight dragon (unarmed)
fight dragon (armed)
buy sword
upgrade sword
rest 25
rest 50
rest 100
BE: Demo app recipes --> Recipes outlined in design notes must be built, tested, and created on-chain
FE: Demo app designs --> Front-end for demo app is a simple console application that presents players with a numbered list of options based on current context (ex: 1) fight a goblin 2) rest for a moment 3) rest for a bit 4) rest for a while ) and executes a recipe based on the provided input.
Following completion of the demo app, devtools badly need a refactoring/code quality pass to address both previously outstanding issues and newer kludges resulting from ongoing hotfixes made in the course of dogfooding.
Summary
setting up pylonsd from zero on win/linux/macos w/o starport dependencies (optimally, from a binary distribution to avoid the go dependency, at least on the win side - doing go stuff on win sucks)
setting up credentials/any post-install environment config to make the thing Work
nice example project w/ a couple of cookbooks and a decent handful (5-6) of recipes interacting in each one, shows off how the modules work (we can adapt the flutter-loud stuff to save some labor, but only to a limited extent, since we need more complexity and a decent number of reusable modules; this is def. gonna be multiple days, but i think it’s really important to provide before we ask people to use these tools)
get together w/ someone who isn’t plugged into this project rn, try to make sure they can actually follow the documentation and deploy a project before we provide it to external consumers
Problem Definition
The DevTool is not ready for external consumption. The fact that you have to have the pylons node installed on your system to run it sucks, and the lack of any features for modularity/reusability means even very simple recipe systems like the current flutter-loud ones can be miserable to debug and consistency check.
Even if something nicer would be out of scope, it'd be well worth looking at trying to put a very simple text preprocessor layer in place so you can store common elements as macros and then just include those instead of making sure twelve recipes that include the same item all agree on what that item is by hand.
Proposal
DevTool Rewrite
Arguments/substitution for #include macro Currently, the #include directive supported by the Pylons dev tools splices some JSON directly and unaltered into a document. It’d be significantly more powerful with some basic templating - so that’s what we’re doing.
The #include directive should take an arbitrary number of tokens, separated by single spaces, after the name of the module to include. Each token should be substituted for the appropriate placeholder in the module - if the tokens are red blue green, %0 is replaced with red, %1 is replaced with blue, etc.
Validate command should provide useful errors in the event validation fails due to a module include
At present, if including a module causes a recipe or cookbook to be invalid JSON, it will fail to validate (which is correct) with some sort of weird JSON parse error, because we don’t validate until after macros are expanded.
This makes it difficult to trace the source of validation failures. We should instead identify that the module is the source of the validation failure and, ideally, tell the user what’s wrong with it.
Additional testing for module import/parse
We have one very simple test case for module importing, but we’ve already managed to hit weird behavior that doesn’t occur in the test on our own. We need a big suite of torture tests that do as many horrible things with our macro system as we can think of, so’s to ensure it behaves as correctly as possible.
Create flag on dev update command
Batch updates can be kind of messy at present; there should be a flag for the update command that makes it fall back to creating the recipes in the case where they don’t exist.
Design note for demo app
This is a single-page note (not really a proper design document - demo app is deliberately incredibly simple anyway, doesn’t really warrant a full design document) covering the goals/flow of the demo app. Design notes, not really a design document:
Goals
a) adapt existing example project as much as possible (don't get too far out in the weeds) b) minimal, text-based c) mechanics must be sophisticated enough to show utility of tools - needn't be more than that
map a) make a character - this is free b) punch goblins for coins, spend coins on sword c) slash trolls for shards, spend shards+sword on lv2 sword d) slash dragon w/ sword, win
complications a) enemies each deal damage to character - if you hit 0 hp you are Dead - hp can be recovered by resting (one of three time-delay recipes, recovering 25%/50%/100% over 5min/7min/10min)
losing a) fight a higher-tier foe than your character+gear can handle - you die, lose everything, must restart b) hit 0 hp during normal combat - you die, lose everything, must restart
recipes
BE: Demo app recipes --> Recipes outlined in design notes must be built, tested, and created on-chain
FE: Demo app designs --> Front-end for demo app is a simple console application that presents players with a numbered list of options based on current context (ex: 1) fight a goblin 2) rest for a moment 3) rest for a bit 4) rest for a while ) and executes a recipe based on the provided input.
Following completion of the demo app, devtools badly need a refactoring/code quality pass to address both previously outstanding issues and newer kludges resulting from ongoing hotfixes made in the course of dogfooding.
For Admin Use