chyrsa(sh): a different approach to the shell. about chrysalisp HOT 23 CLOSED

I'll do that line buffering editing abstraction over the weekend !

I just pushed the image apps resize fix. BTW

from chrysalisp.

Just pushed a change to the pipe.inc file with a new (pipe-run) function. This will let you run a command line and optionally provided an output function, defaults to call (print).

You could for instance now run every line in a file as commands by doing something like.

(each-line (lambda (cmdline)
(pipe-run cmdline)) (file-stream "filename"))

Chris

from chrysalisp.

Just push a lot of GUI terminal work, inspired by your changes. left/right keys, inverse video chars in the VDU etc. Plus resizable GUI screen.

You will need to do a 'make boot' in the TUI or GUI to build the GUI resizing changes in.

from chrysalisp.

Sounds like a plan :)

The current terminal app is very very crude ! It was there to get something going that would allow access to the Lisp REPL and, more importantly at the time, the assembler and make system.

Now its got to the point where the terminal is all in Lisp, and now we have access to the mail and message in/out streams, example the pipe.inc file, the Terminal and cmd/ apps are up for review.

But, this was never intended to be a POSIX/Unix shell, it's there to give easy access to tools and hide the message passing behind something that looks like stdin/stdout/stderr to cmd/ apps.

One of the first things I think should happen is abstracting out the terminal line buffering/history stuff into a separate .inc file and use that in both the GUI and TUI terminal apps. I was going to have a look at that over the weekend as you had prompted me to take more interest in the terminal side of things.

But I'll hold off on that and see what you are thinking.

And how about we name it 'chrysh' ;)

Regards

Chris

from chrysalisp.

chrysh sounds good too!

I definitely think the buffering of commands being abstracted out is the best option for the shell. In my experience it seems like necessary functionality for any sh.

Not sure how much work that means on your end, though.

from chrysalisp.

Cool.

The GUI terminal should really only be a windowed. Sorry if my pull requests are all nuts. I'm still getting the hang of atoms interface, the terminal inteface, and pushing upstream.

from chrysalisp.

I'm struggling with this. I'm just learning lisp. How do I just make the terminal start the lisp cmd when it starts? I feel really stupid. The input out, cmd, and vdu stuff is confusing me. :/

Once I can do that I think I can make some headway.

from chrysalisp.

Your probably not stupid ! Just got to take a while to understand what is going on. So let go over what the terminal app is doing and how that relates to the command style applications in the cmd/ folder.

All .lisp files when started as a process by the kernel have a Lisp class created for them and the REPL method of that instance called with that file as the source. Look at the class/lisp/run.vp file to see exactly what happens. So you can think of this as the Lisp is already running but that's different to what I think you mean by running the Lisp...

The GUI terminal app, apps/terminal/app.lisp, is a Lisp app that is providing a 2D character array (via a vdu class object) and collecting keyboard events into a line input buffer. It exists in 2 states, a pipeline is active or not. If no active pipe it just collects the keystrokes into a line buffer (a string as it happens, with up/down keys switching through a line history buffer) and waits for a LF key before trying to start a pipeline of processes from that string. If a pipe is active it collects the keys and on an LF sends them into the active pipes input (with the call to pipe-write).

All the time a pipe is active it is monitoring the stdout and multiple stderr outputs from that pipe to read and display whatever comes through. The stdout's of each pipe element are wired up to pass to the next element in the pipe, the final element back to the terminal. All the pipe element stderr's are wired to go back to the terminal. The pipe.inc file contains the code that creates/destroys and reads/writes to the active pipe.

Commands that you 'run' via the terminal are not Lisp programmes that you are running in the terminals Lisp interpreter instance ! They are opened up 'out there' on the network somewhere and are running their own Lisp interpreter. They are reading there own stdin message queue and writing to their own stdout/sdterr. Each pipe element has its own Lisp instance and they are unaware of the terminal app or any other pipe element.

The vdu class is simply a GUI component that stores a 2D array of characters, because something has to do that or we will never be able to see anything. The Terminal app window doesn't display characters, it has no ability to display characters, it just provides furniture like a title bar and close buttons and a border for whatever is inside it. It is the vdu object that hold the characters and know how to draw them with a specific font and colour. It also provide some crude methods for scrolling and line clearing etc (and should eventually be a more standard VT52/VT100 standard command set).

When you type 'lisp' in the terminal and have access to a Lisp REPL, what's happening is that you have a single element pipe active, there is an instance of the cmd/lisp.lisp process out on the network somewhere. What you see as 'the lisp running' isn't the terminals lisp instance at all, that one is still just reading the line buffer and feeding it to the active pipe. Any Lisp statement you execute at this REPL runs (or evaluated to be presise) 'out there' wherever that process was placed.

To see this more clearly, bring up the Network monitor app and watch the green process count bars while you try various terminal command lines. See how the process in the pipe live out on the network ?

Try this:

