mal.haza.website

Test driven development

test("write and read a soul relation with state is ok", (t, done) => {
  radisk("key", [{"#": "soul"}, 1234])
  setTimeout(() => {
    assert.deepEqual(puts, {
      "!": '\x1F+0\x1F#\x1F"key\x1F=\x1F#soul\x031234\x1F\n',
    })
    done()
  }, 10)
})


I noticed some typos after my first commit to Holster and wondered how they didn't get picked up. A lot of the current code is copied over from Porting Gun, so I'm still working out how it all works and was genuinely curious why it hadn't caused errors.

The typo was in a utility function that checks if an object is a soul relation (fixed version):
// Check if an object is a soul relation, ie {'#': 'UUID'}
const rel = {
  is: value => {
    if (value && value["#"] && !value._ && obj.is(value)) {
      let o = {}
      obj.map(value, map_soul, o)
      if (o.id) return o.id
    }

    return false
  },
  // Convert a soul into a relation and return it.
  ify: soul => obj.put({}, "#", soul),
}


But why hadn't it caused any errors? Turns out it was called in Radisk.encode(), but only if it was passed an object, and it wasn't. Radisk is called by store, but it was using JSON.stringify to store a value and it's state as an array, so Radisk was only receiving strings! So now besides the original typo, I'm wondering why I can't just store the array and not use JSON in store.js. That led to updating the file format to include state, which explains the test at the start of this post!

Announcing Holster

I hope that what I've written previously shows I'm excited and positive about applications written using Gun. Unfortunately though, I think we need to take a couple of steps back before we can create production ready distributed applications.
 

What needs work

My feed processing software is adding new feed items to Gun every hour. Unfortunately there's an intermittent problem where data isn't written to disk and there are no acknowledgements from Gun.
 
I've avoided using Lex because it doesn't work with userspace. Lex is a great idea, but it's only useful to me if it also works with user data.
 
Yson parsing doesn't work. The parser cannot accurately create a JavaScript object from a given string, which is required by radisk to split files. It currently corrupts the database and so I haven't used it for rsstream.
 
I've already fixed other bugs in Gun and know that the current state of the code base is very difficult to work on. This is not to take anything away from the idea of Gun and the fantastic work Mark and the team have done to bring it to reality.
 

Announcing Holster

Gun feels too dangerous to use right now, so I need something more contained... I'm starting with something very simple, based on github.com/gundb/port which Mark helpfully walks through in gun.eco/docs/Porting-GUN.

Holster is a fork of that code base along with updates from github.com/amark/gun that were required to fill some gaps and get some initial tests passing.
 
I've avoided problems with the unbuild tool by targeting just the node.js version and using webpack to build the browser version. I don't think Holster will end up looking much like Gun, but I'm hoping to keep pulling in features that make sense. As Mark has mentioned, the chaining API makes the current code base very complicated so will probably leave that out. The main priority will be that the current automated tests keep passing, and are added to, as development continues.
 
I've tried to make the code base easier to read and follow so that development is easier to pick up. If you're interested in working on this with me please reach out! The initial version is available at github.com/mblaney/holster