recent news

8sync 0.4.2 "FOSDEM Edition" released, plus videos!

-- Sat 18 March 2017

I'm happy to announce the release of 8sync 0.4.2, AKA "8sync FOSDEM Edition"! The two main features in this release are that the web server code has moved to an actor, and that we also now have a websockets implementing actor. (Code snarfed from David Thompson's great work on guile-websocket! In the future, 8sync may use guile-websocket directly instead of snarfing its code.)

We're calling it 8sync FOSDEM Edition because, you guessed it, this is the set of code used during the demonstration of 8sync at FOSDEM 2017. (The recording of that talk is now up, as well as a variation of it I gave at the Chicago GNU/Linux user group, which I've linked from the 8sync homepage now.) The talks demonstrate 8sync through live hacking a multiplayer game built with Mudsync. (I've also pushed up a fosdem-2017 tag of Mudsync in case you want to try running it yourself.)

You may have also seen the exciting news that Guile 2.2.0 has been released! Congratulations to the whole Guile team and community! This is also good news since 8sync uses some Guile 2.2 specific features, so we're now no longer depending on an unstable release. Horray! Be sure to also read Andy Wingo's reflections on Guile 2.2. Relatedly, Fibers 1.0 was released recently... maybe it's about time to see if we can fit 8sync on top of Fibers. Only one way to find out if it's a good fit!

That's all for now. Happy hacking!

guile-8sync now available in Guix!

-- Mon 09 January 2017

Hello! A minor announcement today, but a useful one! There's now a guile-8sync package available in Guix! This means that setting up and giving 8sync a whirl is fairly easy now. You can set up a little environment to test it in like:

guix environment --ad-hoc guile-next guile-8sync --pure

Then just run guile and give it a whirl!

8sync 0.4.1 bugfix released

-- Sun 08 January 2017

This morning we released 8sync 0.4.0. Well, it turns out there was a bug in the packaging! The files were installing to Guile 2.0's load path, when they should have been installing to Guile 2.2's load path. So, here is a release for 8sync 0.4.1. No significant changes, except that the build is fixed and the guix.scm file has some minor improvements.

And so, 8sync 0.4.1 is out much sooner than we thought! Onward to 8sync 0.4.2... which we hope to be a much more substantial release!

8sync 0.4 released

-- Sun 08 January 2017

Hello, hello! 2017 is fresh upon us, and so is a new release of 8sync... 8sync 0.4 is here!

Most excitingly, we now have some decent documentation! Or at the very least, we finally have a tutorial (API documentation is still on its way). The tutorial walks from extending an existing actor by writing an irc bot, to writing your own basic actors, to writing network actors. You *know* you always wanted your very own IRC bot, so give it a try!

Actors are now "center stage". You can now import a toplevel (8sync) module, and this module includes the full actor model system. The actor model is now *the* way to handle concurrent synchronization in 8sync. So, 8sync is officially less about its event loop, and more about the actor model. (It is even possible that in the future, 8sync's actor model will be able to run on another event loop.)

Actors now also have implicitly run *init* and *cleanup* message handlers. Setting up actors now involves a lot less boilerplate, since most actors do have some sort of initialization method anyway. The *cleanup* message handler allows actors to clean up after themselves when they shut down, by closing a socket, deleting temporary files, save their current state to a database, or whatever.

Sending messages has become slightly easier, as the from-actor field is now implicit, set as a parameter by the actor's hive.

Those are the highlights! See the NEWS file for additional details.

What's next? In 0.4.1 you can expect better automatic shutdown of coroutines after an actor terminates, a new HTTP module, API documentation, and a bunch of other goodies.

Oh! And will you be at FOSDEM 2017 by any chance? There will be a Guile and Guix developer room and if last year was any indication, I expect it to be an absolute blast. I'll be there, giving a talk about 8sync, live hacking, and network freedom, and my talk is going to be delightfully unusual. Instead of slides, I'm going to be running an 8sync-powered MUD (multiplayer text adventure) powered by 8sync and mudsync, where the rooms will be the "slides"! I'll also be live editing the game world *during the talk*! You're not gonna want to miss this!

That's all for now. Happy hacking!

8sync and Fibers, together at last!

-- Sun 08 January 2017

What? 8sync and Fibers, together at last? Can it be true? Indeed it can!

8sync 0.3 released

-- Mon 19 December 2016

Greetings, all! I'm pleased to announce 8sync 0.3! 8sync is a library for GNU Guile which provides an asynchronous event loop and which uses the actor model as its primary concurrency synchronization mechanism.

This release brings some major changes and improvements. The 8sync 0.2 release announcement (less than two weeks ago!) anticipated some of these changes. In summary:

  • 8sync is now Guile 2.2 only, in order to support...
  • Suspendable ports! Writing networked code is considerably simpler in 8sync 0.3. Using Guile 2.2's suspendable ports tooling, when reading and writing from ports that are set to be nonblocking, 8sync's scheduler will automatically suspend to the scheduler and resume your code when network data is ready to be handled.
  • Actors now have an "actions" slot which is automatically inheritable.
  • "define-mhandler" is deprecated. Instead, message handlers are simple procedures, and a message's body can be any sort of Guile procedure argument list.

And more! See the NEWS file for full details.

What's next? If all goes well, 8sync 0.4 should be around the corner soon as well. You can expect the actor system to be moved to take center stage in the application and (finally!) some decent documentation.

Happy hacking!

8sync 0.2 released, and the future of 8sync

-- Mon 05 December 2016

Hello one and all! I'm pleased to announce 8sync 0.2, the thrilling second release of 8sync. What's in store? Well...

Actors, enter stage left!

This release brings an entirely new (and entirely optional) actor model subsystem built on top of 8sync's existing concurrency facilities and GOOPS, and inspired by prior experience designing XUDD. In short, the actor model is a "shared nothing" environment where actors only hold addresses, not direct references, of each other, and where the only communication between actors is through message passing. Actors consume messages from their inbox and propagate messages throughout the actor graph. Callback hell is avoided in a way similar to 8sync core; actors can send messages but "wait" on replies, suspending their procedures mid-execution until a response comes.

Perhaps a demonstration is in order. Some of you may recognize this actor subsystem from the blogpost about Mudsync and the Lisp Game Jam. Yup, this is pretty much exactly the same software as used there! In the blogpost we gave an example of ringing a bell. Let's take a look at the very code for the summoning bell, mentioned previously! (Or more specifically, its action handler for being rung.)

(define-mhandler (summoning-bell-cmd-ring bell message) ;; Call back to actor who invoked this message handler ;; and find out their name. We'll call *their* get-name message ;; handler... meanwhile, this procedure suspends until we get ;; their response. (define who-rang (message-ref (<-wait bell (message-from message) 'get-name) 'val)) ;; Now we'll invoke the "tell" message handler on the player ;; who rang us, displaying this text on their screen. ;; This one just uses <- instead of <-wait, since we don't ;; care when it's delivered; we're not following up on it. (<- bell (message-from message) 'tell #:text "*ring ring!* You ring the bell!\n") ;; We also want everyone else in the room to "hear" the bell, ;; but they get a different message since they aren't the ones ;; ringing it. Notice here's where we make use of the invoker's ;; name as extracted and assigned to the who-rang variable. ;; Notice how we send this message to our "location", which ;; forwards it to the rest of the occupants in the room. (<- bell (gameobj-loc bell) 'tell-room #:text (format #f "*ring ring!* ~a rings the bell!\n" who-rang) #:exclude (message-from message)) ;; Now we perform the primary task of the bell, which is to summon ;; the "clerk" character to the room. (This is configurable, ;; so we dynamically look up their address.) (<- bell (dyn-ref bell (slot-ref bell 'summons)) 'be-summoned #:who-summoned (message-from message)))

Pretty cool, huh? I hope that's pretty clear / self explanatory!

Anyway, so the actor model system is pretty cool and fun to use. Unfortunately like (heh) all of 8sync, it's very underdocumented at present. Documentation is of course coming, but I figured that rather than sit on 8sync's current code, I should make a release, especially before big changes happen. And big changes are likely to happen soon!

The exciting, evolving world of Guile async tooling

Just a year and a couple of months ago, things were pretty different when it came to Guile's asynchronous programming story. A few of us sat down, fresh on the doorstep of the FSF 30th party, and discussed what things could be like. Shortly thereafter, I started hacking on 8sync as an experiment in trying to flesh out what kind of asynchronous environment I really wanted... in fact, 8sync's first commit is just a couple weeks over a year old. Happy birthday! Soon after that I gave a talk at FOSDEM about "Paving a Path to Greater Network Freedom" at the Guile Developer Room. (I also gave a talk immediately after called "The Community Guile Could Have" which I think ties in a lot as well, but perhaps more in terms of the necessary social steps necessary for Guile's success, networking-wise and other-wise.)

From here, I think a lot of things took off. Guile's asynchronous programming story is starting to really develop a lot; alongside 8sync, a few asynchronous network programming libraries popped up and started to move along. Chris Vine started guile-a-sync and Andy Wingo started Fibers. And then the real bombshell, I think, is the work Andy Wingo has been doing on revamping Guile's networking tooling, especially the super exciting suspendable ports tooling coming in Guile 2.2. With all this work, I think we're on track for Guile to be one of the most interesting and most satisfying places to do network hacking. What a great time to be alive and be a part of the Guile community! I'd like to think that some of my advocacy, and starting 8sync, helped spur some of this along, but maybe the rest of it would have happened anyway... who knows!

Well regardless of 8sync's role in spurring the rest of this stuff forward, there's another side to it: what does it mean for 8sync? The answer is: I'm not totally sure, but there will be changes. One thing that is clear is that 8sync will move to use the suspendable ports tooling in Guile 2.2; that feature is just too good to pass up and could considerably simplify much of the tooling in 8sync.

But what about 8sync in relation to these other libraries? Again here, I'm not totally sure. I need to explore more of what's happening outside of 8sync's walls. In particular, there's clearly great stuff happening in Fibers, and I'd like to understand that better. I think that Andy Wingo probably has a better grounding in fundamentals and theory than I do. I recommend reading Andy's excellent blogpost (it's also part of the Fibers documentation) explaining thinking about what concurrency facilities are and aren't desirable. With all that hard thinking and work, is it possible that 8sync's event loop could be built on top of Fibers (or guile-a-sync for that matter)? Maybe, maybe! I think I need to play with it and know. Maybe there are reasons to keep experimenting in a separate direction, or maybe we can join forces fairly easily. Time will probably soon tell. "Worst comes to worst" (or is it "worst comes to best"?) it could be that 8sync just becomes an actor model library living on top of one of these other libraries. Which would be a pretty good worst/best case!

No matter what happens, as I said, it's a great time to be exploring network programming in Guile. And of course, you're always welcome to join us in 8sync land!

Onward and upward... have fun hacking in Guile!

8sync participates in the Lisp Game Jam with Mudsync

-- Wed 11 May 2016

Hello, hello! Over the last week and a half, 8sync participated in the Spring 2016 Lisp Game Jam. In short, I had ten days to build a game, so I decided to build a MUD on top of 8sync. And so, mudsync was born!

> go east **Smoking Parlor** This room looks quite posh. There are huge comfy seats you can sit in if you like. Strangely, you see a large sign saying "No Smoking". The owners must have installed this place and then changed their mind later. There's a door to the west leading back to the grand hallway, and a nondescript steel door to the south, leading apparently outside. You see here: a comfy leather chair, a plush leather sofa, Ford Prefect and a bar stool. > sit in the chair You sink into the comfy leather chair. > say Ahhhhhh, this is the life! paroneayea says: Ahhhhhh, this is the life!

How'd it go?

I'm happy to say that mudsync was successful overall. The end released project includes a fairly solid, live hackable game engine for multiplayer interactive fiction. This ended up being more of a piece of infrastructure to build games rather than being a nice game itself, but it does ship with a mini-world called "Hotel Bricabrac" which has some interesting things, but is more of a tech demo. Most importantly, I feel like mudsync is a really nice foundation for future games, and the amount of world building I did do in it was a joy to put together. So! More of that in the future?

Mudsync also made great use of 8sync's new actor model subsystem, which will publicly premiere in the upcoming 0.2.0 release.

Why participate in the game jam?

At first participating in the game jam may sound merely like an exercise in fun, and of course it was this too, but greater ambitions were also at play. I have plans to use 8sync for some larger projects involving federated networks, and I wanted to be sure that the technology worked well enough to invest my time by building something more complicated. Happily, all seems to have gone well; I am feeling much more confident in 8sync now having completed the jam and am looking forward to my larger projects with it. And along other federation-related lines, I've long been interested in the overlap between the type of federation-related work I am persuing with the ActivityPub standard MUDs, and the actor model of programming. MUDS, the actor model, and ActivityStreams (the syntactic basis upon which ActivityPub rests) all share a subject-predicate-object syntax and use message passing as a primary communication mechanism. And lest it sound like I've gone completely off my rocker (maybe I have, of course) I might note that research in MUDs as a decentralized mechanism of communication was very high before the web took over everything, and even an active topic in a couple of research labs! (I recommend checking out the Design Requirements for Network Spaces document to get a sense of this.) So I figured implementing a MUD might help me better think through some of this space, and it did!

Furthermore, 8sync itself owes part of its existence to a much older interest of mine in creating networked games. XUDD, the actor model system I wrote in Python and which preceded my thoughts on how to build 8sync, originally stood for "eXtensible User Dungeon Design" (but I gave it a sillier acronymn when its goals shifted). I haven't lost interest in how to design such systems, and the implications of them fueled a lot of my reading in this area.

Plus, it sounded like a whole lot of fun!

What does it look like?

From a player's perspective, mudsync is your classic MUD-over-telnet. There are some things missing, but it works: you can walk around from room to room, interactive with objects and other players, and so on.

From an administrator / hacker's perspective, mudsync is much more interesting. You write out a "game spec" like the following (which is borrowed from real game code):

(define lobby (lol ; just a simple 'list of lists' macro ;; Starting place for players ('room:lobby <room> #f #:name "Hotel Lobby" #:desc " You're in some sort of hotel lobby. You see a large sign hanging over the desk that says \"Hotel Bricabrac\". On the desk is a bell that says \"ring for service\". Terrible music plays from a speaker somewhere overhead. The room is lined with various curio cabinets, filled with all sorts of kitschy junk. It looks like whoever decorated this place had great ambitions, but actually assembled it all in a hurry and used whatever kind of objects they found lying around. There's a door to the north leading to some kind of hallway." #:exits (list (make <exit> #:name "north" #:to 'room:grand-hallway))) ;; Summons a clerk if a player does 'ring bell' ('thing:lobby:bell <summoning-bell> 'room:lobby #:name "a shiny brass bell" #:goes-by '("shiny brass bell" "shiny bell" "brass bell" "bell") #:desc " A shiny brass bell. Inscribed on its wooden base is the text \"ring me for service\". You probably could \"ring the bell\" if you wanted to." #:summons 'npc:break-room:desk-clerk)))

This builds the kind of world you might expect from the above:

> look **Hotel Lobby** You're in some sort of hotel lobby. You see a large sign hanging over the desk that says "Hotel Bricabrac". On the desk is a bell that says "ring for service". Terrible music plays from a speaker somewhere overhead. The room is lined with various curio cabinets, filled with all sorts of kitschy junk. It looks like whoever decorated this place had great ambitions, but actually assembled it all in a hurry and used whatever kind of objects they found lying around. There's a door to the north leading to some kind of hallway. You see here: a curio cabinet, a shiny brass bell, the Hotel Bricabrac sign, a frumpy fellow and sign-in form. > look at bell A shiny brass bell. Inscribed on its wooden base is the text "ring me for service". You probably could "ring the bell" if you wanted to. > ring the bell *ring ring!* You ring the bell! Suddenly, a uniformed woman rushes into the room! She's wearing a badge that says "Desk Clerk". "Hello, yes," she says between breaths, "welcome to Hotel Bricabrac! We look forward to your stay. If you'd like help getting acclimated, feel free to ask me. For example, 'ask clerk about changing name'. You can ask me about the following: 'changing name', 'common commands', and 'about the hotel'."

(I inserted the ">" characters to make where the input was a bit clearer, but otherwise that's verbatim output from the game.)

What's nice is that you can live hack everything that's going on. And by that of course I mean the kind of usual nice live hacking you have going on with 8sync and Guile... but it's not only that! Consider the following challenge: you've just tweaked the description of the room your friends are hanging out in, but you already have a room set up in the game's universe, so how on earth can you replace it? Luckily Mudsync provides a nice protocol for replacing objects, and even provides a nice utility to inject it into the currently running game (the actors know how to "transfer important details", in this case, the participants in the room):

(inject-gameobj! game-spec 'room:lobby)

Obviously, you don't want to do this for anything other than live hacking. But it is nice that you can live modify how things are running in the game. For example, at one point a player asked me how they could "emote" in the game, and we didn't have an emote command, so I added it and told them, and then we all happily did some emote'ing. At another point a player said they felt bad for the desk clerk and wanted a way to dismiss her so she wouldn't have to hang around the desk, so I added a dismiss command where she'll thank the player and "run off to do something important" (as it turns out, doing something important means to go smoke in the employee break room).

A story about stories

So, speaking of that, the "main game" that ships with Mudsync right now is a little mo... hotel named "Hotel Bricabrac" full of various strange and fun things (though, not as many as I would like). Unfortunately, it lacks any significant story. There's something that almost resembles a story, and which players seemed to like: the desk clerk, upon ringing the bell, arrives, but quickly becomes bored, starts fidgeting distractedly, and eventually leaves. When I first started coding this, I had envisioned the character as perhaps a disaffected and incompetent teenager, but as I was playing around I started to feel empathy for them... it really was a boring job that they had, and newcomers ringing the bell all the time would get annoying. Thus, if you explore well enough, you might find the "employee break room", a cage affixed to the exterior of the building. Whenever the clerk leaves her post, she goes here to smoke and check her phone and slack off. But if you talk to her enough in this off-duty space, she'll tell you that she's a student studying high energy particle physics, that she's underpaid, but she's working the job because she doesn't have many other options and her student loans are crushing her. So she was never really incompetent after all, just overqualified, bored, and, well, still disaffected. Some players seemed to enjoy that and expressed empathy for the character (though it didn't seem to stop them from ringing the bell to provoke a response from her). I was glad about that, and I wish I had more time to script in more things like this.

Indeed, my original ambitions were to build a full and immersive game as part of the game jam. I sketched in a notebook a layout for a haunted mansion or college campus. My original vision for the jam was that players would be collaborating in exploring an area on figuring out how to help various ghosts be put to rest. You'd find out what's binding them to this world and help them resolve their problems, and you as a player would have an "achievements" list showing off just how many interesting things you had done in the world. Unfortunately (though not surprisingly), building the engine itself ended up being enough work that I didn't have a lot of time for content. Thus the experimental little world where I was testing various game mechanics became the actual deliverable of a demo-world to be played.

In the end, that's probably not the worst situation. I feel I have a good design on which future games could be built. And despite the chaos of it, players did seem to have a lot of fun (I think at one point we had about 8 players or so on the game who were hanging out and mostly socializing). The chaotic gathering place on some mysterious property atmosphere looks a lot like LambdaMOO, and as LambdaMOO enthusiast Rob Myers said to me at one point, "Themeliness is next to timeliness." It's not such a bad start! Though I do hope to have more interesting worlds to show in the future.


No sprint like this is without its challenges. Here were mine:

  • It was really hard to decide what "flavor" of sentence parsing to go with. Basically you can either have more rich sentences which require a lot of complicated parsers, but then you can say complicated things like "Put the melon in the fruit basket." (Zork/ZIL/Z-Machine type single-player interactive fiction games tend to go like this.) Or you can go with more predictable but limited parser and parse more basic sentences like "put melon in fruit basket". The former lends itself to more immersive gameplay. The latter is faster, more predictable, and works better for either combining with non-text interfaces (maybe a web UI) and could concievably work with a federated game. I spent some time agonizing over this. In the end I built kind of a hybrid: actors select from a few prebuilt "rich" command processors which handle all the basic cases you might want.
  • 8sync relies heavily on delimited continuations. However, sometimes if scheme calls C which then calls out to scheme again in Guile, things break. A few things caused this, including using the "@@" special form to try to get around dependency loops lazily. Most significantly, since 8sync's actor model system uses GOOPS, I learned the hard way that GOOPS being very C based in Guile 2.0 means that I had to forego many interesting GOOPS features, like generic methods or accessors. Once I realized this, things went a lot more smoothly, and I didn't really need these features... but sometimes I wished I had them.
  • You might say, "but Guile 2.2's GOOPS was rewritten in scheme!" And you'd be right. Unfortunately, I uncovered a pretty critical bug with GOOPS and Guile 2.2, and didn't have time to look into it seriously. Again, not a huge deal, but it did take up some time to look into.
  • I hit a really weird SIGABRT issue in 8sync's actor model. Initially I thought it was a Guile issue, but it turned out I just didn't understand some things about how prompts and exceptions work.
  • I really wanted to have a nice text formatter, but I ran out of time to integrate one. (If you talk to the hotel owner in the lobby of Hotel Bricabrac, you'll find he complains about this kind of indirectly, expressing my wishes to explore something along the lines of Skribilo or fmt. Alas! No time for it...)
  • Again, I would have loved to have more time to build a more coherent story. But time is always a challenge in these things!

What's next?

So mudsync will be a background hacking task for me probably for a while, something to hack on for my and friends' amusement every now and then. I may end up writing some small and interesting stories. But it won't be my main project.

But it probably will be a basis for research (and fun) for me. It's a nice system to test out ideas in. And I'll probably add some cool optional components, like persistent-world-supporting databases. (Maybe even player-scripted items? Unlikely in that it would require a carefully crafted sandboxed execution environment, but don't think I haven't been thinking about it...!)

In the meanwhile, if you want to check it out, the source is available. Patches most welcome! And if you hop in #8sync on, maybe you can find the address of the current dev server!

Thanks to Rob Myers and Jason Self, who both know a lot more about interactive fiction than I do and answered a lot of questions and offered ideas. Thanks also to everyone who gave the game a try. I hope it was as fun for you as it was for me!

Happy hacking...

8sync 0.1 released

-- Fri 22 April 2016

Greetings, gentle citizens of the GNUiverse! I'm happy to announce 8sync 0.1, the very first release of 8sync, an asynchronous programming library for GNU Guile. (I recently wrote a blogpost introducing 8sync if that's of interest to you.) Get 8sync v0.1.0 here!

This is the first release, so pretty much everything is new. There isn't much documentation, and things are a little bit rough in general. If you're interested in diving in, I recommend checking out the "demos" directory, and particularly try playing around with scripting an irc bot. One nice thing is that you can run it with "--listen" and, if using Geiser and Emacs, run "connect-to-guile" and live-hack away, adding functionality to your bot while it's running!

A lot more needs to be done. 8sync currently uses select, whereas it should clearly use poll or epoll, and such things will be done. More examples and demos are needed. Perhaps this is interesting to you, and you'd like to try to help us out yourself! In that case, please join us! 8sync is young, and now is a great time to get involved and explore. Happy hacking!

(display "Hello, World!")

-- Tue 12 April 2016

Hello everyone! Time to test the sanity of this system, yeah?

So, this is the soft launch of the 8sync website. There's not too much to see quite yet. I need to make a proper release, etc.

But maybe you're wondering what this crazy 8sync thing is? Well, as the name implies, it's an asynchronous event loop (hence the pun, 8-synchronous... the logo has an infinity symbol...) for GNU Guile. If you're familiar with Node.js for Javascript or asyncio for Python, you might know a bit about what I mean by "asynchronous event loop". So, why bring another event loop into the world?

Well, as things tend to go, I initially wrote 8sync largely for myself. I've spent enough time in other asynchronous systems to know that I'm just not very happy working in them. I knew I wanted a system with the following properties:

  • Absolutely no "callback hell". Asynchronous code is as easy to read as synchronous code.

    Most event loops end up with you chaining different event commands together manually and what in a synchronous program might be a strightforward piece of code gets very confusingly threaded across many pieces of code. I was inspired by asyncio's coroutine support, but hoped that I could achieve even better. asyncio requires that you very carefully "line up" coroutines so that they fit together. 8sync avoids this by making use of delimited continuations under the hood. However, most users will never have to learn how delimited continuations work, 8sync provides the (8sync) special form. Yay, abstractions!

  • Live hackable. I wanted a system that I could modify and play with while the system is running. No need to restart. I want my editor, my code, and my REPL all interconnected. So, 8sync has nice integration with Geiser and Emacs. (It's a bit dated, but I still find David Thompson's video of live hacking in Sly to be a massive inspiration).

  • Ideally, in some kind of lisp. Well, I like lisps, but in a certain sense, this is because of the above goals. Lisps tend to be well suited for "REPL driven development" and forging the syntax necessary to make solving problems easier. And I was spending a lot of time in Guile, so of course having something in Guile would be nice.

I had the good fortune at the FSF 30th anniversary party to sit down with Guile hackers David Thompson and Mark Weaver, and we had a nice brainstorm about what a good asynchronous event loop in Guile might look like. At the time I still assumed I would convince someone else to do the work, but then I started coding a mockup, and oh hey! The mockup started to turn into something pretty nice. And so, 8sync was born.

So anyway, it's still early days for 8sync. Today is the launch of the 8sync site. Horray! (Happily, this site is built with David Thompson's Haunt, which is a real delight to use!) And, as you can see, we're a GNU project, which is pretty cool. Hopefully sometime in the next few days, an official 8sync release will come out... 0.1! After that, I might end up doing more integration with some of the port refactoring work Andy Wingo is doing in Guile. At the very least, 8sync has demonstrated some good ideas, but there are some goofy things to clean up too (why are we using select instead of poll/epoll?).

Lots to do! And so, hello world, it's nice to meet you. See you again soon!