An idea to defeat #GenerativeAI in #FreeSoftware:

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

New book: “The Genius of Lisp” by Cees de Groot

Looks like a fascinating read! They have provided chapter 8 as a PDF file downloadable gratis as a sneak-peek into the rest of the book, guess what it’s about:

Chapter 8: Sussman and Steel make Scheme

Awesome! I can’t wait to read that chapter, and then the rest of the book!

Details on the book homepage: https://berksoft.ca/gol/

#tech #software #Lisp #Scheme #SchemeLang #R7RS

RE: https://mstdn.ca/@cdegroot/116086771614712320

#Schemacs update

I decided to merge my #Scheme react-like declarative GUI framework (schemacs ui), even though the back-end isn’t completely bug-free yet. (It is still an experimental software project, so the main branch is the development branch).

Though it is written in pure #R7RS “small” Scheme, the only GUI back-end currently available is for Guile users who go to the trouble to install Guile-GI all on their own.

If Guile-GI is installed, put on your safety goggles and run this command in the Guile REPL:

(load "./main-gui.scm")

I haven’t tried getting it to work in a Guix shell for almost a year now, but my last attempt did not go well (it crashed while initializing Gtk). To anyone who wants to try the GUI, I am sorry to inconvenience you, but I’m afraid I just have to ask you to please install Guile-GI yourself using the old-fashioned ./configure && make && make install method. If anyone happens to be able to get it to work in a Guix shell, please let me know, or open a PR on the Codeberg Git repository.

The only examples for how to use (schemacs ui) are in the test suite and the Schemacs Debugger. The only documentation so far are the comments in the source code, though I did try to be very thorough with comments.

The “Debugui” debugger works, but only has one single feature: the eval-expression command, which is bound to M-: (Alt-Colon). This command works the same as in #Emacs but you enter a Scheme language command instead. The #EmacsLisp interpreter is not yet connected to the GUI.

Now that this is merged, I am going to work on a few tasks in the Emacs Lisp interpreter that have been pending for more than a few weeks now. Then, back to creating new features in the GUI toward the goal of making it a useful program editor. And also, of course, writing some more documentation.

#tech #software #R7RS #SchemeLang

#Schemacs update

I have been banging my head against #Gtk3 for the past 3 weeks and all progress has pretty much come to a stand-still. No matter how simple and straight-forward my GUI is, Gtk makes it simply impossible to get the layout correct. I am now convinced that programming my own layout algorithm from scratch and using the GtkLayout container (which lets you place widgets at arbitrary X,Y coordinates) is the only way to proceed at this point. It is soooo frustrating.

The #Gtk documentation is good, but not at all good enough. The people on the Gnome Discourse have been very kind and helpful, and I truly appreciate the engagement I have had there, but ultimately I am still not able to solve my problems.

I have decided I need find some way to keep making progress without postponing the release of the work I have done so far for an indeterminate length of time. So rather than work out all the bugs in this version before merging it to the main Git branch, what I will do instead is have the main program launch a debugger window. The debugger window will have all layout calculated in advance, and all widgets will be declared once and only once throughout the lifetime of the application to avoid the reference counting issues. Obviously the debugger GUI will be very rigid, but you will at least be able to edit files and run commands in a REPL within this debugger.

Then maybe I can merge the code I have written to the main Git branch, and people will at least be able to use it through the debugger. Maybe also I could use this debugger to help with writing my layout algorithm. Also, I need to get back to the Emacs Lisp interpreter, I haven’t worked on it in almost two months now.

#tech #software #Lisp #Emacs #EmacsLisp #Scheme #SchemeLang #R7RS

Can't get GtkScrolledWindow to use all available space, seems to ignore "vexpand" and "valign"

(In Gtk3) I am ordering elements in a GtkApplicationWindow. The app window’s top-level layout container is a GtkBox with vertical orientation. The box contains two elements, a GtkScrolledWindow (with a GtkTextView inside of it), and GtkLabel below for reporting messages. I made sure the top-level Box and the GtkScrolledWindow both have their expand properties set to TRUE, and both have their valign and halign properties set to fill. I made sure to call pack_start with the expand and fill argume...

GNOME Discourse
Kent Pitman presents his lisp condition system implemented for python

PeerTube

@screwlisp @kentpitman I’m just reading up on the MIT-Scheme condition system. Recent efforts to standardize this are defined in SRFI-255: “Restarting conditions”.

An older standards condition systems in Scheme was defined in SRFI-35: “Conditions”. And #Guile users can use the Guile implementation of SRFI-35 to make use of it.

I wish I had known about this two weeks ago when we first started talking about it on the #LispyGopherClimate show, but better late than never, I guess.

