ryelang

It's a grading season in our COVID-19 home-schooling experiment. I will help my kids learn so I reopened some javascript tool I jotted together a year or two ago to quickly write down notes, trees and graphs when we learned history. It's just a bunch of JavaScript and I decided that I should add a simple backend to it, so I can save notes like a normal person. Then I might have motivation to improve on it and make it more generally usefull. This was an excuse to start writing a very minimal web-application server in Rye. It will follow the similar system that my Rebol apps use since pre-2009. The backend is a STRPC API. It stands for SoTinyRPC and is a really simple HTTP-based way of calling functions on the server. It's very easy to implement a client in any language, curl, or just a html form. It's very easy to serve on a server. My production implementation features multiple return formats, clear validation errors, multiple method calls in one http call and also offe

Two posts in one day. In previous post I showed the first version of goroutines and channels in Rye. Now I joined them with websockets into a minimal chat example. All Go chat examples were quite complex so I couldn't use them and I pretty much tried the simplest structure of channels, sockets, goroutines that made sense to me. And it worked. This could mean that Go channels are pretty intuitive and flexible tool. The code works with restarts and disconnects. Rye's failure management with purge (inverse of HOF filter ) worked quite nicely for cleaning up the closed sockets. Now that all this message passing works, I would only need to add additional structure to messages, sockets and the hub. To add nicknames, enter - leave events, history, etc ... Maybe I will discover I am using sockets wrong here as I better get to know Go's concurrency. Although it works I am not 100% sure if I can read and write to a websocket from two different goroutines. Maybe some syncing mechani

Many "scripting" languages, Rebol included, have or had somewhat problematic handling of concurrency. One of the reasons I started writing Rye in Go was my naive reasoning, that because Go has very solid concurrency support Rye will be able to have it also. Rye is meant to be good at backend tasks and here concurrency is not unimportant. My naive assumption so far seems to be true. Yesterday I re-implemented web-sockets in gobwas and they work now. But to work with them in any meaningful way I need some additiona concurrent mechanisms. And in Go-land they all start with goroutines and channels. Goroutines are like green threads or coroutines and channels are used for communication between them. Unlike some green thread implementations that still run on one core, goroutines enable you to utilize multiple CPU cores. First example uses gorotine and a channel, second creates a parallel http downloader with goroutines. Function go-with runs a function (with one argument) as

I want Rye interpreter to have an option where it can only accept source files digitally signed with the public keys it trusts. This IMHO has use for code residing on servers and on users' clients. This also relates to the " mobile code " I was writing about. So as a first I integrated Ed25519 digital signatures in core Rye. The code below also serves to show few possible differences between a Rebol and Rye code. Links: Rye website (wip) Github

I worked on smaller internal things today. I made error reporting a little more useful on interpreter / repl level. It's now similar to rebol's where you get the "error happened near this code". I could and will add much more info to errors, but additional error reporting will incur some allocation cost and I will do that when I can / have time to test for the costs. The level of error reporting will probably be configurable, so you use that option only when you are debugging. There are few examples on screenshot below. Rye has quite unusual error handling ideas. I will need to write about them sooner or later. So far they seems to work quite OK, but I need to write more real life code to make this any more final. In very very short, it distinguishes between (coding) errors and failures (to accomplish the objective). A failure is information (rye value) like all other. If failure is not handled it becomes an error. You don't handle errors, you fix the code.   It

I already integrated basics of Go-s webserver Echo once. Later I decided that the default http server in Rye should use go's standard lib "net/http" server, which I started working on yesterday. I also added first steps for websockets. It's nothing complete but this is the first demo. I need to figure out what happens when there is an error in a handler next ...

I started writing builtin functions for the excellent Mangos library. Mangos is a pure Go implementation of NanoMsg scalability protocols . The example uses REQREP, but in similar manner we could also use PAIR, BUS, PUBSUB, PIPELINE and SURVEY. Mangos can communicate over multiple protocols. I advise you to read more about it. It all started with also still very active ZeroMQ . I am currently mostly interested in communication with mutual TSL authenticated connections, so my further work will be towards that.  Today I created a simple server and client (REQREP) passing around limited "mobile" code like I described in previous post .  In the image you can see two Rye processes communicating over web-socket transport. I also added some more basic functions to rye like now, format, load.