cat README.md | dump | dump | dump | shuffle | sort

Maybe add some extra dump stages if things go by too fast to see on the monitor app. See how the pipe elements run off CPU 0 ? That because they are started with the call to open-pipe in the pipe.inc file. The terminal and GUI is running on virtual CPU 0, that top bar.

Hope this explanation helps.

Regards

Chris

from chrysalisp.

I've also just noticed a bug I must have introduced when I moved the pipe creation over to Lisp last week, if the pipe has an error the bail out code freezes, I'll work on fixing this now !

Chris

from chrysalisp.

Tracked that issue down to the addition of the object stats stuff, so if you want to avoid any freezing issues while I fix this, just edit the 'debug_mode' value in class/lisp/boot.inc to 1. Then reboot and do a 'make all boot', then reboot again and you will be running the none stats gathering version. That will then not show this freeze issue.

from chrysalisp.

Pushed a fix for that bug. debug_mode 2 now works fine again. After a pull you can 'make boot all' and get back to a fully working system.

from chrysalisp.

I understand a lot more now. I'm also reading the docs now. I jumped in without RTFM.

I'm going to spend time reviewing documentation. This is a lot more low level than I'm used to. My main idea was to add all of the cmds into the lisp interpreter. At this point, the programming of the terminal is beyond me. (cat "this") works.

I will keep learning and contribute in the ways I can.

My favorite part of your explanation was "You're probably not stupid."

from chrysalisp.

No problem :) take it one step at a time. Try have a go at some cmd/ extra commands to get into Lisp a bit more.

from chrysalisp.

How I can get terminal's app.lisp and the tui.lisp to issue a single cmd when it they first open?

from chrysalisp.

Remember a command app would not be even running on the same CPU as the terminal app ! So the question really needs to be what are you intending this single command to do ? Are you wanting it to change something about the terminals Lisp instance's environment ? Are you just wanting some things to run when you start up the terminal but they are just ordinary command apps ?

If you just want to run some Lisp code on starting the terminal you can just call a Lisp function or (import 'filename) which is the same thing (evaluate this entire file). And that would run in the terminals Lisp instance.

As soon as you run a 'pipe' command you are executing a separate Lisp app that does not have any way to change the terminals environment or any other for that matter.

There could be a standard list of 'pipe command lines' that get executed prior to waiting on stdin for user input ? Maybe a list of command strings and the terminal will pop from that list until it's empty ? And only then start to wait on stdin ? Does that sound like something you're after ? Could even pull these lines form a file at startup ? Maybe like an 'autorun.inc' or such ?

If so I could have a go at adding that for you, as a way to get you going, but it would be tomorrow night UK time.

from chrysalisp.

You've got it.

Just a list of commands that users have access to, like the launcher does with apps, and a list of commands that auto-start when the terrminal opens. Similar to the launcher, but for cmds instead of apps.

A default profile could be configured and created, and the administrator could whitelist and/or blacklist certain cmds (the same for apps). That would be a big step towards having a secure multi-user system.

from chrysalisp.

This is looking really good. I'll make some commits today to better show you what I'm thinking.

from chrysalisp.

I'm going to try to get the pupa files in place before I go much further with terminal, but I'm still very much vested in working on making the terminal special.

The line buffering work you did is really solid. I'm looking forward to continuing to work on the project.

from chrysalisp.

I was wanting to get the line buffering and history working with the TUI, but I need access to my Windows laptop to do that, so can't be till Monday night. I need to switch both the MacOS/Linux and Windows terminals to work in none line buffered mode (like the GUI Terminal) and then they can share the same line buffering and line history code. Then eventually I want to expand that common line editing code to deal with left/right keys and tab completion etc.

from chrysalisp.

Yeah, those are definitely things that would help. Key chords would also be great. I might hack around with that. You have key_up and key_down functions, correct?

from chrysalisp.

Fantastic!

from chrysalisp.

I'm working towards an alternative command line that uses repl to act as a semi-scripted subset of lisp. My time table is probably a month for something worth demonstrating, but I think there is potential in this approach. A unique shell using Lisp syntax and a limited subset of functions makes more sense to me than a POSIX style shell, given the environment.

The shell opens with a quick note on accessing the help system, a note that can be changed by the user when they're tired of seeing it, and the paren prompt (_). This prompt immediately sets itself apart. It's identifiable and different. The cursor within parens leads users quickly down the road of learning, using, and creating lisp scripts and personal functions stored in the pupa file. Theres no need to be different for difference sake, but immersion is a proper learning tool.

A robust semi-automated help system is also part of the design and should be easy to maintain as new functions are added. Help text documentation tags in the function library put all help for scripting functions in a single place. Getting help should be easy using a single function that takes an optional argument of function:(help) or (help _function_).
`

from chrysalisp.

As with the filesystem this is something I need to bring to the table when I'm able to implement it. I think this issue can be safely closed, but the discussion has helped me a great deal.

from chrysalisp.