ChrysaLisp – A 64-bit Lisp OS with GUI(github.com)
github.com
ChrysaLisp – A 64-bit Lisp OS with GUI
https://github.com/vygr/ChrysaLisp
124 comments
I started on this path, got through the boot-up, interrupts etc. and to a simple shell. Once that was done, instead of targeting something simpler like malloc(), I wanted to get a VGA driver working. VGA drivers are notoriously hard and I really wanted my OS to have a UI so after a couple of weeks of studying and getting nowhere, I gave up on the whole project.
I think the one major thing that caused me to give up on the project was whenever it became time to refactor or to think about the big picture (for ex. where do the drivers live? what about a libc implementation - can you just get glibc to work on your OS? Or do you have to rewrite the whole of libc?), I found that I was just copying whatever linux had already done. The feeling that I wasn't really doing any original work and am making a shittier version of an existing system demotivated me for some reason even though this was just supposed to be a learning exercise. So some advice for anyone attempting this - be prepared to go out of your way to rewrite significant amounts of helper code that has nothing to do with actually building your OS.
I think the one major thing that caused me to give up on the project was whenever it became time to refactor or to think about the big picture (for ex. where do the drivers live? what about a libc implementation - can you just get glibc to work on your OS? Or do you have to rewrite the whole of libc?), I found that I was just copying whatever linux had already done. The feeling that I wasn't really doing any original work and am making a shittier version of an existing system demotivated me for some reason even though this was just supposed to be a learning exercise. So some advice for anyone attempting this - be prepared to go out of your way to rewrite significant amounts of helper code that has nothing to do with actually building your OS.
For a libc on a weird OS I would recommend newlib (https://sourceware.org/newlib/), which is a libc for embedded systems and so has a well-defined way to implement the basic stuff that it needs to run.
Very interting, my dream too.
I made similar OS. ACPU OS run on mobiles/desktop/browsers/bare-metal, with multiuser p2p team development livecoding, time travel debugger, multiple libraries, startup in 30 seconds on iPad in development mode with synchronization, compile sources & symbol navigations, etc. Powered by ACPUL programming language.
Here is OS API:
https://github.com/d08ble/acpul-demo/tree/master/sys
Simple multiplayer DOTA game prototype:
https://github.com/d08ble/acpul-demo/tree/master/dota
Some demos:
https://www.youtube.com/watch?v=pk58kWIAqMM
https://www.youtube.com/watch?v=UsQklNVUDwM
https://www.youtube.com/watch?v=ubNfWarTawI
Follow us: https://twitter.com/ACPUStudio
I made similar OS. ACPU OS run on mobiles/desktop/browsers/bare-metal, with multiuser p2p team development livecoding, time travel debugger, multiple libraries, startup in 30 seconds on iPad in development mode with synchronization, compile sources & symbol navigations, etc. Powered by ACPUL programming language.
Here is OS API:
https://github.com/d08ble/acpul-demo/tree/master/sys
Simple multiplayer DOTA game prototype:
https://github.com/d08ble/acpul-demo/tree/master/dota
Some demos:
https://www.youtube.com/watch?v=pk58kWIAqMM
https://www.youtube.com/watch?v=UsQklNVUDwM
https://www.youtube.com/watch?v=ubNfWarTawI
Follow us: https://twitter.com/ACPUStudio
> Maybe this will let me live vicariously through someone who has actually built the project I always dream of creating in my free time.
You too!?
You too!?
Heh, maybe you'll get a kick out of http://nand2tetris.org/ (if you haven't come across it already). I finally finished part 1 of the course (implementing the Hack machine) and it was one of the best and most challenging learning experiences I've ever had. My plan is to do part 2 (VM, high level language, OS) with Lisp instead of the language they implement. That's been the plan for the last 6 months, anyway...
Cool, I'll check it out. I have a few lisp projects in the works. I started making a simple lisp operating system for 16-bit intel by forking MikeOS, which is an awesome project (didn't get that far). Then I developed a Forth VM / Compiler to build a lisp on top of (since compiling to my own forth assembly will be easier than targeting a real assembly). I got the forth compiler and vm, no lisp yet =T
It’s probably best to not do side projects. The bang for your buck is pretty low.
A bit of a stretch to call this a "Lisp OS" yet. If you look at the project's history, you can see that it was written in nasm, and at some point the author "slapped some parens around" and took steps to make it into an actual Lisp dialect, but it's not there yet, as it lacks many of the features you'd expect from a Lisp. Also see README_LISP.md.
Does this roughly offer the same benefits that the old lisp machines provided?
I've never used one, but have heard people rave about how productive they were on them.
I've never used one, but have heard people rave about how productive they were on them.
>Does this roughly offer the same benefits that the old lisp machines provided?
This project is cool, but, in short, no.
Please take a look at this paper, which answers the questions of which benefits could be obtained with a Lisp OS. This goes regardless of if such OS has or does not has a nice IDE.
http://metamodular.com/lispos.pdf
This is a really good paper, recommended lecture.
This project is cool, but, in short, no.
Please take a look at this paper, which answers the questions of which benefits could be obtained with a Lisp OS. This goes regardless of if such OS has or does not has a nice IDE.
http://metamodular.com/lispos.pdf
This is a really good paper, recommended lecture.
No.
I expect this will be a fairly controversial comment, so I want to preface this by saying that I'm a big Lisp fan (just look at my handle). Lisp is my favorite programming language. I've been using it for nearly forty years. My first Lisp was P-Lisp on an Apple II in 1980. And I worked on Symbolics Lisp machines in the 1990s. They were very cool, but there's a reason they failed: general-purpose computing is infrastructure, and the economics of infrastructure are such that having a single standard is the most economical solution, even if that standard is sub-optimal. For better or worse, the standard for general-purpose computing is the C machine.
Because it's general-purpose you certainly can run Lisp on a C machine (just as you could run C on a Lisp machine). You can even do this at the system level. But Lisp will always be at a disadvantage because the hardware is optimized for C. Because of this, C will always win at the system level because at that level performance matters.
But that in and of itself is not the determining factor. The determining factor is the infrastructure that has grown up around the C machine in the last few decades. There is an enormous amount of work that has gone into building compilers, network stacks, data interchange formats, libraries, etc. etc. and they are all optimized for C. For Lisp to be competitive at the system level, nearly all of this infrastructure would have to be re-created, and that is not going to happen. Even with the enormous productivity advantages that Lisp has over C (and they really are enormous) this is not enough to overcome the economic advantages that C has by virtue of being the entrenched standard.
The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level. I use Clozure Common Lisp. It has an Objective-C bridge, so I can call ObjC functions as if they were Lisp functions. There is no reason for me to know or care that these functions are actually written in C (except insofar as I have to be a little bit careful about memory management when I call C functions from Lisp) and so using Lisp in this way still gives me a huge lever that is economically viable even in today's world. I have web servers in production running in CCL on Linux, and it's a huge win. I can spin up a new web app on AWS in just a few minutes from a standing start. It's a Lisp machine, but at the application level, not the system level. My kernel (Linux) and web front end (nginx) are written in C, but that doesn't impact me at all because they are written by someone else. I just treat them as black boxes.
I don't want to denigrate ChrysaLisp in any way. It's tremendously cool. But cool is not enough to win in the real world.
[UPDATE] ChrysaLisp is actually doing the Right Thing with respect to its GUI by using a C-library (SDL). But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand. There are already many Lisps that can run on bare metal (ECL was specifically designed for that). None of them have succeeding in displacing C, and I believe none ever will because the economic hurdles are insurmountable.
I expect this will be a fairly controversial comment, so I want to preface this by saying that I'm a big Lisp fan (just look at my handle). Lisp is my favorite programming language. I've been using it for nearly forty years. My first Lisp was P-Lisp on an Apple II in 1980. And I worked on Symbolics Lisp machines in the 1990s. They were very cool, but there's a reason they failed: general-purpose computing is infrastructure, and the economics of infrastructure are such that having a single standard is the most economical solution, even if that standard is sub-optimal. For better or worse, the standard for general-purpose computing is the C machine.
Because it's general-purpose you certainly can run Lisp on a C machine (just as you could run C on a Lisp machine). You can even do this at the system level. But Lisp will always be at a disadvantage because the hardware is optimized for C. Because of this, C will always win at the system level because at that level performance matters.
But that in and of itself is not the determining factor. The determining factor is the infrastructure that has grown up around the C machine in the last few decades. There is an enormous amount of work that has gone into building compilers, network stacks, data interchange formats, libraries, etc. etc. and they are all optimized for C. For Lisp to be competitive at the system level, nearly all of this infrastructure would have to be re-created, and that is not going to happen. Even with the enormous productivity advantages that Lisp has over C (and they really are enormous) this is not enough to overcome the economic advantages that C has by virtue of being the entrenched standard.
The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level. I use Clozure Common Lisp. It has an Objective-C bridge, so I can call ObjC functions as if they were Lisp functions. There is no reason for me to know or care that these functions are actually written in C (except insofar as I have to be a little bit careful about memory management when I call C functions from Lisp) and so using Lisp in this way still gives me a huge lever that is economically viable even in today's world. I have web servers in production running in CCL on Linux, and it's a huge win. I can spin up a new web app on AWS in just a few minutes from a standing start. It's a Lisp machine, but at the application level, not the system level. My kernel (Linux) and web front end (nginx) are written in C, but that doesn't impact me at all because they are written by someone else. I just treat them as black boxes.
I don't want to denigrate ChrysaLisp in any way. It's tremendously cool. But cool is not enough to win in the real world.
[UPDATE] ChrysaLisp is actually doing the Right Thing with respect to its GUI by using a C-library (SDL). But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand. There are already many Lisps that can run on bare metal (ECL was specifically designed for that). None of them have succeeding in displacing C, and I believe none ever will because the economic hurdles are insurmountable.
Yes, but...
I basically agree with everything you wrote, but for two subsidiary points.
1 - it's a phenomenal development platform. I have on multiple occasions built large systems later deployed, for the reasons you discussed, via C ports. It didn't nullify the work done in Lisp: we learned a lot, and quickly; were able to do quick experiments, etc. But ultimately we needed to join the wider world.
2 - there is / has been a sea change in the software deployment model; it includes web browsers, even more rapid and more flexible development etc. Clojure is a good example and consequence of this change. It's quite possible that the circumstances that led to Lisps decline (though was it really ever "mainstream?") may swing the tide the other way. E.g. "Rapid development and realtime deployment of lisp-based microservices" to agglomerate some popular buzzwords.
FWIW: I was a developer from MACLISP to MIT CADRS, various Symbolics machines (at one point I had two 36xx machines on my desk with color monitors attached) and various D machines. Right now I'm doing my development in C++ though.
I basically agree with everything you wrote, but for two subsidiary points.
1 - it's a phenomenal development platform. I have on multiple occasions built large systems later deployed, for the reasons you discussed, via C ports. It didn't nullify the work done in Lisp: we learned a lot, and quickly; were able to do quick experiments, etc. But ultimately we needed to join the wider world.
2 - there is / has been a sea change in the software deployment model; it includes web browsers, even more rapid and more flexible development etc. Clojure is a good example and consequence of this change. It's quite possible that the circumstances that led to Lisps decline (though was it really ever "mainstream?") may swing the tide the other way. E.g. "Rapid development and realtime deployment of lisp-based microservices" to agglomerate some popular buzzwords.
FWIW: I was a developer from MACLISP to MIT CADRS, various Symbolics machines (at one point I had two 36xx machines on my desk with color monitors attached) and various D machines. Right now I'm doing my development in C++ though.
Googling "d machine" gave (semi-)predictably nonsense results. And Wikipedia does not have an article with this exact name.
What was this?
What was this?
Machines from Xerox running Interlisp-D. The computers had acronyms starting with D. Xerox later also integrated Common Lisp into Interlisp-D.
The hardware was not powerful - for example they had very little RAM.
But an emulator was developed for SPARC/UNIX and X86/Linux. Called Medley.
The hardware was not powerful - for example they had very little RAM.
But an emulator was developed for SPARC/UNIX and X86/Linux. Called Medley.
Alto descendants from PARC, ranging in size (not year built) from the Dandelion (AKA Xerox Star) Dolphin and Dorado (an ECL logic screamer). You could boot them into standalone environments like Smalltalk, Interlisp-D, and Cedar/Mesa). By “standalone” I mean you loaded specific microcode into the machine and then booted an environment in which everything: OS, GUI, file system etc was written in that environment.
When I worked at PARC I mostly used Interlisp, but I did use all those environments.
When I worked at PARC I mostly used Interlisp, but I did use all those environments.
Late-70s early 80s Xerox "D machines": Xerox Dorado, Dolphin, Dandeline, ...
> The way Lisp can still win in today's world is not by trying to replace C on the system level, but by "embracing and extending" C at the application level.
Interestingly, another current top post on HN is HPAT - A compiler-based framework for big data in Python (https://news.ycombinator.com/item?id=15466829). This replaces C level languages with something like Python for a specific domain. That could be somewhere lisp wins as well?
Interestingly, another current top post on HN is HPAT - A compiler-based framework for big data in Python (https://news.ycombinator.com/item?id=15466829). This replaces C level languages with something like Python for a specific domain. That could be somewhere lisp wins as well?
I'd be more optimistic. Tools are better today. Machines are faster. Re-inventing the wheel isn't nearly as costly or involved as it had been. Look at how much has already been re-done and re-tooled in JavaScript. The same process is being replayed in Rust, Go, and Clojure as we speak.
As for the C machines, Moore's law already has a foot in the grave. Ten years ago, we would have just assembly-optimized any inner-loop bottlenecks and assumed that in a few more months Intel would get us the rest of the way there. Now I'm seeing more and more being pushed off into GPUs and custom ASICs. With clock speeds topped-out, the mainframe approach of pushing more into the hardware grows increasingly attractive.
That, and so much is written in other garbage-collected languages today that LISP-friendly hardware could benefit Python/C#/Java/PHP programs as much as it would LISP ones.
As for the C machines, Moore's law already has a foot in the grave. Ten years ago, we would have just assembly-optimized any inner-loop bottlenecks and assumed that in a few more months Intel would get us the rest of the way there. Now I'm seeing more and more being pushed off into GPUs and custom ASICs. With clock speeds topped-out, the mainframe approach of pushing more into the hardware grows increasingly attractive.
That, and so much is written in other garbage-collected languages today that LISP-friendly hardware could benefit Python/C#/Java/PHP programs as much as it would LISP ones.
I have web servers in production running in CCL
WANT!!!
Please write an article about it and post a link to it here.
WANT!!!
Please write an article about it and post a link to it here.
I'll see what I can do, but in the meantime:
https://github.com/rongarret/ergolib
In particular:
https://github.com/rongarret/ergolib/tree/master/web
The heavy lifting is all done by Hunchentoot:
http://weitz.de/hunchentoot/
https://github.com/rongarret/ergolib
In particular:
https://github.com/rongarret/ergolib/tree/master/web
The heavy lifting is all done by Hunchentoot:
http://weitz.de/hunchentoot/
The part I’m also interested in is the cgi-bin config of the web server. Or did you manage to get Apache’s mod_lisp working? How?
Are you interested in a web server for Common Lisp? We have had these for years, for example Hunchentoot. This is a standalone web server, doesn't need to be connected to any other server. No need for Apache.
Take a look at the "lack" and "Clack" packages for Common Lisp by Eitaro Fukamachi; they provide a layer of abstraction so your program thinks it has a web server, but in production it can be run by various Lisp web servers (i.e. Hunchentoot) without changes to your code.
Take a look at the "lack" and "Clack" packages for Common Lisp by Eitaro Fukamachi; they provide a layer of abstraction so your program thinks it has a web server, but in production it can be run by various Lisp web servers (i.e. Hunchentoot) without changes to your code.
I’m interested in running Lisp web applications inside of Apache web server, for example with mod_lisp or through cgi-bin, although I’d prefer the former, simply because Apache has modules for many other functions as well. Unfortunately, what documentation there is on mod_lisp isn’t step by step to get from point A to point B.
I wasn’t aware of Hunchentoot.
I wasn’t aware of Hunchentoot.
"As Caveman bases on Clack/Lack, you can choose which server to run on -- Hunchentoot, mod_lisp or FastCGI"
https://github.com/fukamachi/caveman/blob/master/README.mark...
Take a look at Clack. (Caveman2 is a web framework for Common Lisp, by Eitaro ("8arrow") Fukamachi; another recent web framework is Lucerne, by Fernando Borretti ("eudoxia0"))
Caveman is built on top of Clack and I think Lucerne is, too.
Another good option is Ningle, by Eitaro, which is a really mínimal minimal set of functions and macros to create a web application. Runs on top of Clack as well.
https://github.com/fukamachi/caveman/blob/master/README.mark...
Take a look at Clack. (Caveman2 is a web framework for Common Lisp, by Eitaro ("8arrow") Fukamachi; another recent web framework is Lucerne, by Fernando Borretti ("eudoxia0"))
Caveman is built on top of Clack and I think Lucerne is, too.
Another good option is Ningle, by Eitaro, which is a really mínimal minimal set of functions and macros to create a web application. Runs on top of Clack as well.
Hunchentoot is a web server. It's a replacement for Apache.
I usually run nginx as a front-end because it's faster at serving static content and it provides some security benefits, but it's not necessary.
I usually run nginx as a front-end because it's faster at serving static content and it provides some security benefits, but it's not necessary.
> But cool is not enough to win in the real world
But is winning in the real world really important? OPs question was after all "Does this roughly offer the same benefits that the old lisp machines provided", and as LISP machines did not really win in the real world the first time around, I don't think that is really prerequisite for bringing the benefits of a LISP machine.
But is winning in the real world really important? OPs question was after all "Does this roughly offer the same benefits that the old lisp machines provided", and as LISP machines did not really win in the real world the first time around, I don't think that is really prerequisite for bringing the benefits of a LISP machine.
I was asking more about the productivity benefits, versus any performance boost a "made for lisp" ISA might offer...
Productivity measured against what quality metric? For getting code written fast, Lisp is pretty good. For writing an operating system on which you can run a web server that will be competitive with nginx on Linux in terms of requests-per-second, probably not so much.
I asked because many people that used them called out the machines as being very productive...above and beyond lisp. Another comment here suggests it might have been CLIM.
Ah. A lot of that was because the LispMs had really good IDEs at a time when IDEs were all but unheard of. This was possible because it's a lot easier to write an IDE for Lisp than for C. But all that can be re-created at the application level (obviously because IDEs are applications). There's no need for a system-level Lisp to get that win.
In fact, Clozure Common Lisp is a perfect example. It provides (IMHO) 80-90% of the productivity advantages of a LispM when you run it on a Mac (because the IDE is Mac-specific).
In fact, Clozure Common Lisp is a perfect example. It provides (IMHO) 80-90% of the productivity advantages of a LispM when you run it on a Mac (because the IDE is Mac-specific).
Maturity? Gets out of the way? Advanced documentation/learning material? Wealth of prior work solutions to common patterns? It's not so hard to guess what any developer's productivity is hinged on.
[deleted]
It's tremendously cool. But cool is not enough to win in the real world.
Cool is synergistic with other qualities. On top of that, everything is contextual. Does anyone know of any particularly cool ClojureScript electron apps?
Cool is synergistic with other qualities. On top of that, everything is contextual. Does anyone know of any particularly cool ClojureScript electron apps?
> Does anyone know of any particularly cool ClojureScript electron apps?
LightTable was cool.
LightTable was cool.
The reason why Lisp machines failed is because, with compiler and CPU architecture improvements, "C machines" started trouncing Lisp machines in terms of performance, even at running Lisp code. Symbolics's last product was Genera running on a "C machine" architecture. This doesn't obviate your statements about library support, but I don't believe the dream of "Lisp from bare metal on up" is worth abandoning entirely.
What would be the advantage? Why put in all that work just to reinvent the wheel?
I think one big advantage could be seemless integration of all applications. Genera on Lisp Machines [1] and McClim [2] illustrate how it works.
[1] https://news.ycombinator.com/item?id=1878220
[2] https://common-lisp.net/project/mcclim/excite.html
In classical OS (Linux, Windows, Mac) the developer is responsible for seemless integration (in KDE or MS Office for instance). It is easy to break design guidelines here which causes ugly interoperation, or even lack of interoperation.
[1] https://news.ycombinator.com/item?id=1878220
[2] https://common-lisp.net/project/mcclim/excite.html
In classical OS (Linux, Windows, Mac) the developer is responsible for seemless integration (in KDE or MS Office for instance). It is easy to break design guidelines here which causes ugly interoperation, or even lack of interoperation.
> But it's trying to re-invent the compiler wheel (and the language design wheel) so that it can run on bare metal and "grow up to be a real Lisp machine" some day, and I think that aspect of the project is a fool's errand.
I'm not so sure about the actual intentions behind the development beyond "experimenting".
I'm not so sure about the actual intentions behind the development beyond "experimenting".
And there's absolutely nothing wrong with that. But the question I was responding to was about the potential to use this as a starting point for re-creating the productivity advantages of the Lisp machine.
I think that a better idea was (is?) to create a LispM on cloud services, and just use it through the browser, like this:
https://en.wikipedia.org/wiki/BioBIKE
How far do you think is the next local maximum from the current C one? I'm asking in terms of power of displacement of the status quo. Do you think it involves Lisp in one way or another?
The Lisp and C worlds are already kind of converging in languages like Python, Swift, Go and others. Unfortunately, as far as predicting what will happen, I can only quote the late, great Carl Sagan and say that prophecy is a lost art.
I also ran P-Lisp on my AppleII. Fun times.
A few years later I got a Xerox 1108 Lisp Machine at work, a cheaper alternative to your Symbolics, but very nice.
A few years later I got a Xerox 1108 Lisp Machine at work, a cheaper alternative to your Symbolics, but very nice.
Speaking of P-Lisp: https://goo.gl/mUezFv
(I particularly like: "I strongly encourage you not to actually use this to learn Lisp!" :-)
(I particularly like: "I strongly encourage you not to actually use this to learn Lisp!" :-)
Doesn't look like there's anything like CLIM support, unfortunately.
One can debate whether or not this is a "true" operating system, but I'd like to coin a (new?) term: "virtual operating system"...not to be confused with emulation or virtual machines, but rather an OS that runs on top of a host OS. One obvious use for such a thing is reskinning an underlying operating system in a non-trivial way, i.e. completely changing the UI paradigms. Another use is allowing programmatic access to virtually everything.
I would just call this a shell or a runtime environment. It's not an OS and I don't think we should co-opt that term. We don't call nurses virtual surgeons or construction workers virtual architects.
I agree there is probably a better term, but the differentiation would be that you are abstracted one level up from a native shell, and thus could probably more easily write a cross-platform "virtual OS" that could run on top of Windows, OSX, etc - and install it with the ease of running an application, as opposed to fiddling with more sensitive things.
while impressive, this is a userspace program, quite different from an OS, even acounting for their virtual cpu.
nevertheless nice experiment
nevertheless nice experiment
Robot operating system (ROS) is a bit like this. It sits on top of Linux or OS X but offers a message passing framework and some naming and type conventions for passing around data common in robotics, like transform information, laser scans, odometry, etc.
I think is called "Emacs" ?
Jokes aside, you could probably call this a "desktop environment" and communicate most of the meaning. What remains is either a "virtual machine"[1], "runtime system", or something along those lines.
[1] https://en.wikipedia.org/wiki/Virtual_machine
Jokes aside, you could probably call this a "desktop environment" and communicate most of the meaning. What remains is either a "virtual machine"[1], "runtime system", or something along those lines.
[1] https://en.wikipedia.org/wiki/Virtual_machine
So a userspace application with ring0 access, or are you describing paravirtualization or containers?
It could technically fit any of those cases depending on the implementation, but the simplest path is probably building an application that disguises itself as an operating system. It could even be sandboxed to some degree and still probably suit most needs.
Quick start to get the GUI going (not so obvious from the README):
$ clone https://github.com/vygr/ChrysaLisp.git ChrysaLisp
$ cd ChrysaLisp
$ sudo apt-get install libsdl2-ttf-dev
$ make -j
$ ./run.sh
To quit:
$ ./stop.sh
$ clone https://github.com/vygr/ChrysaLisp.git ChrysaLisp
$ cd ChrysaLisp
$ sudo apt-get install libsdl2-ttf-dev
$ make -j
$ ./run.sh
To quit:
$ ./stop.sh
For a recent macOS version, do:
0) Make sure you have a recent Xcode installed
1) Install the libsdl2 and libsdl2_ttf frameworks under /Library/Frameworks
3) cd ChrysaLisp
4) make (takes about 2s!!)
5) ./run.sh (shows full working gui. Amazing!)
0) Make sure you have a recent Xcode installed
1) Install the libsdl2 and libsdl2_ttf frameworks under /Library/Frameworks
libsdl2: https://www.libsdl.org/release/SDL2-2.0.6.dmg
sdl2+ttf: https://www.libsdl.org/projects/SDL_ttf/release/SDL2_ttf-2.0.14.dmg
3) cd ChrysaLisp
4) make (takes about 2s!!)
5) ./run.sh (shows full working gui. Amazing!)
Getting SDL2 to be recognized under MacOS is no joy
correct. I figured out where the frameworks wanted to go -- and it even seems to match the path for -I, but that doesn't seem to be enough.
--
Yes, I have both frameworks installed. I even did the brew commands just for S&G ... same result after make command.
--
Yes, I have both frameworks installed. I even did the brew commands just for S&G ... same result after make command.
This is what I have under "/Library/Frameworks":
antimass@gem:~$ ls /Library/Frameworks/SDL*
drwxr-xr-x@ 22 Sep 14:54 SDL2.framework
drwxr-xr-x@ 1 Feb 2016 SDL2_ttf.framework
antimass@gem:~$
brew will install SDL2 in a "unix" fashion, which should work if the makefile is written this way. The Framework version is the "Mac" way that is recognized by Xcode. The makefile for this project was created using the framework version.
[deleted]
Try; xcode-select install
I ended up changing the "cc" line for darwin to this:
cc -o $@ [email protected] -lSDL2 -lSDL2_ttf
now it compiles (and runs) just fine (for me). YMMV
[deleted]
and for OSX?
see parent reply
make
cc -o obj/Darwin/x86_64/main obj/Darwin/x86_64/main.o -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf
ld: framework not found SDL2
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [obj/Darwin/x86_64/main] Error 1
Yes, I have both frameworks installed. I even did the brew commands just for S&G ... same result after make command.
Do you have "SDL2.framework" and "SDL2_ttf.framework" installed under "/Library/Frameworks"?
Yes
I don't know then. This is what I get on a fresh compile - note that it even specifies the framework paths in the command line options:
antimass@gem:~/github/ChrysaLisp$ make
echo x86_64 > arch
echo Darwin > platform
unzip -nq snapshot.zip
cc -c -nostdlib -fno-exceptions \
-I/Library/Frameworks/SDL2.framework/Headers/ \
-I/Library/Frameworks/SDL2_ttf.framework/Headers/ \
-o obj/Darwin/x86_64/main.o main.c
cc -o obj/Darwin/x86_64/main obj/Darwin/x86_64/main.o -Wl,-framework,SDL2 -Wl,-framework,SDL2_ttf
antimass@gem:~/github/ChrysaLisp$I'm looking for a bare metal boot OS that has internet capabilities -- lisp or forth based (ONLY). Any pointers would be greatly appreciated.
Firmworks has a open source implementation of OpenFirmware which is part of the OpenBIOS project, can be used with Coreboot, and implements TCP/IP with various protocols including HTTP, all in Forth.
http://www.firmworks.com/ofwfeatures.htm
http://GitHub.com/openbios/openfirmware
http://www.firmworks.com/ofwfeatures.htm
http://GitHub.com/openbios/openfirmware
Thank you.
A Common Lisp one: https://github.com/froggey/Mezzano
Interesting. Looks like there aren't many drivers, though. I only see stuff about running it through QEMU or Virtualbox.
Maybe somebody can try running it from OpenFirmware (see my my sibling post to yours), which has been ported to lots of platforms, and has lots of code one could borrow from in the way of drivers. Of course at the end of the day I guess the point of QEMU / Xen is to use Linux as a device driver.
Maybe somebody can try running it from OpenFirmware (see my my sibling post to yours), which has been ported to lots of platforms, and has lots of code one could borrow from in the way of drivers. Of course at the end of the day I guess the point of QEMU / Xen is to use Linux as a device driver.
Thanks for the link
Not exactly a Lisp OS - asm and C beneath. Compare to https://github.com/froggey/Mezzano
So this looks like basically the followup project to the TAOS os which was ways ahead of its time. https://news.ycombinator.com/item?id=9806607
I wonder how difficult it would be to move an existing Lisp to bare metal, like SBCL.
What this reminded me of most is the Connection Machines, which allowed you to configure the interprocessor connection topology. It had specialised C, FORTRAN and Lisp languages. They were also the best looking computers I ever saw!
Very cool, interested in Lisp but I would like to know if any HN'ers would provide me some insight into why Lisp is so popular?
Does anyone use it in production? Is it comparable to JS?
Does anyone use it in production? Is it comparable to JS?
Lisp is popular? Where?
It was almost mainstream in the 1980s when there were four Lisp Machine companies (Xerox, Symbolics, Texas Instruments, LMI) and symbolic AI, particularly expert systems, were used. Not so much now.
I still use it. If you know it you can be much more expressive and productive in it than in other mainstream languages, and when there's something you need that's missing from Lisp, you can extend Lisp to include it.
There are reasons it's fallen from favour, some of which lisper has given here. It's a mistake to languages necessarily succeed or fail on their merits.
It was almost mainstream in the 1980s when there were four Lisp Machine companies (Xerox, Symbolics, Texas Instruments, LMI) and symbolic AI, particularly expert systems, were used. Not so much now.
I still use it. If you know it you can be much more expressive and productive in it than in other mainstream languages, and when there's something you need that's missing from Lisp, you can extend Lisp to include it.
There are reasons it's fallen from favour, some of which lisper has given here. It's a mistake to languages necessarily succeed or fail on their merits.
>I would like to know if any HN'ers would provide me some insight into why Lisp is so popular?
In the late early 80s it was rather popular but it required expensive specialized hardware and software. Or you could execute it on more common hardware, but memory requirements were pretty high, which adds to the expense.
It's not like in 2017 where you can have many excellent Lisp implementations for free and they run blazingly fast on your machine, without needing more memory than what you have already.
It also has something to do with the triumph of UNIX over the Lisp machines
In the late early 80s it was rather popular but it required expensive specialized hardware and software. Or you could execute it on more common hardware, but memory requirements were pretty high, which adds to the expense.
It's not like in 2017 where you can have many excellent Lisp implementations for free and they run blazingly fast on your machine, without needing more memory than what you have already.
It also has something to do with the triumph of UNIX over the Lisp machines
Here is proof that Rust is unnecessary. Lisp comes from the past to save the future from itself.
We can start a LISP evangelism strikeforce and bomb the Rust threads the way the Rust guys bomb the C ones.
You will be heavily downvoted by the Rust zealots, without any argumentation, even if your arguments are in their official docs. I try from time to time because their discrepancy of marketing talk to delivered features is even worse than with Perl.
Comparing to this lisp os its a bit unfair though. This is an async distributed actor model os with various practical shortcuts. Refcounted with manually breaking up cycles. The lisp is very rough, but extremely fast. No linked lists (i.e. cons cells), just vectors. (Very good idea btw, same as in potion). A better macro assembler with message passing OO (smalltalk, Erlang but better than beam). I still want to see the other TAOS features though: selfrouting network, dynamic binding
Comparing to this lisp os its a bit unfair though. This is an async distributed actor model os with various practical shortcuts. Refcounted with manually breaking up cycles. The lisp is very rough, but extremely fast. No linked lists (i.e. cons cells), just vectors. (Very good idea btw, same as in potion). A better macro assembler with message passing OO (smalltalk, Erlang but better than beam). I still want to see the other TAOS features though: selfrouting network, dynamic binding
Even so, somebody needs to do it. What's the use of HN points if you never spend them?
PS> musl libc is beautiful.
PS> musl libc is beautiful.
They don’t just crash the C parties, anything or anyone that’s not on or who is not on Rust is fair game as far as they’re concerned. If you aren’t singing along with the Rust evangelism strike force party line and voice any kind of dissent expect severe repercussions justified by “lack of arguments”, even when the arguments presented are their own damning statements or criticise concrete code and syntax.
Where do I sign?
JavaScript has been called "Lisp in C's clothing". What it lacks is macros basically but you can get a lot of practical work done in JavaScript and it is as mainstream as it gets. So how about a JavaScript OS/Machine/Hardware anybody?
>JavaScript has been called "Lisp in C's clothing". What it lacks is macros
No, it lacks a lot of things in comparison, and if it only lacks macros, then it's lacking a lot as well.
Considering, for this case, "Lisp"="Common Lisp", this is what Javascript lacks:
1. Strong typing. CL is very strongly typed. Javascript is very weakly typed. Typescript doesn't fix this 100% because the runtime is still javascript, and thus the running code is weakly typed.
2. Code should be a first class citizen; code can be processed/sliced/diced/handled as easily as data. That is, code is data so most of the functions that apply to data, also apply to code. This doesn't happen in Javascript. Thus in Lisp metaprogramming is very easy and can be applied in many ways, greatly enhancing the power of the language, making it a "programmable programming language."
---------------
I could stop here, because these two above are strong, significant differences enough to tip the balance towards CL. But there's more:
---------------
3. A really good object system. CLOS might be the most advanced OOP system out there.
4. Really good numeric support. Javascript numbers are internally floats. In CL you have a full numeric tower. Complex numbers? check. Arbitrary-length numbers? check.
5. Image-based interactive development
6. A killer exception handling system: The condition-restart system.
7. Speed. CL can execute significantly faster than JS and can approach C/Fortran speeds if needed (by using tricks.)
8. Optional static type checks, and type declarations for increased performance if needed.
9. In javascript, you code so you define what happens at runtime. In CL, you can define when is your code going to be run: "at read time" versus "at compile time" versus "at runtime". So there are three "times" you can leverage!!
There are even more differences, to be honest.
No, it lacks a lot of things in comparison, and if it only lacks macros, then it's lacking a lot as well.
Considering, for this case, "Lisp"="Common Lisp", this is what Javascript lacks:
1. Strong typing. CL is very strongly typed. Javascript is very weakly typed. Typescript doesn't fix this 100% because the runtime is still javascript, and thus the running code is weakly typed.
2. Code should be a first class citizen; code can be processed/sliced/diced/handled as easily as data. That is, code is data so most of the functions that apply to data, also apply to code. This doesn't happen in Javascript. Thus in Lisp metaprogramming is very easy and can be applied in many ways, greatly enhancing the power of the language, making it a "programmable programming language."
---------------
I could stop here, because these two above are strong, significant differences enough to tip the balance towards CL. But there's more:
---------------
3. A really good object system. CLOS might be the most advanced OOP system out there.
4. Really good numeric support. Javascript numbers are internally floats. In CL you have a full numeric tower. Complex numbers? check. Arbitrary-length numbers? check.
5. Image-based interactive development
6. A killer exception handling system: The condition-restart system.
7. Speed. CL can execute significantly faster than JS and can approach C/Fortran speeds if needed (by using tricks.)
8. Optional static type checks, and type declarations for increased performance if needed.
9. In javascript, you code so you define what happens at runtime. In CL, you can define when is your code going to be run: "at read time" versus "at compile time" versus "at runtime". So there are three "times" you can leverage!!
There are even more differences, to be honest.
I can only agree that Common Lisp is in many ways a much better language than JavaScript. But JavaScript is much more popular and it has evolved into a lisp direction, EcmaScript 6 has "arrow functions" which are basically lambdas.
One question, you say "CL is very strongly typed". Then you also say "Optional type checks". Are you saying CL is optionally very strongly typed?
One question, you say "CL is very strongly typed". Then you also say "Optional type checks". Are you saying CL is optionally very strongly typed?
>One question, you say "CL is very strongly typed". Then you also say "Optional type checks". Are you saying CL is optionally very strongly typed?
Note that I wrote "optional static type checks".
CL is always strongly typed. A character array, for example, stays as a character array. It can't be used directly in place of a byte array, for example.
But what it allows, optionally, are type declarations. These, in implementations like SBCL, allow compile-time ("static") type checking.
The declarations also allow big enhancements in code speed, because this produces code that is specific to a data type (you can always see the compiled assembly code for a lisp function by using the "disassemble" function)
Note that I wrote "optional static type checks".
CL is always strongly typed. A character array, for example, stays as a character array. It can't be used directly in place of a byte array, for example.
But what it allows, optionally, are type declarations. These, in implementations like SBCL, allow compile-time ("static") type checking.
The declarations also allow big enhancements in code speed, because this produces code that is specific to a data type (you can always see the compiled assembly code for a lisp function by using the "disassemble" function)
I see
JavaScript is really nothing like Lisp. Macros/code is data and simple syntax are basically the defining features of a Lisp. Apart from these, JavaScript's type system is totally different (way weaker, based on objects but nothing like CLOS), JS isn't based on lists/pairs as the primary data structure, JS emphasizes imperative programming, etc. I don't know where this myth came about (probably because rumor that Brendan Eich initially intended to use Scheme instead of JS, although this never happened).
> rumor that Brendan Eich initially intended to use Scheme instead of JS, although this never happened
I wonder what'd have happened had he done so. Would it have grown to the size that JavaScript is at today, or would it have lost to something similar to JavaScript that some other browser would have implemented?
I wonder what'd have happened had he done so. Would it have grown to the size that JavaScript is at today, or would it have lost to something similar to JavaScript that some other browser would have implemented?
I believe they hired him under the impression of doing actual Scheme for the browser, but then they did the old corporate bait-and-switch on him:
"The immediate concern at Netscape was it must look like Java. People have done Algol-like syntaxes for Lisp but I didn't have time to take a Scheme core so I ended up doing it all directly and that meant I could make the same mistakes that others make."
http://bryanpendleton.blogspot.com/2009/11/coders-at-work-br...
"The immediate concern at Netscape was it must look like Java. People have done Algol-like syntaxes for Lisp but I didn't have time to take a Scheme core so I ended up doing it all directly and that meant I could make the same mistakes that others make."
http://bryanpendleton.blogspot.com/2009/11/coders-at-work-br...
I think it would've been replaced by a competing standard. Then again, the barrier of entry for Scheme is pretty low, there really wouldn't be much stopping people from using it. My prediction would be small-scale adoption of the Scheme standard, then a gradual phase out within a few years because a Netscape competitor (or maybe even the company itself) would have replaced with something more C-like because of complaints about parentheses.
> So how about a JavaScript OS/Machine/Hardware anybody?
Please, no.
Please, no.
This is quite cool.
For me, calling something an OS requires it to have it's own kernel ... maybe thats just me, but I think this is the 2nd project this month which has called itself an OS when in reality it is just a GUI.
It already has a kernel, except it uses the host OS's system calls instead of its own drivers. Once you have a runnable OS that runs as a separate Unix process in its own address space, it is actually possible to port it over to bare metal by providing all the modules that the OS would normally provide: memory management, graphics, device management and HAL, keyboard/mouse input.
See https://github.com/froggey/Mezzano for something that can run on bare metal.
See https://github.com/froggey/Mezzano for something that can run on bare metal.
> port it over to bare metal by providing all the modules that the OS would normally provide: memory management, graphics, device management and HAL, keyboard/mouse input.
In other words, it can become an OS if you merely add to it the exact things that define an OS.
In other words, it can become an OS if you merely add to it the exact things that define an OS.
That is how we programmed in the 80's on home computers and it is the norm still in 2017 on many micro-controlers.
The language runtime is the OS.
The language runtime is the OS.
I'm not interested in debating the definition of OS. If the textbooks are as wrong as you imply, I guess I'm wrong too.
So which textbooks do you want to start with?
I pick "PC INTERN: system programming", 1992.
https://www.amazon.de/PC-Intern-Programming-Encyclopedia-Dev...
I pick "PC INTERN: system programming", 1992.
https://www.amazon.de/PC-Intern-Programming-Encyclopedia-Dev...
A reference for MSDOS programming on a German amazon page... Am I missing the joke?
Tanenbaum and Silberschatz both have excellent textbooks covering the fundamentals of Operating Systems. Neither book focuses much on "language runtimes".
Tanenbaum and Silberschatz both have excellent textbooks covering the fundamentals of Operating Systems. Neither book focuses much on "language runtimes".
I live in Germany, do not always bother to check if the URL contains locale information.
Anyone that actually programmed MS-DOS, knows that we used to program directly against the hardware for actual work. MS-DOS was nothing more than what is usually known as monitor in OS literature.
Continuing the texts from people more relavant to the CS world than me,
"An operating system is a collection of things that don't fit into a language. There shouldn't be one." - Dan Ingalls on
https://archive.org/details/byte-magazine-1981-08 https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
"Building Parallel, Embedded, and Real-Time Applications with Ada" - John McCormick
https://www.amazon.co.uk/Building-Parallel-Embedded-Real-Tim...
"Project Oberon: The Design Of An Operating System And Compiler" - Niklaus Wirth
https://www.amazon.co.uk/Project-Oberon-Design-Operating-Com...
And not to let this just be theory, here are a few examples of commercial products using the language runtime to interface with the hardware.
http://www.astrobe.com/default.htm
https://www.mikroe.com/products/#compilers-software
https://www.ptc.com/en/products/developer-tools
Anyone that actually programmed MS-DOS, knows that we used to program directly against the hardware for actual work. MS-DOS was nothing more than what is usually known as monitor in OS literature.
Continuing the texts from people more relavant to the CS world than me,
"An operating system is a collection of things that don't fit into a language. There shouldn't be one." - Dan Ingalls on
https://archive.org/details/byte-magazine-1981-08 https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
"Building Parallel, Embedded, and Real-Time Applications with Ada" - John McCormick
https://www.amazon.co.uk/Building-Parallel-Embedded-Real-Tim...
"Project Oberon: The Design Of An Operating System And Compiler" - Niklaus Wirth
https://www.amazon.co.uk/Project-Oberon-Design-Operating-Com...
And not to let this just be theory, here are a few examples of commercial products using the language runtime to interface with the hardware.
http://www.astrobe.com/default.htm
https://www.mikroe.com/products/#compilers-software
https://www.ptc.com/en/products/developer-tools
I programmed MSDOS assembly and on 80s 8-bit machines back in the day too, so you can quit the "back in my day" routine. It was my day too.
Like I said, I'm not interested in debating the definition of OS. Best regards.
Like I said, I'm not interested in debating the definition of OS. Best regards.
Looks like it might evolve that way...
"Could move to bare metal eventually but it's useful for now to run hosted while experimenting"
And this: https://github.com/vygr/ChrysaLisp/blob/master/sys/kernel.vp
"Could move to bare metal eventually but it's useful for now to run hosted while experimenting"
And this: https://github.com/vygr/ChrysaLisp/blob/master/sys/kernel.vp
Operating systems manage IPC/resources and facilitate I/O. This one does the former but as yet depends on another underlying kernel for the latter. It's just a matter of writing the drivers/platform specific code and it can stand on its own. So not that much of a stretch to call it an OS, IMO.
Yep, for example MS-DOS programming using only BIOS calls.
I think it's worth noting the distinction between OS and kernel is a bit messy. I think that you could argue that this together with a kernel creates an OS (In the same way that Linux + GNU creates an OS). You don't have to write the kernel yourself to create an OS, just have a kernel. It is kinda false advertising though - it's like saying you wrote an "OS with CoreUtils" when you just wrote a set of CoreUtils. It's still really good, but not what people are thinking of when you that.
That said, I agree with you that it kinda stinks this doesn't have its own kernel - it really is just a GUI without it. It surprises me that so many people are blowing it off as no big deal. Writing the kernel is not a simple detail, we're talking about a lot of functionality that is missing that takes a lot of work to get right.
That said, I agree with you that it kinda stinks this doesn't have its own kernel - it really is just a GUI without it. It surprises me that so many people are blowing it off as no big deal. Writing the kernel is not a simple detail, we're talking about a lot of functionality that is missing that takes a lot of work to get right.
I think the discussion of what constitutes an OS is mostly academic.
That said, to me, an operating system is basically any environment that allows me to run applications.
Usually, that implies a kernel, since you can't do much without one, but in some circumstances, you might not have a "kernel" in the traditional sense.
For example, LXC containers don't have their own kernel, but they provide an environment - binaries, libraries, etc - where I can run applications. I can rightly call that an OS, I think.
Edit: clarity
That said, to me, an operating system is basically any environment that allows me to run applications.
Usually, that implies a kernel, since you can't do much without one, but in some circumstances, you might not have a "kernel" in the traditional sense.
For example, LXC containers don't have their own kernel, but they provide an environment - binaries, libraries, etc - where I can run applications. I can rightly call that an OS, I think.
Edit: clarity
> "I think the discussion of what constitutes an OS is mostly academic."
An operating system is the software used to interface hardware and applications. If you miss out on control of hardware it's not an OS. At most, solutions like unikernels are an edge case, but anything with less direct control over hardware than unikernels are not. If the term 'OS' is too loose it becomes meaningless.
An operating system is the software used to interface hardware and applications. If you miss out on control of hardware it's not an OS. At most, solutions like unikernels are an edge case, but anything with less direct control over hardware than unikernels are not. If the term 'OS' is too loose it becomes meaningless.
I agree. These things aren't OS's. They're platform emulators that run using the low-level plumbing of actual OS's. Going from that to bare metal has been hard enough for hobbyists that many barely got anything done on it or didn't try. We should only call them OS's when they run on bare metal or something like VirtualBox.
Could look more like a Lisp Machine...
ChrysaLisp is an Assembler/C-Script/Lisp 64 bit OS. MIMD, multi CPU, multi threaded, multi core, multi user, and will build from source in ~2 seconds on most OS X or x64 Linux desktops.
Maybe this will let me live vicariously through someone who has actually built the project I always dream of creating in my free time.