#tech #software #Lisp #CommonLisp #Scheme #SchemeLang #R7RS #MITScheme #Guile #GuileScheme

Error System (MIT/GNU Scheme 12.1)

Error System (MIT/GNU Scheme 12.1)

Ouch, #Guile #Scheme has betrayed me

I am using Guile-GI the GObject Introspection framework for Guile, and discovered that the eq? predicate sometimes returns #t for two different symbols. Does #GOOPS allow overloading eq? on symbols such that it can return #t on different symbols? If so this seems like a huge problem to me, it completely violates the Scheme language specification. (Or should I ask, is this a “GOOPS oopsie?”)

Anyway, what happens is this: you can capture a Gtk keyboard event in an event handler, and extract the list of modifier keys pressed on that key event. It looks something like this:

(lambda (event) (let*-values (((state-ok modifiers) (event:get-state event)) ((mod-bits) (modifier-type->number modifiers)) ((first-mod) (car mod-bits))) (display "first modifier: ") (write first-mod) (newline) (display "is symbol? ") (write (symbol? first-mod)) (newline) (display "eq? to 'mod1-mask: ") (write (eq? 'mod1-mask first-mod)) (newline) #t ))

And the output of the above event handler, when I press a key with a CJK input method enabled (on latest Linux Mint) is this:

first modifier: modifier-reserved-25-mask is symbol? #t eq? to 'mod1-mask: #t

The fact that (eq? 'mod1-mask 'modifier-reserved-25-mask) when the 'modifier-reserved-25-mask has been obtained from a C-language FFI callback is a pretty bad thing to happen in a Scheme implementation, in my humble opinion.

#tech #software #Schemacs #SchemeLang #R7RS

guile-gi 0.3.2-0.388653a — Packages — GNU Guix

GObject bindings for Guile

#Schemacs Update

I have partially resolved the issue I mentioned in my #EmacsConf2025 presentation, regarding the closure of a lambda not correctly capturing it’s environment.

I say “partially” resolved because although my current solution results in correct program behavior, it does not consider let-bound variables inside of the closure. So variables declared locally to the closure using the let keyword will mask variables of the same name in the closure environment. A correct implementation will simply not include those masked variables in the closure environment at all. This can sometimes impact garbage collection, since a closure may be holding a variable which retains a large amount of memory, but that variable not accessible anywhere since it is masked by the let-bound variables in the closure.

However, I am eager to keep things moving, so I am merging this PR and opening a new issue to resolve the let-bindings problem later. To find out more, see issue #62 on Codeberg.

#tech #software #Emacs #EmacsConf #Scheme #R7RS #SchemeLang

bugfix! issue #55: constucting a closure captures environment

closes #55 This patch will cause the construction of a `lambda` closure to ensure the symbols referred to by all local variables defined within the `defun` context are always included in the closure and can be referenced when the closure is evaluated. A simple test to make sure this works as ex...

Codeberg.org
I decided it was time to add a Code of Conduct to #Schemacs

https://codeberg.org/ramin_hal9001/schemacs/src/branch/main/CONTRIBUTING.md

I have been getting a lot of inquiries about Schemacs lately, and so I think it is best to settle on a Code of Conduct (CoC) right now before I find myself in the awkward position of accepting a lot of patches from various people who later on turn out to hate each other. Hopefully we wont ever find ourselves in such a situation, but it is best to be prepared.

I decided to go with the Contributor Covenant 3.0, which provides a template for a CoC that adapts well to various projects. If I recall correctly, I believe I learned about it from Christine Lemmer-Webber @cwebber on one of her podcasts.

I am open to recommendations for changes to be made to the CoC as well, I understand that my knowledge of such things is imperfect and I am willing to learn about various opinions regarding codes-of-conduct if anyone is willing to teach me more.

And of course, #Schemacs is free software, so anyone is welcome to fork it and develop it separately if you disagree with the CoC. But as long as I am the project manager for #Schemacs I will make the executive decision about the CoC.

#tech #software #CodeOfConduct #Scheme #SchemeLang #R7RS #Lisp #Emacs #FLOSS #FOSS

Cookie monster!

My EmacsConf presentation on Schemacs

— will be live in about 5 minutes.

https://emacsconf.org/2025/watch/dev

Questions can be posted to this live chat: https://pad.emacsconf.org/2025-schemacs

EDIT: Thanks for all the great questions everyone. It is so encouraging for me to see that there is so much interest in this project, it really keeps me motivated to keep working on it.

#tech #software #Emacs #SoftwareDevelopment #EmacsConf #EmacsConf2025 #SchemeLang #R7RS #Scheme

EmacsConf - 2025 - talks - One year progress update Schemacs (formerly Gypsum)