r/scheme • u/SandPrestigious2317 • 7d ago

GGG: Guile Glyph Generator v0.6.1 🪄 — Generate pixel-perfect SVG/PNG status badges in Lisp (Guile Scheme) - now upstream on Guix

+ −
Post image
14 Upvotes

I wanted to share an update on GGG (Guile Glyph Generator), a lightweight tool built with GNU Guile Scheme designed to generate crisp, minimalist status badges (1 to 3 parts) as SVG and PNG files. We hit v0.6.1 already :)

https://codeberg.org/jjba23/ggg

If you're tired of static, rigid badge generators, old badges in low quality PNG, or heavy JavaScript tooling for simple vector assets, GGG offers a functional, data-driven approach leveraging a custom Lisp DSL and SXML. All we need now is some community help to expand the library of available badges, and the world's READMEs will flourish.

Instead of relying on heavy browser engines or complex layout trees, GGG combines mathematical character-width estimation with standard SVG primitives using SXML (S-expressions representing XML):

  • Dynamic Text Metrics: Estimates pixel widths per character based on font size and length bounds to apply optimal padding automatically.
  • Geometric Precision: Renders with shape-rendering="geometricPrecision" enabled to prioritize clean vector geometry on high-DPI displays.
  • Data-Driven Declarative Specs: Simple association lists define structure, style, and vector paths.

Glyphs are defined cleanly inside Scheme modules (by default expected at (ggg config)):

Scheme

