And I have a spare NVMe SSD in this laptop for whatever, including storage experiments
@stuarth we're 101 followers away from stickers, though!
PumpkinDB itself needs a bit of a shakeup. We've got here, but certain things (I think) are begging for a rehaul to move forward
I think abstracting lmdb out would be nice
and I am definitely thinking about making a proper VM/interpreter thing -- because it is not great when PumpkinScript is slow
test script::mod_storage::tests::write_1000_kv_pairs_in_isolated_txns ... bench: 6,806,585 ns/iter (+/- 491,140)
test script::mod_storage::tests::write_1000_kv_pairs_in_isolated_txns_baseline ... bench: 2,587,774 ns/iter (+/- 168,159)
this in particular is pretty... unsatisfying
// Copyright (c) 2017, All Contributors (see CONTRIBUTORS file)
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this
// file, You can obtain one at http://mozilla.org/MPL/2.0/.
pub enum Continuation<'a> {
Instruction(&'a [u8], &'a Continuation<'a>),
// Comparison (TODO: LessThan, GreaterThan)
Equal(&'a [u8], &'a Continuation<'a>),
// Boolean
Not(&'a Continuation<'a>),
// Stack
Swap(&'a Continuation<'a>),
Push(&'a [u8], &'a Continuation<'a>),
Dup(&'a Continuation<'a>),
// Control flow
While(&'a Continuation<'a>, &'a Continuation<'a>),
Halt,
}
#[cfg(test)]
mod tests {
use super::Continuation::*;
#[test]
fn test() {
// [SAVE] 10 TIMES:
let prog0 = Push(b"representation for [SAVE]", &Push(&[10u8], &Instruction(b"TIMES", &Halt)));
let prog1 = Push(b"representation for [SAVE]", &Push(&[10u8],
&Dup(&Equal(&[0u8], &Not(
&While(&Instruction(b"UINT/DEC",
&Swap(&Dup(&Instruction("EVAL", &Swap(&Dup(&Equal(&[0u8], &Not(&Halt)))))))), &Halt))))));
}
}
here,
EVAL would try to avoid re-interpreting [SAVE] by simply caching the Continuation derived for it
I played with
Cond instead of While at first but it proved to be difficult
so I thought
While can be seen as a higher level generalization (one can imagine implementing IF through While)
side-thought: it would look like we'd need to compile programs backwards for this (from
Halt to the first Push)
and we'll need to use an arena to store continuations, perhaps
thinking
#[derive(Debug)]
pub enum Continuation<'a> {
Instruction(Vec<u8>, &'a Continuation<'a>),
// Comparison (TODO: LessThan, GreaterThan)
Equal(Vec<u8>, &'a Continuation<'a>),
// Boolean
Not(&'a Continuation<'a>),
// Stack
Swap(&'a Continuation<'a>),
Push(Vec<u8>, &'a Continuation<'a>),
Dup(&'a Continuation<'a>),
// Control flow
If(&'a Continuation<'a>, &'a Continuation<'a>),
Defer(&'a Continuation<'a>, &'a Continuation<'a>),
Yield,
Undefer(&'a Continuation<'a>),
Halt,
}
migrating the engine is going to be one massive undertaking :D
right now VM actually encapsulates the stack
theoretically, this can be extracted and VM can be much more of a pure CPS (continuation passing style) thing where the state (which would be containing the stack) would be passed between continuations
in theory, this would have allowed for the widest possibilities for developing other languages
that said, for these languages to benefit from the engine, they'd need to communicate with all the functionality in the engine
if the engine function is to be only available through primitive operations, then we'd need to connect that language to PumpkinScripts primitives anyway, and that sort of decreases the utility of the whole idea
another way to do this is rewrite the core of the engine in such a way that all actual functionality of the engine is available through standard Rust APIs
and then languages focus on 1) implementing language primitives and 2) connecting to these APIs
this would also mean a fairly major rewrite of many PumpkinDB components
which is not a bad thing on its own... just a big undertaking
should it be 0.3?
i was thinking if pumpkinDB could be a storage backend as git like model?
also i found you github has a java port, so i ask if there's python port?
