Extension of #4 for Classes

This is a low priority task, as procedural macros will most likely be required, and other aspects such as more standard modules and the event loop are more important to complete currently.

Proposed Syntax

#[js_class]
mod Name {
    struct Fields {
        str: String,
        num: u64
    }
    
    #[constructor]
    fn constructor() -> IonResult<Name> {
        Fields {
            str: "",
            num: 0
        }
    }
    
    fn method(#[this] this: IonObject, num: f64) -> IonResult<()> {
        println!("{}", this.str);
        this.set("num", num);
    }
    
    #[get]
    fn get(#[this] this: IonObject) -> IonResult<f64> {
        Ok(this.get("num"))
    }
    
    #[set]
    fn set(#[this] this: IonObject, String str) -> IonResult<()> {
        this.set("str", str);
        Ok(())
    }
}

Issue

Although promises have been implemented, with the addition of the event loop, there is still an issue as native asynchronicity cannot be used. Every promise that is created requires its own native function to be made.

Requirements

• Advanced Understanding of Rust and JavaScript Asynchronous Runtimes
• Understanding of codebase to utilise and enhance APIs

Possible Solution

An API will need to be created that allows Rust Futures to be converted to JavaScript Promises. One possible plan of action is similar to wasm-bindgen, where the future is spawned in a seperate thread, and awaited.

However, this would require a more flexible API for creating promises. Promises currently each require their own native function. Each promise converted from a future would need to be created dynamically. The most effective solution for this would be to allow callbacks for the creation of Promises, but I am unsure of how this could be done.

I've been working on a HTTP module for a while now. I'm just stuck on a few of the API decisions, specifically on how to use the Response to get the data. If you have any other feedback on it, that'd be nice too.

Here's the current API in http.d.ts. <Removed as it is outdated, See below hidden comment>

Currently, different data types cause differently colored output, which (at least in my opinion) is distracting.

~~I would suggest changing the output to always be colored white.~~

based on the other module declaration files this is likely to be a typo @Redfire75369 sorry, while reading the fs module I notice it was declared as assert. Is this an error?

From Ubuntu, zsh, have the current pre-release binary, When i press Ctrl + C 2 times in repl mode i get the following:

> ^C
Press Ctrl+C again to exit.
^Cmozilla::detail::MutexImpl::~MutexImpl: pthread_mutex_destroy failed: Device or resource busy
[2]    12204 segmentation fault (core dumped)  /home/v9/Downloads/spidey/spiderfire repl

Issue

Description

Compilation of spiderfire fails inconsistently on GH Actions during build workflow and when cloning from source.

Examples

GitHub Actions

MacOS build completes successfully Windows and Ubuntu do not successfully build.

Clone & Build (Linux):

Experience similar issue to the issue in the Ubuntu CI build.

Temporary Solution:

Run cargo update to update Cargo.lock's version of mozjs and mozjs_sys

Notes

Refer to issue on rust-mozjs repository for updates

Now you are writing all functions naked for SpiderMonkey. Even Servo does not do that. It uses procedural macro (and WebIDL). Well WebIDL is probably overkill but proc macros...

This is how it could look like:

#[jsfn]
pub fn print(s: String) {
      println!("rust said: {}", s)
}

and it would expend to:

unsafe extern "C" fn print(context: *mut JSContext, argc: u32, vp: *mut Value) -> bool {
    let args = Arguments::new(argc, vp);
    args.rval().set(UndefinedValue());

    if args.len != 1 {
        JS_ReportErrorASCII(context, b"print() requires exactly 1 argument\0".as_ptr() as *const libc::c_char);
        return false;
    }

    println!("{}", to_string(cx, args.value(0).unwrap()));

    return true;
}

It could also be applied for methods (like the one you uses in fs.rs). Something like this is also used in https://github.com/rjs-team/rjs look at js_fn! macro.

