We decided that we want to move away from throwing exceptions in AOs and regular functions implicitly and then returning some default-constructed value (usually an empty JS::Value) - this requires remembering to check for an exception at the call site, which is error-prone. It's also awkward for return values that cannot be default-constructed, e.g. MarkedValueList. Instead, the thrown value should be part of the function return value. The solution to this is moving closer to the spec and using something they call "completion records": https://tc39.es/ecma262/#sec-completion-record-specification-type This has various advantages: - It becomes crystal clear whether some AO can fail or not, and errors need to be handled and values unwrapped explicitly (for that reason compatibility with the TRY() macro is already built-in, and a similar TRY_OR_DISCARD() macro has been added specifically for use in LibJS, while the majority of functions doesn't return ThrowCompletionOr yet) - We no longer need to mix "valid" and "invalid" values of various types for the success and exception outcomes (e.g. null/non-null AK::String, empty/non-empty JS::Value) - Subsequently it's no longer possible to accidentally use an exception outcome return value as a success outcome return value (e.g. any AO that returns a numeric type would return 0 even after throwing an exception, at least before we started making use of Optional for that) - Eventually the VM will no longer need to store an exception, and temporarily clearing an exception (e.g. to call a function) becomes obsolete - instead, completions will simply propagate up to the caller outside of LibJS, which then can deal with it in any way - Similar to throw we'll be able to implement the functionality of break, continue, and return using completions, which will lead to easier to understand code and fewer workarounds - the current unwinding mechanism is not even remotely similar to the spec's approach The spec's NormalCompletion and ThrowCompletion AOs have been implemented as simple wrappers around the JS::Completion constructor. UpdateEmpty has been implemented as a JS::Completion method. There's also a new VM::throw_completion<T>() helper, which basically works like VM::throw_exception<T>() - it creates a T object (usually a JS::Error), and returns it wrapped in a JS::Completion of Type::Throw. Two temporary usage patterns have emerged: 1. Callee already returns ThrowCompletionOr, but caller doesn't: auto foo = TRY_OR_DISCARD(bar()); 2. Caller already returns ThrowCompletionOr, but callee doesn't: auto foo = bar(); if (auto* exception = vm.exception()) return throw_completion(exception->value()); Eventually all error handling and unwrapping can be done with just TRY() or possibly even operator? in the future :^) Co-authored-by: Andreas Kling <kling@serenityos.org> |
||
---|---|---|
.github | ||
AK | ||
Base | ||
Documentation | ||
Kernel | ||
Meta | ||
Ports | ||
Tests | ||
Toolchain | ||
Userland | ||
.clang-format | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
.pre-commit-config.yaml | ||
.prettierignore | ||
.prettierrc | ||
azure-pipelines.yml | ||
CMakeLists.txt | ||
CONTRIBUTING.md | ||
LICENSE | ||
README.md |
SerenityOS
Graphical Unix-like operating system for x86 computers.
About
SerenityOS is a love letter to '90s user interfaces with a custom Unix-like core. It flatters with sincerity by stealing beautiful ideas from various other systems.
Roughly speaking, the goal is a marriage between the aesthetic of late-1990s productivity software and the power-user accessibility of late-2000s *nix. This is a system by us, for us, based on the things we like.
I (Andreas) regularly post raw hacking sessions and demos on my YouTube channel.
Sometimes I write about the system on my github.io blog.
I'm also on Patreon and GitHub Sponsors if you would like to show some support that way.
Screenshot
Kernel features
- x86 (32-bit) and x86_64 (64-bit) kernel with pre-emptive multi-threading
- Hardware protections (SMEP, SMAP, UMIP, NX, WP, TSD, ...)
- IPv4 stack with ARP, TCP, UDP and ICMP protocols
- ext2 filesystem
- POSIX signals
- Purgeable memory
- /proc filesystem
- Pseudoterminals (with /dev/pts filesystem)
- Filesystem notifications
- CPU and memory profiling
- SoundBlaster 16 driver
- VMWare/QEMU mouse integration
System services
- Launch/session daemon (SystemServer)
- Compositing window server (WindowServer)
- Text console manager (TTYServer)
- DNS client (LookupServer)
- Network protocols server (RequestServer and WebSocket)
- Software-mixing sound daemon (AudioServer)
- Desktop notifications (NotificationServer)
- HTTP server (WebServer)
- Telnet server (TelnetServer)
- DHCP client (DHCPClient)
Libraries
- C++ templates and containers (AK)
- Event loop and utilities (LibCore)
- 2D graphics library (LibGfx)
- OpenGL 1.x compatible library (LibGL)
- GUI toolkit (LibGUI)
- Cross-process communication library (LibIPC)
- HTML/CSS engine (LibWeb)
- JavaScript engine (LibJS)
- Markdown (LibMarkdown)
- Audio (LibAudio)
- Digital Signal Processing/Synthesizer Chains (LibDSP)
- PCI database (LibPCIDB)
- Terminal emulation (LibVT)
- Out-of-process network protocol I/O (LibProtocol)
- Mathematical functions (LibM)
- ELF file handling (LibELF)
- POSIX threading (LibPthread)
- Higher-level threading (LibThreading)
- Transport Layer Security (LibTLS)
- HTTP and HTTPS (LibHTTP)
- IMAP (LibIMAP)
Userland features
- Unix-like libc and userland
- Shell with pipes and I/O redirection
- On-line help system (both terminal and GUI variants)
- Web browser (Browser)
- C++ IDE (HackStudio)
- Desktop synthesizer (Piano)
- E-mail client (Mail)
- Various desktop apps & games
- Color themes
How do I read the documentation?
Man pages are available online at man.serenityos.org. These pages are generated from the Markdown source files in Base/usr/share/man
and updated automatically.
When running SerenityOS you can use man
for the terminal interface, or help
for the GUI.
How do I build and run this?
See the SerenityOS build instructions
Before opening an issue
Please see the issue policy.
FAQ: Frequently Asked Questions
Get in touch
Join our Discord server: SerenityOS Discord
Author
- Andreas Kling - awesomekling
Contributors
- Robin Burchell - rburchell
- Conrad Pankoff - deoxxa
- Sergey Bugaev - bugaevc
- Liav A - supercomputer7
- Linus Groh - linusg
- Ali Mohammad Pur - alimpfard
- Shannon Booth - shannonbooth
- Hüseyin ASLITÜRK - asliturk
- Matthew Olsson - mattco98
- Nico Weber - nico
- Brian Gianforcaro - bgianfo
- Ben Wiederhake - BenWiederhake
- Tom - tomuta
- Paul Scharnofske - asynts
- Itamar Shenhar - itamar8910
- Luke Wilde - Lubrsi
- Brendan Coles - bcoles
- Andrew Kaster - ADKaster
- thankyouverycool - thankyouverycool
- Idan Horowitz - IdanHo
- Gunnar Beutner - gunnarbeutner
- Tim Flynn - trflynn89
- Jean-Baptiste Boric - boricj
- Stephan Unverwerth - sunverwerth
- Max Wipfli - MaxWipfli
- Daniel Bertalan - BertalanD
- Jelle Raaijmakers - GMTA
- Sam Atkins - AtkinsSJ
- Tobias Christiansen - TobyAsE
- Lenny Maiorani - ldm5180
- sin-ack - sin-ack
- Jesse Buhagiar - Quaker762
- Peter Elliott - Petelliott
- Karol Kosek - krkk
- Mustafa Quraish - mustafaquraish
(And many more!) The people listed above have landed more than 100 commits in the project. :^)
License
SerenityOS is licensed under a 2-clause BSD license.