Yesterday, I was reading posts on Gab and came across this post:
Anyone good with math? I’m good with things up to a point, but I’ve not had to figure this type of math since HS.
Trying to figure out how to take a straight line and determine how tall it would be, if bent into an arch.
For example, if the width is 20 feet, and the pvc pipe is 40 feet in length, when bent into shape to arc from side to side of what will be a greenhouse, how tall will it be?
This past week, I setup a custom binary format on my workstation for WebAssembly.
Such formats can be setup without modifying the kernel thru the binfmt_misc
capability built into the Linux kernel. This allows specifying an interpreter for
files that are neither a native binary format nor a script starting with #!.
In my case, I setup an interpreter for WebAssembly using the wasmtime
runtime. To do so, I created a file at /etc/binfmt.d/webasm.conf with the contents
Recently, I was reading this article about compiling Ada to WebAssembly and running in the browser. I haven’t used Ada and I don’t plan to, but because I was curious about how they were doing OpenGL from WebAssembly, I took a peak at the JavaScript shim they were using and found code like this:
__adawebpack__html__Button__disabled_getter: function(identifier) {
return +(__adawebpack_o2i.too(identifier).disabled);
},
__adawebpack__html__Button__disabled_setter: function(identifier,to) {
__adawebpack_o2i.too (identifier).disabled = (to !== 0);
},
__adawebpack__html__Canvas__height_getter: function(identifier) {
return __adawebpack_o2i.too(identifier).height;
},
I’m sure that it works, but I found it looked a bit clunky. So I began thinking
about how I would get the same behavior while not having to produce so much
boilerplate code. The idea of using handles to reference JavaScript objects
is good, so I kept it, but tried to reduce the remainder to as few API calls
as I thought was reasonable. JavaScript helps here in that ever object except
window can be accessed thru window with indexing (i.e. [])
Here is what I came up with:
One milestone I will be looking forward to in the WebAssembly space is when a compiler that can output WebAssembly has been compiled to WebAssembly and is capable of compiling itself. The first compiler to do this will be the first native WebAssembly compiler. Right now, all compilers that output WebAssembly do so as a cross compiler, where the compiler is one instruction set (x86_64, aarm64, etc.) and outputs binaries in a different instruction set (WebAssembly aka. WASM).
Another weekend, another wabt-hole.
I got crystal to compile to WebAsembly and then run in Brave, and it only took two days to get setup and get it to print out “Hello, World!” in the console.
I have tried to use WebAssembly a couple of years ago, but dropped it once I failed to get a simple hello world program to function. This is the same reason I don’t have Haskell under my programming utility belt, no hello world. It is rather helpful that the environment, tools and tutorials have come a long way in the past couple of years.
Over the past couple of years, I’ve been thinking about things that could be used to replace parts of the internet and web we currently use. There are projects like cjdns that are looking to replace the network routing layer of the internet with a system that does not require a centralized authority to issue IP addresses.
There are other parts of the web stack that are looking to be replaced (IPFS is one of them, looking to replace HTTP(S)), but the one I will be looking at in this post is the Domain Name System (DNS).
I have made another change to the git repo handling code so that when publishing, only the repos that have been updated are added to IPFS again. This way, large repos only slow down the publish process when they are updated and not every time any repository is updated. The new process is this:
Now, git push is almost exactly the same speed as a plain ssh remote (only
an additional flag set), the update is fast for small repositories and only slows
down when processing a large repo.
I have a set of git repos published to IPFS that I talked about before here. Since that post a month ago, the repos have grown in count and size to the point that it is no longer feasible to use the automatic publish as it was. I have made one change and found that I am required to make further changes for it to remain usable.
The change already made is to no longer run the publish from the post-update hook
and to instead have that create a file in a spool directory and have a separate
process monitor the spool directory and launch the publish script. This has the
effect of the git push master to return quickly (it only needs to create a file).
About 26 hours later, and somewhere between 10 and 14 hours of programming in a language I had not used before, I have a libipfs at a Proof of Concept stage. I have a program written in crystal (because I am familiar with it and it lets you right C bindings in crystal) that initializing an IPFS node, connects to the bootstrap nodes, and downloads the CID from the ipfs-as-a-library example. I think this could expand into something useful because most programming languages have a way to call C functions.
I have had an idea floating around for a while now about a C interface to IPFS. Today, I stumbled upon this thread about using ipfs as a library. I remembered the C-library idea and was able to find this article about how to make go libraries that can be called from C. And thus I dove head-first down the rabbit hole and spent the next two hours creating a proof-of-concept C bindings for go-ipfs.