here is the logs ``` Fresh cc v1.0.67 Fresh version_check v0.9.3 Fresh glob v0.3.0 Fresh unicode-xid v0.2.1 Fresh autocfg v1.0.1 Fresh pkg-config v0.3.19 Fresh regex-syntax v0.6.23 Fresh rustc-hash v1.1.0 Fresh shlex v0.1.1 Fresh lazy_static v1.4.0 Fresh cfg-if v1.0.0 Fresh same-file v1.0.6 Fresh lazycell v1.3.0 Fresh cfg-if v0.1.10 Fresh peeking_take_while v0.1.2 Fresh unicode-width v0.1.8 Fresh ansi_term v0.11.0 Fresh strsim v0.8.0 Fresh vec_map v0.8.2 Fresh once_cell v1.7.2 Fresh termcolor v1.1.2 Fresh regex v1.4.5 Fresh walkdir v2.3.1 Fresh textwrap v0.11.0 Fresh libc v0.2.89 Fresh memchr v2.3.4 Fresh proc-macro2 v1.0.24 Fresh bitflags v1.2.1 Fresh encoding_rs v0.8.28 Fresh which v3.1.1 Fresh log v0.4.14 Fresh atty v0.2.14 Fresh time v0.1.44 Fresh nom v5.1.2 Fresh libloading v0.5.2 Fresh quote v1.0.9 Fresh num-traits v0.2.14 Fresh libz-sys v1.1.2 Fresh encoding_c v0.9.8 Fresh encoding_c_mem v0.2.6 Fresh clap v2.33.3 Fresh cexpr v0.4.0 Fresh clang-sys v0.29.3 Fresh num-integer v0.1.44 Fresh bindgen v0.53.3 Fresh chrono v0.4.19 Fresh mozjs_sys v0.68.2 (https://github.com/servo/mozjs?rev=82da136c53d7ca7b0b7fe1c5622627036ef31899#82da136c) Fresh mozjs v0.14.1 (https://github.com/servo/rust-mozjs#fe104a26) Compiling spiderfire v0.1.0 (/home/wolfpat/spiderfire) Running rustc --crate-name spiderfire --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=f681912fcf3e37c1 -C extra-filename=-f681912fcf3e37c1 --out-dir /home/wolfpat/spiderfire/target/debug/deps -C incremental=/home/wolfpat/spiderfire/target/debug/incremental -L dependency=/home/wolfpat/spiderfire/target/debug/deps --extern chrono=/home/wolfpat/spiderfire/target/debug/deps/libchrono-33f7dbbd138754ae.rlib --extern clap=/home/wolfpat/spiderfire/target/debug/deps/libclap-02d3490164b7a98c.rlib --extern libc=/home/wolfpat/spiderfire/target/debug/deps/liblibc-92a6ce5a991a67c9.rlib --extern mozjs=/home/wolfpat/spiderfire/target/debug/deps/libmozjs-b5ab7020a62ab304.rlib --extern once_cell=/home/wolfpat/spiderfire/target/debug/deps/libonce_cell-e9da1314ab8fbd82.rlib --extern termcolor=/home/wolfpat/spiderfire/target/debug/deps/libtermcolor-e268ff7bc76f4625.rlib -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs-3ca1e6668fc070d0/out -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs_sys-36dbba0e74ff8ac2/out/build/js/src/build -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs_sys-36dbba0e74ff8ac2/out/build/glue error[E0061]: this function takes 3 arguments but 2 arguments were supplied --> src/runtime/jsapi_utils/eval.rs:103:8 | 103 | if !ModuleEvaluate(rt.cx(), module.handle().into()) { | ^^^^^^^^^^^^^^ ------- ---------------------- supplied 2 arguments | | | expected 3 arguments

error: aborting due to previous error

For more information about this error, try rustc --explain E0061. error: could not compile spiderfire.

Caused by: process didn't exit successfully: rustc --crate-name spiderfire --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -Cembed-bitcode=no -C debuginfo=2 -C metadata=f681912fcf3e37c1 -C extra-filename=-f681912fcf3e37c1 --out-dir /home/wolfpat/spiderfire/target/debug/deps -C incremental=/home/wolfpat/spiderfire/target/debug/incremental -L dependency=/home/wolfpat/spiderfire/target/debug/deps --extern chrono=/home/wolfpat/spiderfire/target/debug/deps/libchrono-33f7dbbd138754ae.rlib --extern clap=/home/wolfpat/spiderfire/target/debug/deps/libclap-02d3490164b7a98c.rlib --extern libc=/home/wolfpat/spiderfire/target/debug/deps/liblibc-92a6ce5a991a67c9.rlib --extern mozjs=/home/wolfpat/spiderfire/target/debug/deps/libmozjs-b5ab7020a62ab304.rlib --extern once_cell=/home/wolfpat/spiderfire/target/debug/deps/libonce_cell-e9da1314ab8fbd82.rlib --extern termcolor=/home/wolfpat/spiderfire/target/debug/deps/libtermcolor-e268ff7bc76f4625.rlib -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs-3ca1e6668fc070d0/out -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs_sys-36dbba0e74ff8ac2/out/build/js/src/build -L native=/home/wolfpat/spiderfire/target/debug/build/mozjs_sys-36dbba0e74ff8ac2/out/build/glue (exit code: 1)

Resolves: #4

This pull request also splits the application into multiple applications.

The addition of this new macro allows easier creation of native functions to reduce boilerplate and chances for type errors. An eventual move to a custom attribute procedural macro is intended, but I lack experience and knowledge in that, so this will do for now.

Example Syntax:

#[js_fn]
fn print(val: String) -> IonResult<()> {
    println!("{}", val);

    Ok(())
}

#[js_fn]
fn log(cx: IonContext, #[varargs] values: Vec<Value>) -> IonResult<()> {
    print_indent(false);
    print_args(cx, values, false);
    println!();

    Ok(())
}

Resolves: #9

The addition of this new procedural macro allows easier creation of native functions to reduce boilerplate and chances for type errors. It currently supports:

• Methods
• Accessors
• Accessors for Public Properties
• Static Methods,
• Static Value Properties
• Static Accessors

Below is an example of code using this macro:

#[ion::js_class]
mod switch {
	use ion::Result;
	use mozjs::conversions::ConversionBehavior::Clamp;

	#[derive(Clone, Debug)]
	pub struct Switch {
		b: bool,
		#[convert(Clamp)]
		pub i: i32,
	}

	impl Switch {
		pub const INT: i32 = 32;
		pub const DOUBLE: f64 = 4.20;
		pub const STRING: &'static str = "SPIDER\0";

		#[constructor]
		fn new(b: bool) -> Result<Switch> {
			Ok(Switch { b, i: 144 })
		}

		fn print(#[this] this: &mut Switch) -> Result<()> {
			eprintln!("SWITCH: {:?}", this);
			Ok(())
		}

		fn switch(#[this] this: &mut Switch) -> Result<()> {
			this.b = !this.b;
			Ok(())
		}

		fn spiderfire() -> Result<String> {
			Ok(String::from("SPIDERFIRE"))
		}

		#[get]
		fn b(#[this] this: &Switch) -> Result<bool> {
			Ok(this.b)
		}

		#[set]
		fn set_b(#[this] this: &mut Switch, b: bool) -> Result<()> {
			this.b = b;
			Ok(())
		}

		#[get]
		fn get_a() -> Result<i32> {
			Ok(Switch::INT)
		}

		#[set]
		fn c(_: bool) -> Result<()> {
			eprintln!("Pranked!");
			Ok(())
		}
	}
}

The rough equivalent of this code in TypeScript would be

class Switch {
	static INT = 32;
	static DOUBLE = 4.20;
	static STRING = "SPIDER";
	
	constructor(b: boolean) {
		self._b = b;
		self._i = 144;
	}
	
	print() {
		console.log(this);
	}
	
	switch() {
		this.b = !this.b;
	}
	
	static spiderfire() {
		return "SPIDERFIRE";
	}
	
	get b() {
		return this._b;
	}
	
	set b(b: boolean) {
		this.b = b;
	}
	
	static get a() {
		return Switch.INT;
	}
	
	static set c(_: any) {
		console.log("Pranked!");
	}
	
	get i() {
		return this._i;
	}
	
	set i(i: number) {
		this._i = i;
	}
}

Although the URL Module is mostly complete, URLSearchParams is currently unimplemented. This can be implemented with the #[js_class] macro, you can look at the definition of URL or ask here for more help.

Since the URLSearchParams should mutate the underlying URL object, it can probably store a url: &mut Url or the output of Url::query_pairs_mut. Url::query_pairs_mut should deal with most of the underlying implementation details, and the main task will be mapping the underlying functions to the JS API.

Requirements: Basic in JavaScript, Intermediate in Rust Difficulty: Intermediate

Resources

• url crate
  • Url::query_pairs_mut
• URLSearchParams on MDN
• URLSearchParams Specification

Currently, Spiderfire has 4 modules (assert, fs, path, url) and a bunch of globals Iconsole, setTimeout, etc.). However, it can be a bit confusing for the users who would like to use these since their API differs slightly from stuff like node or deno.

All of the above have typescript and flow declaration files. As such, it would be nice to add documentation in these files for those functions. All contributions are welcome.

Most of the functions should make sense on their own, but feel free to ask here if you need some help.

Requirements: Intermediate in JavaScript Difficulty: Easy

Resources

• Globals - MDN
• Modules - Node.js API Documentation
• URL Module - URL Specification (Documentation on MDN too)

Issue

Spiderfire currently lacks a networking module, making it impossible to use this as a serverside runtime, and serve webpages for example. It is also unable to fetch data from web APIs. Implementing a networking module will be essential for spiderfire's usage.

Possible Solution

hyper or reqwest can be used to provide HTTP networking APIs in a module.

I know, I know this is a deno thing but I really think it would improve the project by attracting all the typescript folks. Personally is something node.js needs and I'd use it without doubt. I'm not suggesting get rid of javascript, not at all, what I'm suggesting is let the users use typescript or javascript without too much configuration or boilerplate. I'm still learning rust but I'd like to work/collaborate on this feature.

Lack of Documentation

Spiderfire is currently lacking documentation for most of its API. It would be nice to have the structs and functions documented so that contributors can more easily understand the codebase, and users can begin creation of native modules.

Requirements

This task requires basic understanding of Rust, to understand the codebase, and intermediate understanding of Javascript, to understand the interactions with SpiderMonkey. Difficulty: Easy to Intermediate

Workspace Crates

• Ion Procedural Macros ('ion-proc`): Contains procedural macros.
  • Wrappers around regular macros
