HyperSignals

Concept for a Signal system, loosely inspired by Reactive.jl

• Inline callback code
• Transfer entire branches to jitted OpenCL/OpenGL kernels
• Multithreaded branching
• Different event sources, like websockets, disc, files, OpenCL-events, IDE-code changes, etc...
• Different caching methods, for events that are emitted faster than they're being processed
• Bidirectional signals
• lazy updates (state changes only get updated when read)

• creating memory optimal code paths. For example consider loading a video from the hdd, loading it into ram, then transferring it to the GPU to filter it. After the filtering, compress it and send it via a network connection to another client. This should look something like this in Hypersignals:

video = lift(open, "file.mp4") # create a signal from a file
filtered = lift(video) do frame  
  filter!(kernel(:gauss, 4,4), frame)
  hue!(frame, 0.4)
end
compressed = lift(compress, filtered)
lift(compressed) do frame
  sent(socket, frame)
end

This lift should now sent a data stream to socket with this this kind of pseudo code:

video = read_video_from_hdd_into_ram(filepath)
gpu_code = find_gpu_segments(signal) # should recognize, that filter!, hue! 
#and compress is executable on the gpu and can use the same gpu memory.
gpu_kernel = compile(gpu_code)
while !done(video)
  frame = next(video)
  upload_to_gpu(frame)
  frame = execute(gpu_kernel, frame) # shouldn't allocate new memory and reuse both ram and video memory
  sent(socket, frame) # some magic function that serializes the signal and sents it optimally to another client.
end

• should make it easier to have asynchronous and heterogenous events processed on the GPU and CPU.