stoneknifeforth
rupy
Our great sponsors
stoneknifeforth | rupy | |
---|---|---|
13 | 31 | |
405 | 136 | |
- | - | |
0.0 | 1.1 | |
almost 4 years ago | about 1 year ago | |
Forth | Java | |
Creative Commons Zero v1.0 Universal | - |
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.
stoneknifeforth
- Konilo: A personal computing system in Forth
-
Writing a Compiler is Surprisingly Easy (part 1)
a problem that a lot of these series run into is that the author runs out of steam before they finish writing them. crenshaw's otherwise excellent series suffers from this, for example
so far the author of this one has only written the first chapter
i've written a few didactic compilers that are complete enough to compile themselves, though nothing else
https://github.com/kragen/stoneknifeforth (from a forth-like language to an i386 linux elf executable)
https://github.com/kragen/peg-bootstrap/blob/master/peg.md (from a peg language description with semantic actions to javascript)
http://canonical.org/~kragen/sw/urscheme (from a subset of scheme to at&t-syntax i386 assembly)
-
MilliForth
Look at how much room you have for data! I wonder what we can fit in there.
More seriously, a metacircular example to draw from would be: https://github.com/kragen/stoneknifeforth
-
Lisp as the Maxwell’s Equations of Software
i wasn't able to get a runnable forth to less than a couple of pages written in itself https://github.com/kragen/stoneknifeforth but schönfinkel's ski-combinators are maybe the simplest practical basis
s f g x → f x (g x)
-
Stop Writing Dead Programs (Transcript)
I've done all these things (except designing the hardware) and I agree that it can be very painful. I did some of them in 02008, for example: https://github.com/kragen/stoneknifeforth
The thing is, though, you can also not do all those things. You can use variables, and they don't even have to be allocated on a stack (unless you're writing a recursive function, which you usually aren't), and all the NIP TUCK ROT goes away, and with it all the Memory Championship tricks. You can test each definition interactively as you write it, and then the fact that the language is absurdly error-prone hardly matters. You can use metaprogramming so that your code is as DRY as a nun's pochola. You can use the interactivity of Forth to quickly validate your hypotheses about not just your code but also the hardware in a way you can't do with C. You can do it with GDB, but Forth is a lot faster than GDBscript, but that's not saying much because even Bash is a lot faster than GDBscript.
But Yossi was just using Forth as a programming language, like a C without local variables or type checking, not an embedded operating system. And, as I said, that's really not Forth's strength. Bash and Tcl aren't good programming languages, either. If you try to use Tcl as a substitute for C you will also be very sad. But the way they're used, that isn't that important.
I explained a more limited version of this 12 years ago: https://yosefk.com/blog/my-history-with-forth-stack-machines...
So, I don't think Forth is only useful when you have the freedom to change the problem, though programs in any language do become an awful lot easier when you have that freedom.
- StoneKnifeForth
-
A complete compiler and VM in 150 lines of code
That's powerful enough to conveniently write, for example, a numerical root finding program for an arbitrary arithmetic expression.
But I think that within a complexity budget of 150 lines of code you can maybe be even more ambitious than that.
The example compiler in https://github.com/darius/parson/blob/master/eg_calc_compile... is a bit more stripped down than that, but in its 32 lines of code it compiles arithmetic assignment statements to a three-address RISC-like code (though using an unbounded number of registers). https://github.com/darius/parson/blob/master/eg_calc_to_rpn.... is a 16-line version that compiles the same language to a stack machine like your tutorial example.
In 66 lines of code in https://github.com/kragen/peg-bootstrap/blob/master/peg.md I wrote an example compiler which compiles a PEG grammar into a JavaScript parser for that grammar. Admittedly those 66 lines do not include an implementation of JavaScript to run the code on. It compiles the language it's written in.
In 132 lines of code in https://github.com/kragen/stoneknifeforth/blob/master/tinybo... I wrote an example compiler which compiles a crippled Forth dialect into i386 machine code, including an ELF header so you can run the result. It also compiles the language it's written in. It also doesn't include an i386 emulator to run it on.
In 83 lines of code in http://canonical.org/~kragen/sw/dev3/neelcompiler.ml Neel Krishnaswami wrote a compiler from the untyped λ-calculus to a simple assembly language for a register machine. It also doesn't include an implementation of the assembly language.
In 18 lines of code in http://canonical.org/~kragen/sw/dev3/meta5ix.m5, a simplification of META-II, I wrote a compiler from grammar descriptions to an assembly code for a parsing-oriented virtual machine. It compiles the language it's written in. A Python interpreter for the machine is in http://canonical.org/~kragen/sw/dev3/meta5ixrun.py (109 lines of code) and a precompiled version of the compiler-compiler for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix.generated.m5asm.
A slightly incompatible variant of Meta5ix which instead compiles itself to C is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.m5 (133 lines of code, depending on how you count). (No C compiler is included.) The precompiled C output for bootstrapping is in http://canonical.org/~kragen/sw/dev3/meta5ix2c.c.
Meta5ix is extremely weak and limited, really only enough for a compiler front-end; it can't, for example, do the kinds of RPN tricks we're talking about above.
-
Looking for a simple forth compiler (producing asm/executables, not compiling forth words) to learn from, preferably in C family language
Title effectively says it all. The only thing I have found is StoneKnife Forth (implementation is in tinyboot1.tbf1) but this file is implemented in the same dialect of forth it implements, which due to being minimal makes it difficult to read and comprehend efficiently (I also can't find the origin of some words such as 'byte' used in the code but not implemented by the interpreter). I would prefer something in the C family to look at but anything should do as long as it's clean enough that I could use it as a reference to reimplement the compiler without much difficulty. Thank you in advance for any help with what is seemingly quite a narrow request.
-
An HTTP server in a single .c file
I'm pretty sure Linux ELF has always allowed you to specify the initial load address. When I first wrote StoneKnifeForth https://github.com/kragen/stoneknifeforth its load address was 0x1000, but at some point Linux stopped allowing load addresses lower than 0x10000 by default (vm.mmap_min_addr). I originally wrote it in 02008, using the lower load address, and fixed it in 02017. It's still not using 0x804800 like normal executables but 0x20000. ASLR does not affect this.
Maybe you mean that before ELF support, Linux a.out executables had to be loaded at a fixed virtual address? That's possible—I started using Linux daily in 01995, at which point a.out was already only supported for backward compatibility.
- StoneKnifeForth (With a Metacircular Compiler)
rupy
-
Considerations for a long-running Raspberry Pi
I have been running a Raspberry 2 cluster for 10 years: http://host.rupy.se
A few weeks back the first SD card to fail got so corrupted it failed to reboot!
My key learning is use oversized cards, because then the bitcycle will wear slower!
I'm going from 32GB to 256/512/1024!
-
What Kind of Asynchronous Is Right for You?
How this article does not mention SSE, comet or chunking escapes me.
What does their definition of event-driven really look like in practice.
Nobody has a clue.
Here is the ideal event driven system, it's async-to-async: https://github.com/tinspin/rupy/wiki/Fuse
The example is not working because I had to shut down the services for multiple reasons, but the high level of it is that you use 4 (potentially different) threads to do one request/response middle man transaction.
That way you have _zero_ io-wait or idling. I'm surprised nobody has copied this approach since I invented it 10 years ago. I understand why though you need your entire chain to be async and that means rewriting everything and that is a big risk when it's hard to debug.
But if you succeed you can build something that is 10x perf/watt than all other implementations. Which is going to be important when interest rates go higher and crash our entire industry.
-
An unknown Swedish startup’s €3B bid to build a green rival to AWS
The hardware is peaking.
So software is where you can make the difference: http://host.rupy.se
- Sandstorm: Open-source platform for self-hosting web app
-
You Want Modules, Not Microservices
I think we're all confused over the definition. Also one might understand what all the proponents are talking about better if they think about this more as a process and not some technological solution:
https://github.com/tinspin/rupy/wiki/Process
All input I have is you want your code to run on many machines, in fact you want it to run the same on all machines you need to deliver and preferably more. Vertically and horizontally at the same time, so your services only call localhost but in many separate places.
This in turn mandates a distributed database. And later you discover it has to be capable of async-to-async = no blocking ever anywhere in the whole solution.
The way I do this is I hot-deploy my applications async. to all servers in the cluster, this is what a cluster node looks like in practice (the name next to Host: is the node): http://host.rupy.se if you click "api & metrics" you'll see the services.
With this not only do you get scalability, but also redundancy and development is maintained at live coding levels.
-
I wish my web server were in the corner of my room
I have hosted my own web server both physically and codevise since 2014.
It's on a Raspberry 2 cluster:
http://host.rupy.se
Since 2016 i have my own database also coded from scratch:
http://root.rupy.se
We need to implement HTTP/1.1 with less bloat, a C non-blocking web server that can share memory between threads is probably the most interesting project for humans right now, is anyone working on that?
-
Ask HN: Free and open source distributed database written in C++ or C
I have one in Java: https://github.com/tinspin/rupy
Here is the 2000 lines of code of the entire database: http://root.rupy.se/code?path=/Root.java
And here you can try it out: http://root.rupy.se
-
Dokku – Free Heroku Alternative
The smallest PaaS you have ever seen is one order of magnitude larger than mine: https://github.com/tinspin/rupy
And I bet you the same goes for performance, if not two!
-
Server-Sent Events: the alternative to WebSockets you should be using
The data is here: http://fuse.rupy.se/about.html
Under Performance. Per watt the fuse/rupy platform completely crushes all competition because of 2 reasons:
- Event driven protocol design, averages at about 4 messages/player/second (means you cannot do spraying or headshots f.ex. which is another feature in my game design opinion).
- Java's memory model with atomic concurrency which needs a VM and GC (C++ copied that memory model in C++11, but it failed completely because they lack both VM and GC, but that model is still to this day the one C++ uses), you can read more about this here: https://github.com/tinspin/rupy/wiki
You can argue those points are bad arguments, but if you look at performance per watt with some consideration for developer friendlyness, I'm pretty sure in 100 years we will still be coding minimalist JavaSE on the server and vanilla C (compiled with C++ compiler) on the client.
- Jodd – The Unbearable Lightness of Java
What are some alternatives?
jonesforth - Mirror of JONESFORTH
huproxy
durexforth - Modern C64 Forth
cmdg - Command line Gmail client
factor - Factor programming language
Nullboard - Nullboard is a minimalist kanban board, focused on compactness and readability.
r4 - :r4 concatenative programming language with ideas from ColorForth.
cakephp-swagger-bake - Automatically generate OpenAPI, Swagger, and Redoc documentation from your existing CakePHP code.
r3d4 - r3 programing language for 64 bits Windows/Linux/Mac/Rasberry Pi 4
dbmate - :rocket: A lightweight, framework-agnostic database migration tool.
http - A simple multi-threaded HTTP/1.0-ish file server. Single file, ~250 LOC.
Aerospike - Aerospike Database Server – flash-optimized, in-memory, nosql database