lord / anchors Goto Github PK

right now it actually will re-run entire calculations even if a cutoff said the value didn't change, which is really silly. if nodes can determine if their parent actually changed value, they should be able to skip a lot of these wasted cycles

perhaps only solution is a new combined map/eq cutoff node

• 'manually monomorphize' like have map, bind, etc be enum variants and actual anchorinner implementations? not sure if this will actually be faster
• could have implementing anchorinner just be fundamentally unsafe. since it's really seeming like we can't solve this with a GAT (only actual higher kinded types will work i think) i also think a lot of cloning could be avoided if we have some way to 'lock' and 'unlock' an anchor inner? also can just put unsafe everywhere and have it go faster?

Hey!
Want to start out by saying this is some very cool work!
I've been playing around with the library a little, and came to a point where I wanted to listen for changes when an observed node has changed its inner value.

I wanted to know if there is a mechanism for having a sort of "on change" callback for observed nodes? I tried implementing it myself with closures within the Var struct, but it seemed to bring problems - and im not sure how to implement such a feature the way map and cutoff are implemented :)

Happy new year!

could try some system to keep track of which anchors are actually used in multiple places, and combine runs of single uses into single nodes??

The original version didn't have as many boxes
When I try to dynamically modify/remap the closure for Anchor::map, I made a test,
first, v.push(Box::new(a_watch.map(function.clone()))); many times is OK ,

but when I try to know How many levels can there be , the anchor can 1000 levels but 1200 levels will stack overflow.
So I unthinkingly added a lot of Box .. nothing work :[

I don't know much about Anchor, and rust :p , I think since I have used box, so unless the stack memory is used too many during internal processing of the Anchors library,Or it's the problem about linked-list Drop this
and this

use std::cell::RefCell;

use anchors::singlethread::{Engine, Var};
thread_local! {
    static ENG: RefCell<Engine> = RefCell::new(
        Engine::new_with_max_height(3002)
    );
}

fn main() {
    let a = ENG.with(|e| Box::new(Var::new(1)));
    let aw = Box::new(a.watch());

    let function = Box::new(|x: &i32| x + 1);
    let mut v = Box::new(vec![Box::new(aw.map(function.clone()))]);

    (1..1200).for_each(|i| {
        v.push(Box::new(v[i - 1].map(function.clone())));
    });

    let end = ENG.with(|e| e.borrow_mut().get(&v[1200]));
    // let end2 = engine.get(&c);
    println!("{} ", end);
}

If the history of changes is important, how can I use it to derive the new values? The closest I saw of an accumulator was map_mut, but it loses values in between if I don't poll for changes.

i think this is a lot more memory efficient? idk

I want global access singlethread::Engine, I try like this both can't work:

pub static ENGINE: Mutex = Mutex::new(Engine::new());
////////////////////////////
lazy_static! {
pub static ref ENGINE: Mutex = Mutex::new(Engine::new());
}

so can it static ..?

see rust-lang/rust#44265

could also look into enum of built-in types that are allowed to do this as a workout

    #[test]
    fn foo() {
        use crate::AnchorHandle;
        let graph1 = Graph2::new(10);
        let a = graph1.insert_testing();
        {
            let graph2 = Graph2::new(10);
            let a_guard = graph1.get(a.token()).unwrap();
            let b = graph2.insert_testing_guard();
            a_guard.add_clean_parent(b);
        }
        graph1.get(a.token()).unwrap().drain_clean_parents();
    }

could require graph2 to be a pinned reference, and therefore have a particular lifetime?

one of the differences between a system like anchors/incremental/adapton and things more like noria is that noria has some notion of an 'upquery'. nodes can pass some request to their dependencies (i want the first 10 rows matching this definition), and that query can be modified based on which children

right now our demand info is basically a bool. i wonder if we could modify this system to have statically typed demand types that flow backwards on the graph? or could this be modelled with fn calls?? seems like the current system might not be generic enough to do this, but maybe i'm just not thinking about the problem in the right way.

this whole thing is extremely similar to our Dict type or IncrMap or raph's rope persistent rope stuff, but where maps and filters on those objects can upquery demand information