@socketsupply/ltp - npm Package Compare versions

Comparing version 2.2.1 to 2.3.1

generate.js

		@@ -145,3 +145,3 @@ var path = require('path')
		if(field.isLength) {
		s += encode_direct(field, def_freep, Cast(Type(direct), PtrSub(free, buf, field.offset\|0)))
		s += encode_direct(field, def_freep, Cast(Type(direct), PtrSub(free, PtrAdd(buf, field.offset\|0))))

		@@ -148,0 +148,0 @@ ops_direct.push(Call(encode(field), [buf, free]))

generators/zig.js

		@@ -6,2 +6,6 @@ var map = {

		buffer_u8: '[*] u8',
		buffer_u16: '[*] u8',
		buffer_u32: '[*] u8',

		fixed_4: '*[4]u8',
		@@ -45,7 +49,8 @@ fixed_8: '*[8]u8',
		var last = statements.pop()
		return `export fn ${name} (${args.filter(Boolean).join(', ')}) ${type} {\n ` +
		return `pub export fn ${name} (${args.filter(Boolean).join(', ')}) ${type} {\n ` +
		[...statements, (type!='void'?'return ': '')+ last].join(';\n ')+';\n}\n'
		}
		function PtrAdd (...args) {
		return '(' + args.join(' + ') + ')'
		var [first, ...rest] = args.filter(Boolean)
		return '(' + first + rest.map(e => e < 0 ? ' - '+Math.abs(e) : ' + '+e).join('') + ')'
		}
		@@ -52,0 +57,0 @@ function PtrSub (...args) {

package.json

		{
		"name": "@socketsupply/ltp",
		"version": "2.2.1",
		"version": "2.3.1",
		"description": "A schemaful parseless binary format, like a simpler version of captnproto. fast access to fields without allocating memory",
		@@ -5,0 +5,0 @@ "main": "index.js",

README.md

		# ltp

		A high performance, readable, and maintainable, in-place encoding format.
		ltp is a parseless copyfree binary encoding format.
		This means that you can read a field out of ltp encoded data without

		An "in-place" format is designed so that you can read out individual
		fields without needing to a) examine every byte, and b) without needing to
		create a data structure.
		a) inspecting every byte.
		b) going through a complicated state machine.
		c) creating another in memory data structure.

		it's inspired by capt'n'proto, but much simpler.

		## Motivation

		High performance and simplicity usually go together. We often think of high
		performance as "more power". With, for example, a car, you can put in a larger
		performance as "more power". To make a car go faster, you can fit a larger
		engine and burn more fuel, faster. But with software, that's wrong. To make
		@@ -17,2 +20,3 @@ software faster you can only take away unnecessary work. Often, something
		unnecessary work. We also like simplicity because it makes it _faster to understand_.
		(again, because you don't have to understand the unnecessary parts)

		@@ -22,10 +26,15 @@ A format such as JSON may appear simple, because it is so familiar.
		One aspect of the work is examining each byte in the input, switching between
		states, escaping characters, etc. Another significant aspect is transforming the
		flat bytes into a data structure, (which means the garbage collector must get
		involved) Often, we parse a json object, and then only access one or two fields.
		states that represent escape characters, nesting level, etc.
		Another significant aspect is transforming the flat bytes into a data structure,
		(which means the garbage collector must get involved) Often, we parse a json object,
		and then only access one or two fields, but to do that we recreated another representation
		of the object as a data structure in memory, then threw it away.

		That's not environmentally friendly!

		If there are a lot of data moving through the system this parsing and data
		structure building can be very significant. People say that the JSON parsing
		libraries built into your system are well optimized, and are fast. They may well
		be fast compared to other JSON libraries, but they still include a lot of
		uncessary work.
		be fast compared to other JSON libraries, or to other encoding formats based around the same idea,
		but they still include a lot of uncessary work.

		@@ -35,3 +44,3 @@ `ltp` can be pronounced like "litup" or LTP. The joke was that it's "lieutenant

		## generating code
		## Generating Code

		@@ -79,3 +88,3 @@ ltp can currently generate code in C and Zig.

		## Fixed vs variable size fields
		## Fixed vs Variable size fields

		@@ -140,3 +149,3 @@ Your basic primitives: numbers, boolean, are always the same size.

		## Schema data structure
		## Schema Data Structure

		@@ -143,0 +152,0 @@ To understand what sort of things ipb can represent, it's helpful to understand

headers/ltp.zig