Preskoči na glavno vsebino

Towards Rye's minimal web-application library #2

This is a continuation from the previous post. I integrated the postgresql into Rye, and made it work with the same SQL dialect that the SQLite integration uses.

The "web framework" code (5 functions) is the same as in the previous post. The web-application and server code is below.


A couple of notes ...

The SQL dialect is in short a dialect of Rye values (not a string) that produces prepared SQL statements avoiding the usual bug-prone positional arguments.

Open, query and exec are generic methods and dispatch on the kind of the first argument (in this case a postgresql database). SQLite also uses these generic words, so do other also non-database kinds.

Query returns value of type Spreadsheet. It's similar to your Excel spreadsheet or in more technical terms like R-s frame. Some spreadsheet specific functions are sum, avg, max, min, and also two to quickly retrieve a value of the first and second cell like A1 and B1 ... that correlates to columns A and B in row 1.

Rye has some specific ideas about failure handling. Failure means that the function failed to produce an intended result. Failure is first information and only unhandled failure becomes an Error. We have specific patterns around handling the failures like check, fix, tidy. I should write a blog post about this soon.

Words that start with a ^ are returning words . They conditionally return to the caller. This line with ^check:

read %profile.txt |^check "couldn't read profile" |print

would in a more classical language look something like:

data = read("profile.txt")
if (data is Error) {
 
return new Error("couldn't read profile", data)
}
print data


The current idea I am trying out is that we use failure very strictly when the function couldn't produce a desired result. Various languages use nulls, empty strings, empty blocks, zeroes, etc. to convey additional information. This is exactly what I am trying to avoid. We will see if it works out well.

For example if a dictionary lookup returns no result it doesn't return null but failure, also if a SQL query returns no result. In the code above "try-login" returns the ID of the user on successful login. You could make up a silent "convention" that it should return 0 if the user login failed. But such unwritten conventions  are very frail and can pile up into a mess. So our function fails if there is no user with that email and it fails via assert if the passwords don't match. Only if it validates and can return the user's ID, it returns the integer.


The get-page functions like this:


And the get-token like this ...


Next I should add session related functions and work on better error reporting from the handler functions.

Links:
Rye website
(wip)
Github

Komentarji

Priljubljene objave iz tega spletnega dnevnika

Ryelang - controlled file serving example and comparison to Python

This is as anecdotal as it gets, but basic HTTP serving functions in Rye seem to be working quite OK. They do directly use the extremely solid Go 's HTTP functions, so that should be somewhat expected. I made a ryelang.org web-server with few lines of Rye code 3 months ago and the process was running ever since and served more than 30.000 pages. If not else, it  seems there are no inherent memory leaks in Rye interpreter. Those would probably show up in a 3 month long running process? And now I got another simple project. I needed to make a HTTP API for some mobile app. API should accept a key, and return / download a binary file in response if the key is correct. Otherwise it should return a HTTP error. So I strapped in and created Rye code below. I think I only needed to add generic methods stat and size? , all other were already implemented, which is a good sign. Of course, we are in an age of ChatGPT, so I used it to generate the equivalent  Python code. It used the ele...

Receiving emails with Go's smtpd and Rye

This goes a while back. At some project for user support, we needed to receive emails and save them to appropriate databases. The best option back in the day seemed project Lamson . And it worked well ever since. It was written in Python by then quite known programmer Zed Shaw. It worked like a Python based SMTP server, that called your handlers when emails arrived. It was sort of Ruby on Rails for email. We were using this ever since. Now our system needs to be improved, there are still some emails or attachments that don't get parsed correctly. That isn't the problem of Lamson, but of our code that parses the emails. But Lamson development has been passive for more than 10 years. And I am already moving smaller utilities to Rye.  Rye uses Go, and Go has this nice library smtpd , which seems like made for this task. I integrated it and parsemail into Rye and tested it in the Rye console first. Interesting function here is enter-console , that can put you into Rye console any...

Go's concurrency in a dynamic language Rye

  The Rye programming language is a dynamic scripting language based on REBOL’s ideas, taking inspiration from the Factor language and Unix shell. Rye is written in Go and inherits Go’s concurrency capabilities, including goroutines and channels. Recently, Rye gained support for Go’s select and waitgroups. Building blocks Goroutines Goroutines are lightweight threads of execution that are managed by the Go/Rye runtime. They operate independently, allowing multiple tasks to run concurrently without blocking each other. Creating a Goroutine in Rye is straightforward. The go keyword is used to launch a new Goroutine, followed by the Rye function to be executed concurrently. For instance, the following code snippet creates and starts a Goroutine that prints a message after a delay: ; # Hello Goroutine print "Starting Goroutine" go does { ; does creates a function without arguments sleep 1000 print "Hello from Goroutine!" } print "Sleepi...