jengamon / ruwren Goto Github PK

set_slot_new_foreign overwrites slot 0, calling set_slot_new_list(0) then set_slot_new_foreign on a free slot(say 1) and then set_list_elment(0, idx, 1) causes a sigsev (apparently set_slot_new_foreign writes a class on slot 0 so it makes sense). Now of course I can create and populate the list in another slot but there seems to be no way of copying it to slot 0 to return it.
Handles, could solve the issue but are only available through VMWrapper, a foreign function only gets a "VM" which doesn't expose a way to get and set handles.

For example:

unwrapping or panicking in runtime.rs is UB as it crosses the C threshold. Remove these and replace with some kind of defaulting.

The example showed how to access a function handle inside a class, while how do I access a function directly inside a module - if it's possible?

// main.wren
var start = Fn.new {}
var update = Fn.new {}

I could check if they exists using has_variable for main module; then how do I use make_call_handle to access the functions? The slot id also is confusing for me, I didn't find any instruction how they are used from wren official.

I have a class like this

class MyClass {
  foreign static api(result);
  static call(){
     api("result data") // call the foreign function
  }
}

Is there an API to do something like this?

fn api_function(vm:&VM){
   // do stuff with data
}

/// macro to generate a wren foreign function 
create_foreign_function!{
  static(fn "MyClass.api", 1) api_function
}

Are statics as they are currently implemented useful?

They are not allowed to access the instance they are defined on, leaving them without any space to store data between calls, whiel in Wren you have the class that can take data.

Should we reimplement statics to work exactly how instance functions work? (Thus statics simply becoming a difference in how to access from the Wren side rather than anything being different on the Rust side.)

Each time I call vm.get_map_count() I get random number like Some(712005920) but I am expecting 1 as value, because the value is expected to be {"sum": 3}

I have a wren class like this

class Component {
    static process(input){
        if(input["left"] != null && input["right"] != null){
            var sum = input["left"] + input["right"]
            var result = {"sum": sum}
            my_foreign_api.send(result) // send result to rust backend
        }
    }
}

 fn send(vm: &VM) {
       let count = vm.get_map_count();
       println!("{:?}", count); // <= I need to know the size of the map
}

Upstream Wren has added a Map API, so once they bump their version, we should add the Map slot API too, cuz it's convenient.

Besides the module loader always returns None, I'm thinking something like:

pub struct DefaultLoader {
    source_dir: &str,
}
impl DefaultLoader {
    pub fn new() -> DefaultLoader {
        DefaultLoader { source_dir: "." }
    }
    pub fn source_dir(&mut self, source_dir: &str) -> &mut Self {
        self.source = source_dir;
        self
    }
}
impl ModuleScriptLoader for DefaultLoader {
    fn load_script(&mut self, module: String) -> Option<String> {
        use std::fs::File;
        use std::io::Read;
        use std::path::Path;

        // Look for a file named [module].wren.
        let mut name_path = Path::new(self.source_dir).join(&module);
        name_path.set_extension("wren");

        let mut buffer = String::new();

        let result = File::open(&name_path).map(|mut f| f.read_to_string(&mut buffer));
        if result.is_ok() {
            return Some(buffer);
        } else {
            None
        }
    }
}

It loads wren scripts from source_dir in hierarchy. So you can do:

main.wren
a.wren
    - lib/
      b.wren

in main.wren:

import "a"
import "lib/b"

Except the part whether using relative current working directory as default. Or more useful, it should load from multiple source directories. Is it good to add in, or we prefer not?

While a lot of the API is meant to resemble that of the Wren API, it's a good idea to just do a documentation pass of the entire library, mainly because of the "magic macros" that remain currently quite undocumented and maybe a bit obtuse (im sorry i mostly just wanted to get things easy and working, so they dont look the prettiest), and to collate the knowledge that's scattered in the 'examples/' directory.