McCLIM
slime
McCLIM | slime | |
---|---|---|
8 | 14 | |
574 | 1,855 | |
- | 1.0% | |
9.0 | 8.2 | |
about 1 year ago | 3 days ago | |
Common Lisp | Common Lisp | |
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
McCLIM
-
McCLIM respository migrates to Codeberg.
There's also Drei that comes with McClim as the editor substrate that can be included like a widget in any app. https://github.com/McCLIM/McCLIM/tree/master/Documentation/Drei
-
Looking for good common lisp projects on github to read?
0 https://github.com/McCLIM/McCLIM
-
Lisp in Vim with Slimv or Vlime (2019)
I've been really happy with slimv. There are a few things missing that I'd like to have were I to find myself working on a really large program with a bunch of other programmers, though I suspect the commercial Lisps offer a good approximation. Besides the trivial things like more auto-refactoring tools (thanks to cross-referencing I can at least get a list of all the locations something is used and jump to edit them one by one if necessary) and project organization tools (I've started using @export from https://github.com/m2ym/cl-annot rather than going back to my package definition to keep adding symbols to the export list) I'd like a better line debugger. It hasn't been a hurdle so far because what's there is good enough (as the article describes, when you hit the debugger you get your stack, you can inspect stuff in the frame, you can recompile and then restart computation from a frame instead of aborting the whole thing). If your declaim settings are right you can also step your code and so on within vim but it's kind of clunky, I'd rather launch a dedicated GUI that's at least as nice as the old Insight GDB wrapper. When inspecting complex data I've started to use the McCLIM app Clouseau: https://github.com/McCLIM/McCLIM/tree/master/Apps/Clouseau I bound ,ci to call (clouseau:inspect) on the symbol and that launches a nice enough GUI to explore it. (Repeated periodically in a thread also serves as a poor man's variable watcher...) A handful of other vim plugins make the full experience even better (even when not writing lisp).
It's been pretty amusing watching the LSP landscape evolve for other languages, it's almost like swank for CL. But it's rather nice to have the server be embedded in the process itself. On my personal web server I have a compiled lisp binary running, but I shipped it with swank listening on a local port, so if I want to change something without rebuilding and redeploying I can just SSH in while forwarding port 4005, connect to the lisp image with my local editor, and recompile functions or whatever. At my last job I also inserted ABCL into the huge Java app on my dev box and had it start a swank server, letting me connect with vim and mess around -- it was mostly useful for quickly launching system tests which otherwise had a dedicated clunky browser UI, and writing some code to quickly extract or insert data. I had some designs to write some webdriver tests in Lisp and demo how the debugging experience when one fails can be much better (not having to restart the whole flow because a UI element changed its class name or whatever and threw an exception) so as to introduce the language to the broader company officially, but never got around to it before I left.
-
Learn Common Lisp by Example: GTK GUI with SBCL
Currently, the only officially supported backend renders directly to an X server. Until another backend matures that either wraps native controls or draws more modern looking controls using OpenGL, I don't consider it production ready. It might have a really nifty API, but it comes down to would I want to put a GUI made with McClim in front of someone who paid for the app I created.
-
Lisp Implementations similiar to old Lisp Machines?
But I don't want to have a net negative contribution to this thread, so I'd also recommend looking at some of the McCLIM applications, including the inspector Clouseau, editor Climacs and the CLIM interactor, which are very much Lisp machine-inspired.
-
McCLIM — A powerful GUI toolkit for Common Lisp
Regarding HiDPI there are some ideas, but right now they are not implemented (see i.e https://github.com/McCLIM/McCLIM/issues/827). I'm writing a vt100 terminal backend to reveal some underlying assumptions about the pixel size.
Thank you for working on McCLIM back then! If you feel motivated to join development efforts please don't hesitate joining #clim @ freenode :)
-
Help me to find a language to describe user interfaces
Remembered this post when github suggested me this project: https://github.com/McCLIM/McCLIM
slime
- Emacs 28 can not run Slime
-
Anyone know why newlines get randomly inserted when printing a list with format on emacs + slime?
Try https://github.com/slime/slime/commit/e6a71c725c8e13d7d4c40e6a6fa7b696575a8d01
-
So i wanna learn Common Lisp
With emacs your two choices are either SLIME or SLY. Slime is a good place to start - it's rock solid. Once you get moving you can make a judgement call on whether or not SLY has features you'd like over what SLIME has available.
-
Common Lisp vs Racket
To provide a bit more context, most of SLIME is just Common Lisp code (https://github.com/slime/slime), with a bunch of Emacs Lisp code alongside to support interfacing with Emacs. But you don't need that Emacs Lisp code to take advantage of almost all of the functionality SLIME provides. For instance, if you want to know who-calls a function, there's some command in emacs to do it, but all that command is doing is just a bit of elisp code which sends a message to Swank (a server running inside Common Lisp) and Swank invokes some native CL code to figure that out and return the results, then finally a bit of elisp code presents the results in some way. Vim can do the same thing just fine with vimscript/python (what the Slimv plugin uses) or otherwise, the bulk of the work in figuring out the list of callers of some function is done by the CL code (and CL implementation itself).
-
What does your workflow look like on Linux?
SLIME or SLY for Common Lisp (if you want to work with it), Geiser for various Schemes
-
slime-pop-find-definition-stack not working
That's rather new, https://github.com/slime/slime/commit/789584a7acb15747678fa62a8fcfc8d1187be867 is probably about that.
- Offline Hyperspec? html, texinfo, org, something?
-
Slime
With that headline on HN, I was expecting this: https://common-lisp.net/project/slime/
-
Python REPL-driven development in Emacs
SLIME or Sly for Common Lisp, Geiser for most Scheme implementations, or racket-mode for Racket?
-
Is there a possibility to have a master stack in bspwm like in dwm?
For example, some people that are Common Lisp programmers, but don't use GNU Emacs, may decide to use GNU Emacs because of the slime-mode workflow.
What are some alternatives?
ChrysaLisp - Parallel OS, with GUI, Terminal, OO Assembler, Class libraries, C-Script compiler, Lisp interpreter and more...
sly - Sylvester the Cat's Common Lisp IDE
kons-9 - Common Lisp 3D Graphics Project
portacle - A portable common lisp development environment
nyxt - Nyxt - the hacker's browser.
paip-lisp - Lisp code for the textbook "Paradigms of Artificial Intelligence Programming"
Smalltalk - By the Bluebook implementation of Smalltalk-80
hebigo - 蛇語(HEH-bee-go): An indentation-based skin for Hissp.
Smalltalk - By the Bluebook implementation of Smalltalk-80
bsp-layout - Manage layouts in bspwm (tall and wide)
cl-annot - Python-like Annotation Syntax for Common Lisp
common-lisp-jupyter - A Common Lisp kernel for Jupyter along with a library for building Jupyter kernels.