Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Howto:Serializing Nasal data structures

From FlightGear wiki
Revision as of 16:14, 12 August 2017 by Hooray (Talk | contribs) (Created page with "{{Stub}} == Objective == == Background == Nasal's hash syntax is already close enough to JSON that Nasal could even serialie a property tree without requiring much work, ana...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.

Objective

Background

Nasal's hash syntax is already close enough to JSON that Nasal could even serialie a property tree without requiring much work, analogous to props.getValues() which is already traversing a property tree node and which turns it into a Nasal data structure (hash).

[1]


Another possibility would be using a subset of JSON, i.e. to serialie/unserialize Nasal data structures as scalars, vectors and hashes - which should be pretty straightforward. The format would then be plain text, and it would just be evaluated via Nasal's compile()/call() APIs to turn data structures back into Nasal types.[2]

you could then also directly use io.load_nasal() to load a Nasal file from disk (think mydata.nas) and for serialiation purposes, write to the same file - just make sure that it is valid Nasal[3]


depending on how much can be saved using a space-time or time-memory tradeoff, you could compute lookup tables using Nasal vectors/hashes (or both) and serialie those to disk - e.g. using JSON, which is basically equivalent to the syntax used by Nasal. You would basically compute your lookup tables once and then use a nested for-loop to read the lookup tables and serialize/write those to a custom file in $FG_HOME/Export, at that point you can then copy the whole thing into a folder where it can be loaded at runtime using the helpers available in io.nas (using JSON would be much less verbose than using PropertyList/XML, but obviously not as efficient as using a binary serialization format). Basically, this would be equivalent to programmatically creating a complex texture and storing that on disk to save reduce the runtime overhead (treating the texture as a multi-dimensional lookup table). https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff

https://en.wikipedia.org/wiki/JSON[4]


Proof of concept

Nasal Console

var serializeVector = func(vector) {
retVal = "[";
foreach(var item; vector) {
retVal ~= serialize(item) ~ ',';
} 

return retVal~"]";
}

var serializeHash = func(hash) {
var retVal = "{";
foreach(var member; keys(hash)) {
retVal ~= serialize(member) ~ ',';

}

return retVal ~"}";
}


var serialize = func (data) {
var type = typeof(data);
if (type == "scalar") return data;
if (type == "vector") return serializeVector(data);
if (type == "hash") return serializeHash(data);
if (type == "ghost" or type == "func") return "";
die("cannot serialize unsupported data type:", type);
} 

var myVector = [];

for (var i=0;i<=40;i+=1) {
append(myVector,[i, i*i]);
}



# debug.dump(myVector);

var serialized = serialize(myVector);


# debug.dump(serialized);


var compiled = compile(serialized);
var result = compiled();
debug.dump(result);


References

References
  1. Hooray  (Oct 9th, 2016).  Re: Why not use Erlang instead of .
  2. Hooray  (Sep 12th, 2015).  Re: String manipulation and file I/O (pm2thread) .
  3. Hooray  (Sep 12th, 2015).  Re: String manipulation and file I/O (pm2thread) .
  4. Hooray  (Aug 12th, 2017).  Re: Space Shuttle .