urbit/arvo

Unexpected results when generator source files revert to previous versions

jfranklin9000 opened this issue · 1 comments

Create gen.hoon

|=  a=@  ~&  %one  a

+gen ~ gives: (expected)

%one
> +gen ~
0

Edit gen.hoon

|=  a=@  ~&  %one  ~&  %two  a

+gen ~ gives: (expected)

%one
%two
> +gen ~
0

Edit gen.hoon to previous version

|=  a=@  ~&  %one  a

+gen ~ gives: (unexpected, missing sigpad output)

> +gen ~
0

Edit gen.hoon to another previous version

|=  a=@  ~&  %one  ~&  %two  a

+gen ~ gives: (unexpected, missing sigpad output)

> +gen ~
0

Edit gen.hoon

|=  a=@  ~&  %one  ~&  %two  ~&  %three  a

+gen ~ gives: (expected)

%one
%two
%three
> +gen ~
0

Also, the syncs seem to take longer when going back to a previous version of the file.

This is intended behavior. You're seeing the Ford cache kicking in. If you build and run something twice, Ford will use the cached version the second time.

~& and all other runes beginning with ~ are hints to the runtime that can't affect the result of evaluating Nock, so there's no guarantee that they'll be executed. Similarly, there's no requirement that Ford has to replay the hints from code it's already run.

~& should really only be used for debugging and logging. For console user interaction, use the "sole" library. Datatypes are defined in sur/sole.hoon and functions in lib/sole.hoon. This isn't well documented, unfortunately, but you can see examples of use in app/dojo.hoon.

The overall idea is that we send moves (effects) to the Hood app -- see lib/hood/helm.hoon -- which maintains the linkages between apps and the console, so that only the "active" app's moves get relayed to Dill and out to Unix. Hitting Ctrl-X to switch from, say, Dojo to Talk, changes that active app.