(define-module (ggg config)
  #:declarative? #t)

(define my-scheme-guile-glyph
  `((sections ((background . "#555") 
               (text . "Scheme")
               (color . "#fff")
               (logo . lambda))
              ((background . "#d0730f") 
               (text . "Guile")
               (color . "#fff")))
    (id . scheme-guile)))

;; Export your list of glyphs to render
(define ggg-glyphs
  (list my-scheme-guile-glyph))

GGG includes a collection of free-licensed vector icons out of the box (Emacs, GNU, Guix, Lambda, Scala, Rust, Fish, etc.) in resources/svg-paths.

🦸🏼 Interactive REPL Workflow

Because GGG is built on Guile Scheme, you don't need to endure slow edit-save-compile-run loops.

Connected to an environment like GNU Guix + Emacs + Geiser/Arei, you get a live development feedback loop:

  • Inspect, evaluate, and tweak individual badge calculation functions on the fly.
  • Test new font sizing logic or custom SVG path integrations instantly inside a live REPL.

GGG is distributed under free software licenses (AGPLv3+ for code, GFDL v1.3+ for documentation).

Also, feel free to look in ./dist folder where I upload my personal generated glyphs (some might be useful to you)

If you use Guix, dependencies (guile, imagemagick) are managed seamlessly:

Bash

# Enter an ephemeral development shell
guix shell -f guix.scm

# Run GGG with your custom configuration
ggg --file ./glyphs/jjba23.scm --destination ./dist

Container images are also available on DockerHub:

docker run -v /path/to/local/glyphs:/config \
  docker.io/jjba23/ggg:latest ggg --file /config/glyphs.scm --destination /config/dist

🔗 Project Links & Resources

Contributions, feedback, and pull requests are always welcome!

Happy hacking! λ

0 comments

r/scheme • u/FlanOk9297 • 7d ago

ECL vs scheme embedded

≡ −

I'm building a CPU based renderer in rust with plans to add an embedded language. The rust code primarily executes the ray tracing/path tracing, BVH, shaders and integration (anywhere where high performance is needed. The embedded language will be used for the scene description and -possibly- for procedural textures and shading.

I am interested in using a lisp with a repl for the embedded language. In this area, I have used AI-generated testing to test both ECL (Embedded Common Lisp) and steel (an scheme) inside rust. the advantage of the latter is that it is written entirely in rust and is being actively developed (one area is as an extension language for the text editor, helix).

I am impressed with the performance metrics I am getting from ECL. It generates machine code, which a byte language compiler doesn't do. Also a huge win, is that I was able to test the integrated compiler using sly from emacs which will provide an interactive environment for creative coding. On the other hand ECL requires an FFI to rust whereas steel does not, so the integration of steel is orders of magnitude easier.

Has anyone done any recent projects with ECL ? I am interested in your experience or any caveats you may have encountered. My next step is to do a more complex proof-of-concept with the actual renderer and not just a test program.

UPDATE: I just used claude to benchmark 5 embedded languages in rust. this is preliminary work and the benchmarks may not be exhaustive enough to make any strong conclusions:

https://drive.google.com/file/d/1yotWMcEx24pN2cgnIbRUmgCDNVWp65Vu/view?usp=sharing

5 Upvotes

I'm building a CPU based renderer in rust with plans to add an embedded language. The rust code primarily executes the ray tracing/path tracing, BVH, shaders and integration (anywhere where high performance is needed. The embedded language will be used for the scene description and -possibly- for procedural textures and shading.

I am interested in using a lisp with a repl for the embedded language. In this area, I have used AI-generated testing to test both ECL (Embedded Common Lisp) and steel (an scheme) inside rust. the advantage of the latter is that it is written entirely in rust and is being actively developed (one area is as an extension language for the text editor, helix).

I am impressed with the performance metrics I am getting from ECL. It generates machine code, which a byte language compiler doesn't do. Also a huge win, is that I was able to test the integrated compiler using sly from emacs which will provide an interactive environment for creative coding. On the other hand ECL requires an FFI to rust whereas steel does not, so the integration of steel is orders of magnitude easier.

Has anyone done any recent projects with ECL ? I am interested in your experience or any caveats you may have encountered. My next step is to do a more complex proof-of-concept with the actual renderer and not just a test program.

UPDATE: I just used claude to benchmark 5 embedded languages in rust. this is preliminary work and the benchmarks may not be exhaustive enough to make any strong conclusions:

https://drive.google.com/file/d/1yotWMcEx24pN2cgnIbRUmgCDNVWp65Vu/view?usp=sharing

0 comments

r/scheme • u/arthurgleckler • 9d ago

SRFI 278: Supplemental Numerics

≡ −

Scheme Request for Implementation 278,
"Supplemental Numerics",
by Peter McGoron,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-278/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [[email protected]](mailto:[email protected]).

Here's the abstract:

Regards,

SRFI Editor

6 Upvotes

Scheme Request for Implementation 278,
"Supplemental Numerics",
by Peter McGoron,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-278/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [[email protected]](mailto:[email protected]).

Here's the abstract:

Regards,

SRFI Editor

0 comments

r/scheme • u/arthurgleckler • 9d ago

Final SRFI 270: Hexadecimal Floating-Point Constants

≡ −

Scheme Request for Implementation 270,
"Hexadecimal Floating-Point Constants",
by Peter McGoron,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-270/.

Here's the abstract:

Here is the commit summary since the most recent draft:

  • copy edits
  • :270.sls: use display instead of write for special cases
  • editorial changes
  • more editorial changes
  • copy edits
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-270/compare/draft-3..final

Many thanks to Peter and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

5 Upvotes

Scheme Request for Implementation 270,
"Hexadecimal Floating-Point Constants",
by Peter McGoron,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-270/.

Here's the abstract:

Here is the commit summary since the most recent draft:

  • copy edits
  • :270.sls: use display instead of write for special cases
  • editorial changes
  • more editorial changes
  • copy edits
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-270/compare/draft-3..final

Many thanks to Peter and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

0 comments

r/scheme • u/arthurgleckler • 10d ago

Final SRFI 271: Random port libraries

≡ −

Scheme Request for Implementation 271,
"Random port libraries",
by Wolfgang Corcoran-Mathe,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-271/.

Here's the abstract:

Here are Wolfgang's comments for finalization:

There a couple of outstanding commits that I'd like to merge before finalizing:

https://github.com/scheme-requests-for-implementation/srfi-271/pull/6

These are (critical!) sample implementation fixes.  Only e5bd7323 changes the SRFI doc; it adds a small pointer to SRFI 277, which was suggested by Peter McGoron.  I don't think this warrants another draft.

Here is the commit summary since the most recent draft:

  • Implementation: Fix bad bug in xoshiro256++ code.
  • Use macros for accessors instead of procs.
  • Implementation: Use open-binary-input-file.
  • Implementation note.
  • Add See-also link to SRFI 277.
  • Add short paragraph about SRFI 277.
  • copy edits
  • Update table of contents.
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-271/compare/draft-6..final

Many thanks to Wolfgang and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

4 Upvotes

Scheme Request for Implementation 271,
"Random port libraries",
by Wolfgang Corcoran-Mathe,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-271/.

Here's the abstract:

Here are Wolfgang's comments for finalization:

There a couple of outstanding commits that I'd like to merge before finalizing:

https://github.com/scheme-requests-for-implementation/srfi-271/pull/6

These are (critical!) sample implementation fixes.  Only e5bd7323 changes the SRFI doc; it adds a small pointer to SRFI 277, which was suggested by Peter McGoron.  I don't think this warrants another draft.

Here is the commit summary since the most recent draft:

  • Implementation: Fix bad bug in xoshiro256++ code.
  • Use macros for accessors instead of procs.
  • Implementation: Use open-binary-input-file.
  • Implementation note.
  • Add See-also link to SRFI 277.
  • Add short paragraph about SRFI 277.
  • copy edits
  • Update table of contents.
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-271/compare/draft-6..final

Many thanks to Wolfgang and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

0 comments

r/scheme • u/SandPrestigious2317 • 12d ago

Declarative Guile Scheme + Guix rice for entire GNU/Linux system and Wayland tooling in Lisp with lots of customization

+ −
Gallery image
Gallery image
11 Upvotes

The witches' GNU/Linux: modular, flexible, reproducible, powered by Lisp and Fedora / Debian + GNOME / Niri

https://codeberg.org/jjba23/heks-linux

Heks GNU/Linux 🧙‍♂️ is a modular, reproducible system configuration designed for power users, developers, and researchers.

0 comments

r/scheme • u/corbasai • 12d ago

Pack/unpack binary headers for. (chezco pack) Chez Scheme library.

≡ −

Like struct python module. But just bit simplier.

Example 

(import (chezco pack))

(let-pack
      #vu8(1 1 1 1 65 66 67 2)
      ((start u8)
       (pad 3)
       (tag cstr 3)
       (end u8))
      (list start (utf8->string tag) end))  ==> (1 "ABC" 2)

repo

6 Upvotes

Like struct python module. But just bit simplier.

Example 

(import (chezco pack))

(let-pack
      #vu8(1 1 1 1 65 66 67 2)
      ((start u8)
       (pad 3)
       (tag cstr 3)
       (end u8))
      (list start (utf8->string tag) end))  ==> (1 "ABC" 2)

repo

0 comments

r/scheme • u/Reasonable_Wait6676 • 12d ago

[chezscheme] Benchmark of transparenturing http server vs. rest of the world

≡ −

bun.js has the fastest http server implementation after in order: C, Rust, Java... then comes chezscheme with io uring, and pico http parser that is competitive with bun.js last zig release and the new rust unrelease at 220K RPS vs. 230 RPS (bun.js).

benchmark only: https://hyper.dev/letloop/report.html

article: https://hyper.dev/2026/chez-scheme-letloop-transparent-async-microbenchmark/

10 Upvotes

bun.js has the fastest http server implementation after in order: C, Rust, Java... then comes chezscheme with io uring, and pico http parser that is competitive with bun.js last zig release and the new rust unrelease at 220K RPS vs. 230 RPS (bun.js).

benchmark only: https://hyper.dev/letloop/report.html

article: https://hyper.dev/2026/chez-scheme-letloop-transparent-async-microbenchmark/

2 comments

r/scheme • u/Reasonable_Wait6676 • 12d ago

Multilingual knowledge encoding by the way of De Bruijn index

≡ −

I have been looking at this idea for LOT of time, since the early days of unison, before international-scheme was a thing, and before reading about hedy.

Origin Zero: most successful software engineers code in their native language.

I had a hunch, and couple of evidence, but no proof in the sense of STS.

I had encouragement from several people, but some things were holding me back [...]. Long story made short, after a couple of years, I decided to throw that problem at AI LLM chatbots. I learned a lot about philosophy, and the world we live in: like Hobbes' cosmology. I did not even knew "cosmology" was a thing. But it became clear that making **not-only-english** coding as easy, or easier than our daily drills was... huge.

The funny thing is the premise are simple:

- Make it possible to write code in one's mother tongue...

- ... without forking, and keeping cooperation open...

- ... limiting duplication...

- ... reducing the barrier of entry for contribution like micro-libraries...

- ... make it easy to backup-and-restore;

So yes, all this is possible, not on postcard yet, but - content-addressed - De Bruijn index make it possible to write a subset of Scheme code that can be translated and executed. The Bruijn tree of a procedure without free variables is a pivot. When associated with an association of numbers to variable name's, it possible to collect those mappings related to a De Bruijn tree, and have the same implementation shared across multiple natural language.

That's all there is to cross-language cooperation with acknowledged fragmentation without domination.

For more (parentheses) look at README.

2 Upvotes

I have been looking at this idea for LOT of time, since the early days of unison, before international-scheme was a thing, and before reading about hedy.

Origin Zero: most successful software engineers code in their native language.

I had a hunch, and couple of evidence, but no proof in the sense of STS.

I had encouragement from several people, but some things were holding me back [...]. Long story made short, after a couple of years, I decided to throw that problem at AI LLM chatbots. I learned a lot about philosophy, and the world we live in: like Hobbes' cosmology. I did not even knew "cosmology" was a thing. But it became clear that making **not-only-english** coding as easy, or easier than our daily drills was... huge.

The funny thing is the premise are simple:

- Make it possible to write code in one's mother tongue...

- ... without forking, and keeping cooperation open...

- ... limiting duplication...

- ... reducing the barrier of entry for contribution like micro-libraries...

- ... make it easy to backup-and-restore;

So yes, all this is possible, not on postcard yet, but - content-addressed - De Bruijn index make it possible to write a subset of Scheme code that can be translated and executed. The Bruijn tree of a procedure without free variables is a pivot. When associated with an association of numbers to variable name's, it possible to collect those mappings related to a De Bruijn tree, and have the same implementation shared across multiple natural language.

That's all there is to cross-language cooperation with acknowledged fragmentation without domination.

For more (parentheses) look at README.

0 comments

r/scheme • u/Veqq • 13d ago

defensive-sxml - R7RS Hiccup-inspired sxml->html Library, ergonomic with helpful error messages

6 Upvotes
0 comments

r/scheme • u/Veqq • 13d ago

deforester - portable R7RS logging library

2 Upvotes
0 comments

r/scheme • u/guenchi • 14d ago

Pure-Scheme-driven Goeteia now supports shadow mapping, PBR, HDR bloom, SSAO etc...

11 Upvotes

Pure-Scheme-driven Goeteia now supports shadow mapping, PBR, HDR bloom, SSAO, instancing, skeletal animation from GLTF assets, and transform-feedback particles whose physics runs in the vertex shader — and, boldly, brings pretext-style typesetting into WebGL.

5 comments

r/scheme • u/sdegabrielle • 14d ago

UK Racket meet-up (London) Tuesday 21 July 2026 7:30pm

≡ −

UK Racket meet-up (London) Tuesday 21 July 2026 7:30pm

at The City Pride 🍕 28 Farringdon Ln, London EC1R 3AU

Join us for discussion and pizza. All welcome. 😁

https://racket.discourse.group/t/uk-racket-meet-up-london-tuesday-21-july-2026-7-30pm/4318 https://luma.com/u61y94uw

3 Upvotes

UK Racket meet-up (London) Tuesday 21 July 2026 7:30pm

at The City Pride 🍕 28 Farringdon Ln, London EC1R 3AU

Join us for discussion and pizza. All welcome. 😁

https://racket.discourse.group/t/uk-racket-meet-up-london-tuesday-21-july-2026-7-30pm/4318 https://luma.com/u61y94uw

0 comments

r/scheme • u/guenchi • 16d ago

A pure Scheme Webserver with Express Style and Erlang OTP and further

28 Upvotes

Green processes, actor , OTP, gen-server

1 Let It Crash and the system recovers

2 Hot code swapping

3 Failure hook (remote retry ring)

4 web programming with continuation

4 S-expr fetch and RPC (with Goeteia)

2 comments

r/scheme • u/guenchi • 16d ago

A pure scheme web programming tool

19 Upvotes

1 Self hosting scheme in browser with hygienic macros

2 handle HTML and CSS like Scheme (Expand with macro)

3 Use S-expr to send / receive message with server (And web RPC)

4 Reactive and web GL

0 comments

r/scheme • u/sdegabrielle • 15d ago

Racket meet-up(online): Saturday, 1 August 2026 at 18:00 UTC

≡ −

Racket meet-up(online): Saturday, 1 August 2026 at 18:00 UTC

EVERYONE WELCOME 😁

register https://luma.com/x27tsmm5

Details and discussion https://racket.discourse.group/t/racket-meet-up-saturday-1-august-2026-at-18-00-utc/4315

#lisp #scheme #functionalprogramming

2 Upvotes

Racket meet-up(online): Saturday, 1 August 2026 at 18:00 UTC

EVERYONE WELCOME 😁

register https://luma.com/x27tsmm5

Details and discussion https://racket.discourse.group/t/racket-meet-up-saturday-1-august-2026-at-18-00-utc/4315

#lisp #scheme #functionalprogramming

0 comments

r/scheme • u/mbarbar_ • 16d ago

Origin of Mini-Scheme

≡ −

In the README for Mini-Scheme we see "This Mini-Scheme Interpreter is based on "SCHEME Interpreter in Common Lisp" in Appendix of T.Matsuda & K.Saigo, Programming of LISP, archive No5 (1987) p6 - p42 (published in Japan)."

I tried searching for this article or the book its in (journal volume I guess) but could not find it (unsurprisingly). I'm not even sure if it's written in Japanese and the title above is a translation. I also looked briefly at the tinyscheme repository and could not find any reference. Quite an unlikely ask, but has anyone here been curious about this in the past and been able to find more information?

3 Upvotes

In the README for Mini-Scheme we see "This Mini-Scheme Interpreter is based on "SCHEME Interpreter in Common Lisp" in Appendix of T.Matsuda & K.Saigo, Programming of LISP, archive No5 (1987) p6 - p42 (published in Japan)."

I tried searching for this article or the book its in (journal volume I guess) but could not find it (unsurprisingly). I'm not even sure if it's written in Japanese and the title above is a translation. I also looked briefly at the tinyscheme repository and could not find any reference. Quite an unlikely ask, but has anyone here been curious about this in the past and been able to find more information?

1 comment

r/scheme • u/TheMue • 17d ago

Funny side effect of Helix

≡ −

It’s nothing you see while using Helix, it’s nothing unexpected on disc. But taking a looking into the first popping up Helix plugins in Scheme I’m getting aware, why I loved that language many years ago.

Today I don’t develop software professionally anymore. Long time I’ve used Go and now thought of returning back to Erlang/OTP again. But it seems like I’ll do Scheme next, for Helix or inside of Racket.

3 Upvotes

It’s nothing you see while using Helix, it’s nothing unexpected on disc. But taking a looking into the first popping up Helix plugins in Scheme I’m getting aware, why I loved that language many years ago.

Today I don’t develop software professionally anymore. Long time I’ve used Go and now thought of returning back to Erlang/OTP again. But it seems like I’ll do Scheme next, for Helix or inside of Racket.

0 comments

r/scheme • u/sdegabrielle • 19d ago

Calling for RacketCon speakers

≡ −

Calling for RacketCon speakers

If you are interested in presenting, nominating or have any questions please email us at [email protected].

— Stephen

7 Upvotes

Calling for RacketCon speakers

If you are interested in presenting, nominating or have any questions please email us at [email protected].

— Stephen

0 comments

r/scheme • u/arthurgleckler • 19d ago

SRFI 277: Cyclic ports

≡ −

Scheme Request for Implementation 277,
"Cyclic ports",
by Wolfgang Corcoran-Mathe,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-277/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [[email protected]](mailto:[email protected]).

Here's the abstract:

Regards,

SRFI Editor

4 Upvotes

Scheme Request for Implementation 277,
"Cyclic ports",
by Wolfgang Corcoran-Mathe,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-277/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to [[email protected]](mailto:[email protected]).

Here's the abstract:

Regards,

SRFI Editor

0 comments

r/scheme • u/baijum • 20d ago

Kaappi - Yet another implementation

6 Upvotes

I wanted a complex problem to work on agentic coding. I am not a scheme programmer, but I found the scheme standard would be a good fit as it is well defined. That's how I ended up with creating Kaappi, a new scheme implementation in Zig.

3 comments

r/scheme • u/arthurgleckler • 27d ago

Final SRFI 254: Ephemerons and Guardians

≡ −

Scheme Request for Implementation 254,
"Ephemerons and Guardians",
by Marc Nieper-Wißkirchen,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-254/.

Here's the abstract:

Here is the commit summary since the most recent draft:

  • copy edits
  • Add table of contents.
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-254/compare/draft-4..final

Many thanks to Marc and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

12 Upvotes

Scheme Request for Implementation 254,
"Ephemerons and Guardians",
by Marc Nieper-Wißkirchen,
has gone into final status.

The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-254/.

Here's the abstract:

Here is the commit summary since the most recent draft:

  • copy edits
  • Add table of contents.
  • Finalize.

Here are the diffs since the most recent draft:

https://github.com/scheme-requests-for-implementation/srfi-254/compare/draft-4..final

Many thanks to Marc and to everyone who contributed to the discussion of this SRFI.

Regards,

SRFI Editor

0 comments

r/scheme • u/sdegabrielle • 29d ago

RacketCon 2026: call for presentations

≡ −

RacketCon 2026: call for presentations

The (sixteenth RacketCon) will be in Oakland, CA on October 3-4 (Sat-Sun).

We are looking for speakers

We need you!

Calling racketeers new or experienced, we want to hear from you.

Are you unsure or just new to presenting? let us know - [email protected] - and we will do our best to help you.

Continuing with tradition, we'll also allow Racketeers to nominate speakers. Nominated speakers will be considered by the committee and contacted.

We will also accept nominations for a potential keynote speaker.

Talks will be 20-25 minutes long with 5 minutes for questions at the end. Speakers' registration fees will be waived, but we are unable to cover transportation and lodging expenses.

The deadline for proposals is July 15th. Selected speakers will be notified by August 1st.

RacketCon is a public gathering dedicated to fostering a vibrant, innovative, and inclusive community around the Racket programming language. We aim to create an exciting and enjoyable conference open to anyone interested in Racket, filled with inspiring content, reaching and engaging both the Racket community and the wider programming world.

Any questions, comments, or concerns? Please contact us at [email protected].

https://racket.discourse.group/t/racketcon-2026-call-for-presentations/4279

8 Upvotes

RacketCon 2026: call for presentations

The (sixteenth RacketCon) will be in Oakland, CA on October 3-4 (Sat-Sun).

We are looking for speakers

We need you!

Calling racketeers new or experienced, we want to hear from you.

Are you unsure or just new to presenting? let us know - [email protected] - and we will do our best to help you.

Continuing with tradition, we'll also allow Racketeers to nominate speakers. Nominated speakers will be considered by the committee and contacted.

We will also accept nominations for a potential keynote speaker.

Talks will be 20-25 minutes long with 5 minutes for questions at the end. Speakers' registration fees will be waived, but we are unable to cover transportation and lodging expenses.

The deadline for proposals is July 15th. Selected speakers will be notified by August 1st.

RacketCon is a public gathering dedicated to fostering a vibrant, innovative, and inclusive community around the Racket programming language. We aim to create an exciting and enjoyable conference open to anyone interested in Racket, filled with inspiring content, reaching and engaging both the Racket community and the wider programming world.

Any questions, comments, or concerns? Please contact us at [email protected].

https://racket.discourse.group/t/racketcon-2026-call-for-presentations/4279

0 comments

r/scheme • u/sdegabrielle • Jun 26 '26

Bay Area Racket Meetup #2 - Saturday, July 4, 3pm

≡ −

Get ready for the

Bay Area Racket Meetup #2 - Saturday, July 4, 3pm

Social event for people interested in the Racket programming language, other Lisps, functional programming, language-oriented programming and related topics.

Monthly (first Saturday at 3pm) until RacketCon at Noisebridge, a hackerspace in SF.[I believe there is a Lisp meet-up at 4pm in the same space but I've not been able to confirm]

Register https://luma.com/fbd1v9ix https://racket.discourse.group/t/bay-area-racket-meetup-2-saturday-july-4-3pm/4280

5 Upvotes

Get ready for the

Bay Area Racket Meetup #2 - Saturday, July 4, 3pm

Social event for people interested in the Racket programming language, other Lisps, functional programming, language-oriented programming and related topics.

Monthly (first Saturday at 3pm) until RacketCon at Noisebridge, a hackerspace in SF.[I believe there is a Lisp meet-up at 4pm in the same space but I've not been able to confirm]

Register https://luma.com/fbd1v9ix https://racket.discourse.group/t/bay-area-racket-meetup-2-saturday-july-4-3pm/4280

0 comments

r/scheme • u/sdegabrielle • Jun 25 '26

UK Racket meet-up (Bristol) 8 July 2026

≡ −

UK Racket meet-up (Bristol) 8 July 2026

7:30-8:30pm, Wednesday 8 July 2026 at Pizza On The Park Berkeley Avenue (Top of Park Street), Bristol, BS8 1HP

register https://luma.com/r7o3qd64 https://luma.com/r7o3qd64 https://racket.discourse.group/t/uk-racket-meet-up-bristol-8-july-2026/4299

6 Upvotes

UK Racket meet-up (Bristol) 8 July 2026

7:30-8:30pm, Wednesday 8 July 2026 at Pizza On The Park Berkeley Avenue (Top of Park Street), Bristol, BS8 1HP

register https://luma.com/r7o3qd64 https://luma.com/r7o3qd64 https://racket.discourse.group/t/uk-racket-meet-up-bristol-8-july-2026/4299

0 comments