λ - programming

>>12467

My first question is, knowing this type of system is possible, what are some parts of web or native runtime that'd you would like to see pulled into Lisp execution?

Is there a good command line windowing tool for manipulating windows in X?

How can I/we hook X keyboard/mouse input through Emacs/SBCL? How do you bind X window commands or listeners from an external program?

>>12469
>Is there a good command line windowing tool for manipulating windows in X?
not sure but you have a whole window manager written in common lisp so I'd say you could use at least part of the code
https://stumpwm.github.io/

>>12470

this goes against the my point virtualization; that library may not have all the functionality of other WMs or may not even see support in a few years, and new adopters of a Lisp virtual machine may wish to reuse utilities they are already familiar with or that their current desktop setup depends on, abstracting out commonly used command line utilities would also encourage more people to use a lisp virtual machine than having to completely learn a new system

>>12469
Wouldn't CLX work for that?http://www.cliki.net/CLX

Also I am interested in the project but sadly I don't know where to start. Maybe an init? After al, it IS init that starts userspace.
I don't know what your ideas are, off the top of my head, a sort of kernel interface that takes sexprs and does all syscalls. It ciuld sort of divide the userspace into a C portion, where libraries get loaded as well as C-based end user applications, and the less nice (in the unix sense) sbcl environment which does the rest with the resources taken directly from the kernel and the low level interactions with the C portion

>>12473
Of course it'd be greatmif (for simplicity) we could do witout C entirely in the first stages, so we just get a kernel+sbcl. We could the go by layers and have, for starters, a simple syscall-lisp. On top of that we can make just about anything, let me look at the dependencies for sbcl and if it can be linked with static libraries...

>>12473

I think a great way we can start this is by an SBCL+Emacs installer init .el+.lisp bundle (first workflow is open emacs load an .el file downloaded from the internet to install required packages/files)

>C portion

this would be excellent for expanding eventual cross-platform Emacs kernel (as a fork or as a package-like thing?) functionality as well and should be organized accordingly

Repo here folks

https://github.com/olewhalehunter/mycelium


>>12474

all this can be done, there needs to be a concern for a formalized system of options for choosing configurations during installation; some may not want native call permissions and wish to use their own management programs, thus everything needs to be abstracted out appropriately by some system given a base SBCL+emacs installation (I exclude linux as a given because we may wish to even provide utilities for windows client platforms, I like to create portable installations by usb to use on random computers sometimes)


C libs need to not be leaky, the user should not have to hunt the internet to find drivers, dlls, libs; the system should assume nothing until the user chooses something and things are installed to completion

utilities as lisp objects should be tagged by manual functionality as assigned (assignments may be configured); ie windowing utilities that you use to manipulate the desktop should be tagged in a category; our tags for this organization should be flexible, subject to change with regard for linguistic relativity, peripheral device use, workflows ec etc

also importantly:

common lisp should be the preferred runtime/language for the bulk of work, emacs lisp should /only/ be used for binds to buffers with async io, macros, etc

other things;

S-exp/macro evaluation should be recorded to a relational database

I'm thinking PostgreSQL? DB Management will be with CL

I tried this before with much less forethought and ended up with a hunk of lisp spaghetti laying around, however I think this can really go far if we focus on providing a singular interface and robust installation procedures


so the logical first step for runtime functionality is hooking X keyboard input: at any point while mycelium is running you should be able to run commands (M-x lookups, emacs keybinds) without having to be focused on emacs

I'll start by hooking CLX to emacs, however I think people who are interested in contributing for now can just submit command line functions they like to hook in lists that we can compile and analyze to categorize

>>12467
Here's the issue with all systems like this: UNIX is so poorly designed that you can't abstract over it like this.

Anyways, there's already a way to just use Emacs as the init and only user interface:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html

Of course, Emacs Lisp is actually pretty gross compared to Common Lisp, but you have to understand that is entirely because Emacs is nice to use on UNIX, because Emacs has had to adapt to UNIX.

All of those niceties that make Emacs nice to use are what you get when you take a Lisp and specially craft it for a UNIX, because UNIX is broken beyond any hope for repair.

So you want dmd, guix, scsh and emacs-guile but rewritten in Common Lisp?

The more I think about this, the more it seems to me we're trying to make a lisp-systemd. No, I'm not trying to insult anyone. I think that's the closest to a full lisp machine we can emulate on a linux kernel. A daemon which runs as PID 1 as root and sts up services, and spawns a client which is essentially a lispy shell.Now the clients are full lisp runtimes and the server manages users and resource distribution on userspace acting as a middleman between kernel and user

>>12480
This is actually sounds like a pretty good system design, especially when implementation matures.