alonely0/voila

Voila is a domain-specific language launched through CLI tool for operating with files and directories in massive amounts in a fast & reliable way.

Voila is a DSL (domain-specific language) for interacting in a fast, reliable, versatile, safe & multithreaded way with files & directories. It is based on a CLI tool, although you can write your Voila code and do something like this voila DIRECTORY "$(cat operations.vla)". Voila is mainly tested in Linux, so should work better in *nix (Linux, *BSD, macOS, etc) than in Windows-based operating systems, but shouldn't be any problems on them. Voila is completely cross-platform.

Voila scripts are interpreted, but optionally you can compile it like you'd do with other programming languages.

Documentation

You can find the docs in the wiki.

Installation

See #Installation in the docs.

Submitting

• Errors: file an error issue using this link. Remember to check if that issue is already registered!
• Feature requests: file a f-request issue using this link. Remember to check if that f-request was already submitted!
• Doubt: file a doubt issue using this link. Remember to check if that doubt was already resolved!
• Wanna chat with me? You can talk with me on Discord, add me as friend (NOT-Guillem#8042) and we'll be able to start chatting!

voila's Issues

Note on resources, and undefined behavior inside the cycles (long term planning)

Look at the below snippet:

@name == 1 {
   delete(@path)
   shell(my-useful-check @path)
}

This snippet triggers undefined behavior, as it's using a resource potentially destructively (delete will certainly do, my-useful-check might do). You don't know which one will error out, if delete or shell. It could be that shell finds the file while delete is still working on it, and you never know what will happen next.

This issue is meant to open a debate. How shall we mitigate this issue? I've thought of three options, let me know if you have any more:

• let the undefined behavior happen (as it would in the current state) but document it (i.e say which functions are potentially destructive). This might be a good thing to do while we're developing a more useful idea into the project, to advise against known issues.
• staticly analyze the code, and trigger an error before it's run if there are calls within the same cycle to functions which will potentially destroy the resource (using the resource would mean passing the path, or the name, to a create/delete/shell function). This seems to me as the best one of the three.
• silently modify the code before it's run, moving each call to their own separate cycle, and probably issuing a warning that those functions won't execute concurrently because they're trying to own the same resource at one. This is not a great thing to do as you're probably hindering performance through separating the functions and actually don't know which of the functions would be desired to run first.

Final note: I don't think we should start working on this immediately, but instead come up with different ideas or expand one of them as the project matures.

Add more SHAs checksums

While surfing crates.io, I found these crates

• sha2
• sha-1

Those crates would let us support these SHAs:

• SHA-1 (cryptographically broken, but if MD5 is in, why not?)
• SHA-224
• SHA-254 (already implemented, but would be rewritten using that crate)
• SHA-384
• SHA-512

I'll be working in a separate branch for implementing all that.

Performance concern regarding print function

The print function does not seem to implement block buffering. So if you print a lot of lines, you end up calling the write syscall for every line, which is quite costly.

Add tokio runtime to optimize voila and make it faster

I've been testing Voila execution times using the tokio runtime. These are the results:

• no tokio runtime

  ➜ time ./target/debug/voila ~ '@name == @name { print(@path) }' -r
   Executed in   80.10 secs    fish           external
     usr time   59.58 secs  600.00 micros   59.58 secs
     sys time   13.80 secs  236.00 micros   13.80 secs
  

• tokio runtime initialized on interpreter

  ➜ time ./target/debug/voila ~ '@name == @name { print(@path) }' -r
   Executed in   65.67 secs    fish           external
     usr time   58.11 secs  551.00 micros   58.11 secs
     sys time    7.39 secs  263.00 micros    7.39 secs
  

• tokio runtime initialized on main

  ➜ time ./target/debug/voila ~ '@name == @name { print(@path) }' -r
   Executed in   64.50 secs    fish           external
     usr time   57.34 secs    0.00 micros   57.34 secs
     sys time    7.01 secs  449.00 micros    7.01 secs
  

This issue is for discussing which one should be implemented, if the one that only affects the interpreter, that is where all the async stuff resides, or implement it on all Voila's source by initializing it on main.