lone
Oberon
lone | Oberon | |
---|---|---|
7 | 76 | |
301 | 429 | |
1.7% | - | |
9.6 | 7.0 | |
5 days ago | 20 days ago | |
C | C++ | |
GNU Affero General Public License v3.0 | GNU General Public License v3.0 only |
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.
lone
-
How to Write a (Lisp) Interpreter (In Python)
I made something somewhat close to that: a freestanding lisp. It targets the Linux kernel directly. No libc.
https://github.com/lone-lang/lone
-
Boehm Garbage Collector
> register scanning isn't portable
Certainly not but it wasn't particularly hard to implement either. I just wrote some inline assembly for every architecture. Here's my programming language's x86_64 and aarch64 implementations:
https://github.com/lone-lang/lone/blob/master/architecture/x...
https://github.com/lone-lang/lone/blob/master/architecture/a...
-
Show HN: Self-contained Linux apps in Lisp
Not too long ago, a project of mine was shared here on HN.
https://news.ycombinator.com/item?id=38126052
In that thread I wrote:
> I have this vision in my mind: embedding lone modules into sections of the lone ELF and shipping it out. Zero dependencies, self-contained.
I've been working on that since that day. Proud to say I've gotten it to work and thought I'd make it the subject of my first Show HN. Some free software projects gained features along the way too.
The link is to an article with a proper demonstration, technical details and what happened in the past few weeks.
The complete repository itself can be found here:
https://github.com/lone-lang/lone
I've completely reorganized it since the last thread. Would be very happy if you guys tried it out.
- A standalone zero-dependency Lisp for Linux
-
Decoded: GNU Coreutils
To test my programming language. It's a freestanding lisp interpreter that doesn't link to libc. I wrote the code that handles the environment variables and in order to test it I needed full control over the program's inputs including its environment. The env utility provides this control by emptying the environment and setting only the variables I specify, solving 90% of the problem. Only thing I still can't control is argv[0]. With this new feature upstreamed, my test suite will be complete.
Here's the code if you'd like to take a look:
https://github.com/lone-lang/lone#testing
https://github.com/lone-lang/lone/blob/master/scripts/test.b...
-
Writing Small CLI Programs in Common Lisp (2021)
> only to be confronted with the notorious 'incompatible glibc version error'. It's super annoying.
I started making my own freestanding Linux Lisp because of this exact issue. It's nowhere near as performant as something like SBCL but it's small and once compiled has no dependencies and will literally run on any Linux.
https://github.com/lone-lang/lone
I'm taking a break from this project but I plan to add a feature where I can put a Lisp script into the ELF itself so I can just copy it with the scripts included.
-
The 90s Developer Starter Pack
The kernel just puts the data contiguously on the stack. Obtaining pointers to them can seem somewhat magical if you're writing a nolibc program but I wouldn't call it horrible.
I implemented it for my programming language with some rather simple assembly code:
https://github.com/lone-lang/lone/blob/master/arch/x86_64.c#...
https://github.com/lone-lang/lone/blob/master/arch/aarch64.c...
Oberon
-
Boehm Garbage Collector
> Sure there's a small overhead to smart pointers
Not so small, and it has the potential to significantly speed down an application when not used wisely. Here are e.g. some measurements where the programmer used C++11 and did everything with smart pointers: https://github.com/smarr/are-we-fast-yet/issues/80#issuecomm.... There was a speed down between factor 2 and 10 compared with the C++98 implementation. Also remember that smart pointers create memory leaks when used with circular references, and there is an additional memory allocation involved with each smart pointer.
> Garbage collection has an overhead too of course
The Boehm GC is surprisingly efficient. See e.g. these measurements: https://github.com/rochus-keller/Oberon/blob/master/testcase.... The same benchmark suite as above is compared with different versions of Mono (using the generational GC) and the C code (using Boehm GC) generated with my Oberon compiler. The latter only is 20% slower than the native C++98 version, and still twice as fast as Mono 5.
-
Niklaus Wirth, or the Importance of Being Simple
Great, thanks!
There are books online for free, e.g.
https://people.inf.ethz.ch/wirth/ProgInOberonWR.pdf
and https://ssw.jku.at/Research/Books/Oberon2.pdf
Oberon+ is a superset of Oberon 90 and Oberon-2. Here is more information: https://oberon-lang.github.io/, and here is the current language specification: https://github.com/oberon-lang/specification/blob/master/The.... I already had valuable feedback here on HN concerning the channel extensions. Further research brought me to the conclusion, that Oberon+ should support both, channels and also monitors, because even in Go, the sync package primitives are used twice as much as channels. Mutexes and condition variables can be emulated with channels (I tried my luck here: https://www.quora.com/How-can-we-emulate-mutexes-and-conditi...), but for efficiency reasons I think monitors should be directly supported in the language as well, even if it might collide with the goal of simplicity.
Feel free to comment here or e.g. in https://github.com/rochus-keller/Oberon/discussions/45.
-
Tex-Oberon: Make Project Oberon Pretty Again
> Does anyone know why Wirth never modernized his style?
Readability. It's easier to read the source code with uppercase keywords. (I think Wirth once said that code is written once but read many times). See this source code - https://raw.githubusercontent.com/rochus-keller/OberonSystem... - to get an idea of this (the uppercase keywords allow you to easily scan the blocks of code). Ofcourse, one can claim that the same can be achieved better today with colour-coded keywords.
If I remember right, the Oberon+ IDE - https://github.com/rochus-keller/Oberon - gives you an option to disable this and use lowercase keywords.
- FreeOberon cross-platform Oberon language IDD
-
Project Oberon (New Edition 2013)
> gain a deep understanding of it .. generate smaller subsets of the system
You can use the OberonViewer for this purpose with the original source code, or the Oberon IDE with a version of the Project Oberon System which runs with SDL on all platforms, see https://github.com/rochus-keller/oberon/#binary-versions and https://github.com/rochus-keller/OberonSystem/tree/FFI
-
KolibriOS on Single Floppy Disk
> Regardless, which one is more likely to be ported to a different architecture in the future?
Not sure I understand the question. I'm talking about CPU architectures. The current implementation is in x86 assembler. So if you want to run it on AMD64 or ARM, then you have to replace all assembler files, in the present case probable the full source code.
> what are the comparative performance benchmarks of the low-level language versus the high-level language?
I don't have any measurements. But consider that many operating systems are implemented in C (e.g. Linux) with only isolated parts in assembler, so it is easier to port to other architectures. Linux apparently is fast enough and available for nearly every CPU. Oberon in contrast to C is garbage collected, which also affects performance. I have measurements comparing the same benchmark suite implemented in C++ and in Oberon, where the former is about 22% faster (see https://github.com/rochus-keller/Oberon/blob/master/testcase...).
- Why Use Pascal?
-
C or LLVM for a fast backend?
I actually had a similar problem some years ago and finally moved away from LLVM because of complexity, continuous research effort and performance. My current Oberon+ implementation works like this: the CIL code generator together with Mono is used during development, integrated with the IDE, using the debugging features integrated in Mono; to deploy the application and to gain another factor 2 of performance C99 instead of CIL can be generated and compiled with any compatible toolchain. Here are some performance measurements: https://github.com/rochus-keller/Oberon/blob/master/testcases/Are-we-fast-yet/Are-we-fast-yet_results_linux.pdf. Compiling to CIL is very fast and the time Mono needs to compile and run is barely noticable.
- Do transpilers just use a lot of string manipulation and concatenation to output the target language?
-
Native AOT Overview
> annoying aspects was requiring the .NET runtime ... OpenJDK is a blessed implementation in a way that Mono never was
Which is unjustified, because Mono CLR is just a single executable less than 5 MB which you can download and run without a complicated installation process (see e.g. https://github.com/rochus-keller/Oberon/#binary-versions ). AOT compilation on the other hand is a huge and complex installation depending on a lot of stuff including LLVM, and the resulting executables are not really smaller than the CLR + mscorlib + app.
What are some alternatives?
mxe - MXE (M cross environment)
oberon-riscv - Oberon RISC-V port, based on Samuel Falvo's RISC-V compiler and Peter de Wachter's Project Norebo. Part of an academic project to evaluate Project Oberon on RISC-V.
CIEL - CIEL Is an Extended Lisp. Scripting with batteries included.
Smalltalk - Parser, code model, interpreter and navigable browser for the original Xerox Smalltalk-80 v2 sources and virtual image file
ohrrpgce - Official Hamster Republic RPG Construction Engine (mirror of SVN repository)
MoarVM - A VM with adaptive optimization and JIT compilation, built for Rakudo
freebsd-src - The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests....
tectonic - A modernized, complete, self-contained TeX/LaTeX engine, powered by XeTeX and TeXLive.
src - Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.
aws-lambda-rust-runtime - A Rust runtime for AWS Lambda
liblinux - Linux system calls.
atldotnet - Fully managed, portable and easy-to-use C# library to read and edit audio data and metadata (tags) from various audio formats, playlists and CUE sheets