AIT
LjTools
AIT | LjTools | |
---|---|---|
8 | 11 | |
124 | 251 | |
- | - | |
8.6 | 0.0 | |
25 days ago | over 1 year ago | |
Haskell | C++ | |
- | 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.
AIT
-
Ray Tracer in a Boot Sector
It is described in https://github.com/tromp/AIT/blob/master/fast_growing_and_co...
-
Does quantum theory imply the entire Universe is preordained?
A = λxλyλz. x z (y (λ_.z)), which is encoded as bit 0 (left branch), while bit 1 (right branch) encodes prefix application.
[1] https://github.com/tromp/AIT/blob/master/ait/allA.lam
-
Show HN: Lambda-8cc – An x86 C compiler written in untyped lambda calculus
I expect so, as the author is familiar with my tools [1] for doing these optimizations.
[1] https://github.com/tromp/AIT
-
Minimalism in Programming Language Design
Haskell is not far from being a layer of syntactic sugar on top of the lambda calculus.
For an example of a non-trivial program, see this binary lambda calculus self-interpreter: https://github.com/tromp/AIT/blob/master/uni.lam
- Lambda Calculus in 400 Bytes
- Show HN: Lisp with GC in 436 Bytes
-
A Busy Beaver champion derived from scratch
While Goodstein sequences do get really long quite fast, they're not that easy to code. This [1] binary lambda calculus program may be the shortest possible, but still takes 351 bits. Meanwhile, in a mere 215 bits, we can encode a Laver table [2] program that potentially grows so much faster than Goodstein, that it's not even provable in ZFC [3].
[1] https://github.com/tromp/AIT/blob/master/goodstein.lam
[2] https://github.com/tromp/AIT/blob/master/laver.lam
[3] https://codegolf.stackexchange.com/questions/79620/laver-tab...
LjTools
-
LuaJIT decompiler that supports GOTO statements?
I dug a little more and came across this tool which does seem to have the capability to view all LuaJIT Bytecode. https://github.com/rochus-keller/LjTools
-
A History of Lua
> a large lua game code base, over 4000 files, 1.5 million lines of code
Interesting; how do you manage to keep consistency? Do you have special tools to e.g. detect inadvertent global variables? I once wrote a Smalltalk VM in Lua (https://github.com/rochus-keller/Smalltalk/blob/master/Inter...) which is a much smaller code base but even with this size I quickly would have lost track of e.g. scopes and names without tools I had to write myself (https://github.com/rochus-keller/LJTools).
- Minimalism in Programming Language Design
-
KT/COBOL — Choosing a VM edition — I need to hear your experiences with the VM you're currently using for your project.
Most of my languages have VM backends; see e.g. https://github.com/rochus-keller/Oberon; I implemented different backends generating LuaJIT bytecode; a year ago I switched to Mono which is based on ECMA-335; here is a discussion why I switched: https://github.com/rochus-keller/Oberon/releases/tag/IDEv0.9.0; I implemented utility libraries for both LuaJIT and CIL bytecode; see https://github.com/rochus-keller/LjTools/, https://github.com/rochus-keller/Pelib/ and https://github.com/rochus-keller/MonoTools/. I evaluated many VMs and think the mentioned ones are best suited. There were a lot of challenges with both technologies, what is to be expected, and too much to describe here.
-
LuaJIT for backend?
LuaJIT is well suited as a backend/runtime environment for custom languages; I did it several times (see e.g. https://github.com/rochus-keller/Smalltalk, https://github.com/rochus-keller/Som/, https://github.com/rochus-keller/Oberon/). I also implemented a bit of infrastructure to ease the reuse: https://github.com/rochus-keller/LjTools. LuaJIT has some limitations though; if you require closures you have to know that the corresponding LuaJIT FNEW bytecode is not yet supported by the JIT, i.e. switches to the interpreter; as a work-around I implemented my own closures; LuaJIT also doesn't support multi-threading, but co-routines; and there is no debugger, and the infrastructure to implement one has limitations (i.e. performance is low when running to breakpoints). For most of my projects this was no issue. Recently I switched to CIL/Mono for my Oberon+ implementation which was a good move. But still I consider LuaJIT a good choice if you can cope with the mentioned limitations. The major advantage of LuaJIT is the small footprint and impressive performance for dynamic languages.
-
Writing a Register Based VM
Implementing a VM is certainly interesting, but if you just need a fast backend you could generate LuaJIT bytecode (see e.g. https://github.com/rochus-keller/ljtools/ LuaJitComposer.h/cpp).
- Finl Is Not LaTeX
- (LuaJIT) How to directly modify strings within LuaJIT Bytecode?
-
Bytecode for a Register Machine
If you want to re-use LuaJIT as a backend, have e.g. a look at https://github.com/rochus-keller/ljtools
-
Favorite Program for writing LUA?
Recently I mostly use https://github.com/rochus-keller/LjTools#lua-parser-and-ide-features
What are some alternatives?
cosmopolitan - build-once run-anywhere c library
SATySFi - A statically-typed, functional typesetting system
lambda-calculus-devkit - A collection of lambda calculus interpreters and development tools
ubpf - Userspace eBPF VM
elvm - EsoLangVM Compiler Infrastructure
Oberon - Oberon parser, code model & browser, compiler and IDE with debugger
OBNC - A Oberon-07 to C translator. Forked from http://miasap.se/obnc/
port70 - A Gopher server in Lua
nokolisp - Lisp interpreter and compiler from 1977-1988 for MSDOS.
tex-rs - A port of TeX82 to Rust. (WIP)
blamscript - game scripting documentation for halo speedruns
langs