#r7rs — Public Fediverse posts

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

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

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

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

Quoting the memo:

The outgoing Steering Committee was elected in 2009 and successfully oversaw the production and ratification of the R7RS small language report until 2013. Unfortunately, during the protracted initial development of the R7RS large language after that, it fell dormant.

The current Scheme Working Group resolved in September 2025 to ask the Steering Commitee for a new election because it felt that after such long dormancy the outgoing Steering Committee was no longer able, as a group, to make and implement decisions effectively.

The Scheme standardization process charter says, ‘The Steering Committee itself shall establish procedures for replacing its members.’ The outgoing Steering Committee unanimously decided to delegate this task to the current Working Group. The Working Group has very closely modelled the procedure to be used this time on the procedure used last time.

The Working Group has written a statement to candidates and voters explaining what it hopes for in a new steering committee.

Lobste.rs thread

#tech #software #Scheme #SchemeLang #ProgrammingLanguage #R7RS #R7RSLarge #Lisp #FunctionalProgramming #Guile #GuileScheme #ChezScheme #ChickenScheme #GambitScheme #RacketLang #Racket