Support for using shadergarden through standard input and piping

[jar2333]

READ NEXT COMMENT FOR INFORMATION ABOUT THIS PR

One last consideration: have a separate thread reading from stdin in a blocking manner. Whenever a full config is read from stdin, set a string variable, set the reload bool, and have a subprocedure in the reload procedure read said string variable to pass to the graph creation function. This is different from the current implementation which reads from stdin in the reload procedure directly. There is no way to set the reload bool when stdin is filled automatically. The current code works when manually reloading with SIGUSR1 though! This should be the last edit before this can be merged to (my fork's) master.

[jar2333]

This branch adds functionality to shadergarden which allows it to be used through piping in scripts:

1. Added shader-inline and shader-rec-inline forms to the lisp configuration language, which are identical to shader and shader-rec, except that the string argument is treated as shader source, instead of a shader source filename.
2. Added an option for the --graph flag. Setting it to - makes shadergarden read configuration from standard input, following POSIX convention. At the moment, it consumes s-expressions until it consumes the output form, whereupon it loads the whole parsed configuration into the graph creation function.
3. Added a thread which detects the SIGUSR1 POSIX signal, and reloads all shaders/configuration upon handling it. At the moment, this is the only way to trigger a read from standard input beyond the initial graph build.

One final change would be preferred:
4) Make a thread which reads from standard input, if the --graph flag is -. Have functionality which mimics watching for file changes, by setting the atomic bool that triggers reload whenever a full config is read. Refactor code such that the config read by this thread is the one accessed in the reload function. This would relegate the SIGUSR1 signal method of reloading to purely debug purposes.

These changes would allow the use of shadergarden as a subprocess, where one can feed the lispy configuration file with (optionally) inlined shaders to interact with it. This allows it to be used in command line scripts, or other programs, without the use of intermediary files.

[jar2333]

One other minor change, the omission of a directory to search for shaders should be allowed, since inline shaders are now part of the configuration language. A hefty warning should probably be issued to the user in this case, however.

[jar2333]

I am very new to Rust, so be sure to demand refactoring where necessary. A lot of my code is very imperative and probably not idiomatic. It is also not heavily tested.

[jar2333]

The use of the SIGUSR1 interrupt and its dependency on the signal-hook crate should be made optional, given the extra dependency and the platform specificity.

[strohel]

Hi @jar2333, thanks for your contribution!

I haven't yet reviewed the code, but this looks like a useful addition. Let's first see if @slightknack (the founder of this crate) is online these days.

[jar2333]

Ok, thank you! I'll be working on that last piece of functionality in the meantime, to make stdin hot reloading work like other files, and the other minor features.

[jar2333]

The final feature has been added, where the program can automatically detect new configs fed through stdin. A minor issue, is that it does not play nice with SIGUSR1 interrupts as currently implemented. It would take a bit more effort to make the two work together well, which is not imperative since SIGUSR1 interrupts are platform-specific anyhow. They still work well when stdin is not involved, for causing a reload in spite of file changes, which is still useful.