• Ion (ion): Contains wrappers around the native JSAPI.
  • Wrappers around native types. (IonObject, IonArray, IonDate, IonFunction)
  • Conversion and printing of native types.
  • Handling runtime exceptions.
• Runtime ('runtime'): Contains functions related to runtime initialisation and operation.
  • Module loader.
  • Console global.
  • Logging level.
• Modules ('modules'): Contains standard modules.
  • Assertion (assert)
  • File System (fs)
• CLI (cli): Contains the application code for the command-line interface.
  • Evaluation (eval)
  • REPL (repl)
  • Running modules/scripts (run)

Issue

Currently, there is a limitation to the usage of tests as only 1 test per file can be created to test actions within the runtime. This is due to the following. Hence, only 1 runtime can be initialised per thread. Due to how cargo tests are run serially(with --test-threads=1) and in parallel, this means only 1 runtime can be initialised per executable, which requires 1 file per test.

It is currently not possible to initialize SpiderMonkey multiple times (that is, calling JS_Init/JSAPI methods/JS_ShutDown in that order, then doing so again). This restriction may eventually be lifted.

Finding a solution to this will improve flexibility for future tests with more complex modules, and JSAPI wrappers. Currently, I have a draft of tests for the fs module, but I am not satisfied with them, as putting them all in a singular function partially defeats the purpose of such tests, as they are not targeted. With this improvement, each portion of the fs module can then be tested independently, and properly utilise cargo's test system, with many tests and test cases.

Requirements

• Advanced Understanding of Rust, static values and cargo tests
• Intermediate Understanding of JavaScript
• Understanding of Spidermonkey Runtime and Engine initialisation

Possible Solution

thread_local or Mutex could be used to store the ParentRuntime and Runtime::create_with_parent could be used to create the appropriate runtimes.