IRC channel logs

<oriansj>xentrac: well that is the amazing part of about working in C; I don't have to be constrained by any Lisp rules to implement lisp functionality. (The most I have to deal with is compatibility)

<xentrac>hm? oh, you mean you prefer to write your Scheme macro transformations in C rather than in Scheme? I'm sure that's a reasonable preference to have in some way even if I can't imagine what it is :)

<xentrac>writing fexprs in C, by contrast, sounds totally reasonable

<xentrac>I guess in some sense that would make them fsubrs but that distinction disappeared sometime in the 1960s

<oriansj>xentrac: honestly I've spent the last 3 years writing exclusively assembly and C code for this project and I guess working is C just straight forward. Now if doing the work in scheme is easier; I'd do that (or perhaps someone might throw a patch or two to save me the effort)

<oriansj>Basically we are in the final stretch; onces mes-m2 is golden and running guix and the scheme programs needed to bootstrap GCC and guile. The bootstrap problem will be solved.

<oriansj>Then I have to do the Posix in M2-Planet route to solve the kernel bootstrap problem

<oriansj>and then I have to get into FPGAs and TTL to finish the final pieces

<xentrac>congratulations :)

<xentrac>hopefully you can find a smaller, saner kernel interface than POSIX

<xentrac>to run mes-m2 and tcc and stuff

<oriansj>xentrac: honestly, I wished more people would want to put their names on it; because at this point it is janneke and me doing 98+% of all the work

<oriansj>well the kernel will only need 8 syscalls to support mes-m2 and do the gcc bootstrap

<xentrac>open, close, read, write, fork, exec, exit... getdents?

<oriansj>seek

<xentrac>huh, what uses seek?

<oriansj>to rewind the file pointer for reading the file twice

<oriansj>(hex2 and M1 are two pass programs)

<xentrac>oh

<xentrac>if you give them the filename they could just open it again

<oriansj>xentrac: true

<xentrac>that might be easier than implementing seek

<xentrac>but maybe not in the long run

<oriansj>seek only needs to set the file pointer to the start of the file; not exactly hard to implement

<oriansj>plus we need to be able to run GCC on it to build Linux

<oriansj>(or a BSD)

<xentrac>GCC may demand more than eight system calls

<oriansj>(depending which group is willing to help us)

<xentrac>so here's the full definition from R5RS of the usual kind of let, unnamed let:

<oriansj>xentrac: absolutely correct (I just haven't had the chance to figure those out yet)

<xentrac>(define-syntax let (syntax-rules () ((let ((name val) ...) body1 body2 ...) ((lambda (name ...) body1 body2 ...) val ...))))

<xentrac>although in R5RS it's given with more readable formatting and with an additional case for named let

<xentrac>I think definitions like those are both easier to write and easier to read than corresponding procedural code that does the same restructuring

<xentrac>in Ur-Scheme I didn't implement syntax-rules, in part because implementing hygienic macros correctly is notoriously complicated

<xentrac>I didn't implement quasiquote, either, and so the Ur-Scheme implementation of the same thing looked like this:

<xentrac>(define-ur-macro 'let

<xentrac> (lambda (args)

<xentrac> (cons (cons 'lambda (cons (map car (car args)) (cdr args)))

<xentrac> (map cadr (car args)))))

<oriansj>xentrac: I guess the C version is a bit simpler: https://github.com/oriansj/mes-m2/blob/slow_lisp/mes_eval.c#L257

<xentrac>it looks a little less simple to me because I have to figure out what exp->cdr->car->car->cdr->car is to figure out what is being evaled

<xentrac>but I suppose it must be the right thing because it can run code that uses let :)

<xentrac>it sort of looks like compiler output

<xentrac>this is somewhat of a problem with the Ur-Scheme version as well!

<oriansj>xentrac: ironically that actually required me to sit down with a piece of paper and work out the correct way to do it

<xentrac>the piece of paper is unfortunately not in git

<oriansj>I probably need to draw lots of pretty little cons diagrams for the documenation

<xentrac>I've found graphviz useful for that; I've been thinking of hacking together a JS implementation of graphviz for Dercuano

<xentrac>in particular graphviz shape=record nodes allow you to draw arrows from or to particular parts of a node that you've divided into rectangular parts

<xentrac>for http://canonical.org/~kragen/memory-models/ I drew diagrams on paper with permanent marker in a café, photographed them, and processed them a bit

<oriansj>xentrac: nice

<xentrac>see https://graphviz.gitlab.io/_pages/Gallery/directed/datastruct.html for an example close to being a cons diagram

<oriansj>xentrac: if you use cgdb to walk the parse-tree in process_let; you'll see the structure is much simpler than you'll expect

<oriansj>(let ((a 1) (b (+ 1 a))) (begin ...)) is actually the exact shape of that parse-tree

<xentrac>oh, I did eventually puzzle it out!

<xentrac>but I still think the syntax-rules "(let ((name val) ...) body1 body2 ...)" is easier to read

<oriansj>xentrac: I guess people find different things easier

<xentrac>agreed!

<oriansj>but then again; if anyone wants to do this job I have no problem with someone else making a name for themselves doing it.

<oriansj>at this point; it is impressive enough that I bootstrapped a C compiler, written in C from hex. I wrote a Lisp in assembly. I wrote my own FORTH and now I am writing a Scheme powerful enough to bootstrap GCC (gotta dream big); using that C compiler that I bootstrapped...

<oriansj>heck, I might even port cc_* to z80 and 6502 assembly to hit the retro "Dear lord" combo

<xentrac>it is indeed very impressive :)

<xentrac>also, in addition to being impressive, it is crucially important

<oriansj>xentrac: is something really important if lots of people have the ability to solve the problem but no one does?

<oriansj>now it leaves me with only a few possibilities: 1) bootstrapping is only crucuially important to a much smaller subset of that population (aka the population of this channel + a handful of others) 2) It is more insanely difficult and thus the number of people capable of doing the work are rare

<xentrac>most of the humans are more concerned with getting laid, feeding their kids, wiping their grandparents' butts, getting drunk, and gaining social esteem, which is more usually attached to things like football prowess and fashionable clothes than to anything significant

<xentrac>of those who care about things that matter, some are crippled by their concern for them; my friend Aaron ended up hanging himself

<xentrac>most do not know about the bootstrapping problem at all. my surprise lover last month is passionately concerned about a variety of social issues, including patriarchy, capitalism, and pollution, but she does not have a clear idea of what a computer program consists of, I think

<xentrac>I did try to explain to her the trusted firmware problem but she fell asleep

<xentrac>I think she might have eventually understood what firmware was

<xentrac>of those who care and know, many of us are not very effective. I needed to spend today restructuring the parser combinators in the Hammer parsing engine because the current approach unavoidably leaks memory, and then going to class, for example, and instead I wasted it arguing about solar furnace designs: https://news.ycombinator.com/item?id=21578938

<oriansj>xentrac: well it is kinda like the problem of global warming; There are 118 people on this planet who can single handedly solve the problem of which more than half of them said it was a major concern of theirs. But we see none of them even investing in starting to actually solve the problem

<xentrac>I don't think anyone can singlehandedly solve the problem anymore. maybe when the US and USSR had larger nuclear arsenals that was possible

<xentrac>Also that solution would have had its drawbacks

<xentrac>But you can certainly find a lot more people willing to spend their nights and weekends working on global warming than on bootstrapping, because it's a problem that's both easier to understand and better known

<xentrac>Both of them pose a risk of making the Earth uninhabitable; bootstrapping poses a risk of destroying the self-sufficient Mars colony Elon Musk will probably get built

<xentrac>well, more accurately, failing to bootstrap is what poses the risk

<oriansj>actually it is far simpler than one would expect: 1) add a clause into the climate agreement to allow the planting of trees to be counted as a carbon offset 2) build 3 platforms to extract Carbonic acid from sea water (US Navy already did the research and it works amazingly) and power them via Fission 3) Sell Carbon Neutral fuel at a profit 4) Reinvest that profit to expand operations

<oriansj>hell 1Million People investing $2K is all that it takes

<xentrac>how could you solve global warming with only 2 billion dollars?

<oriansj>see post above for the high level sketch

<xentrac>I think right now it's about a 5 trillion dollar problem, but hopefully improved technology will reduce the size of the problem

<xentrac>post?

<oriansj> http://logs.guix.gnu.org/bootstrappable/2019-11-20.log#033753

<xentrac>(1) might be beneficial or not, depending on how it worked

<xentrac>like, would it just be a giveaway to Weyerhaeuser?

<oriansj>CO2 in atomosphere naturally must be in equilibrium with the carbonic acid level in the oceans; so by pulling carbonic acid out of the ocean, CO2 in atomosphere must be absorbed by the ocean itself. Thus lowering atomospheric CO2

<xentrac>sure, (2) is a reasonable approach but I'm not sure what the constants are

<oriansj>as it is very energy efficient to extract carbonic acid from sea water; it has huge EROI potenial

<xentrac>how energy efficient is it?

<oriansj> http://www.nrl.navy.mil/media/news-releases/2014/scale-model-wwii-craft-takes-flight-with-fuel-from-the-sea-concept efficient enough to be cheaper than sending Super tankers

<oriansj>The problem is the initial capital investment and the time to returns ($2 Billion and no returns for 60 years)

<oriansj>after which you now have the ability to manufactor hydrocarbons cheaper than any Drilling location on Earth and a financial reason to keep atomospheric CO2 low and store most of the extract to ensure a higher profit margin

<oriansj>(while keeping competition from arising because lower CO2 levels mean more expensive per Ton of carbonic acid extract)

<oriansj>or if one wanted to go the solar route; Australia's outback and massive concentrating Solar could get the cost per GigaWatt required to be viable but that would cost more and take longer

<xentrac>60 years?

<xentrac>404

<xentrac> http://archive.is/j2nm5

<xentrac>this press release doesn't seem to link to a research paper and also doesn't say what the energy input of the process is

<xentrac>maybe https://www.sciencedirect.com/science/article/pii/S0959652617321881 is a paper from the project

<xentrac>yeah, it does seem to be

<xentrac>it cites "Willauer et al, 2012"

<xentrac>that's presumably Heather Willauer

<xentrac>they seem to be using numbers of 56-57 MJ electrical energy input from PV per liter of fuel produced in this paper

<xentrac>this paper is proposing a half-billion dollar project on Diego Garcia as a pilot of this method

<xentrac>no wait. a 2.5 billion dollar project

<xentrac>no, a 3.35 billion dollar project

<xentrac>they're proposing to use Fischer-Tropsch to produce the fuel proper

<xentrac>they also considered using floating nuclear reactors to produce the fuel, but estimated that this would produce fuel that cost US$8.67 per gallon, which sounds expensive to me

<xentrac>which came from "Willauer et al., 2015"

<xentrac>Willauer et al. 2012 is https://apps.dtic.mil/dtic/tr/fulltext/u2/a539765.pdf

<xentrac>NRL/MR/6180--10-9300

<xentrac>which is actually from 2010

<xentrac>"During the OTEC process dissolved carbon dioxide (CO2) in ocean water is liberated as a gas."

<xentrac>oh, but only 2-3% of it

<xentrac>on p. 9 it mentions that naval nuclear reactors cost US$1.20 per watt

<xentrac>I've gone through the whole paper and nowhere does it give any kind of estimate of the energy or capital cost of separating CO₂ from seawater

<xentrac>which is, you know, the critical parameter determining how much it costs to put global warming into reverse. converting some fraction of it to fuel may be profitable but that fraction doesn't count

<xentrac>Willauer et al., 2015 is https://www.sciencedirect.com/science/article/pii/S0301421515000695

<xentrac>it says that nuclear reactors probably cost between US$1.20 and US$7.00 per watt

<xentrac>more detail in https://defensesystems.com/articles/2016/06/08/nrl-e-cem-seawater-into-fuel.aspx

<xentrac>still no energy consumption yet

<xentrac>"Using novel and proprietary NRL electrolytic cation exchange modules (E-CEM), up to 92% of CO2 both dissolved and bound can be removed from seawater" https://www.nrl.navy.mil/mstd/branches/6300.2/alternative-fuels

<xentrac>maybe https://pubs.acs.org/doi/abs/10.1021/ie502128x

<xentrac>"there is no energy or economic penalty to extract CO₂ from the seawater matrix, above the energy needed to produce hydrogen."

<xentrac>they remove the CO₂ that's acidifying the seawater by... acidifying the seawater further, electrolytically

<xentrac>from pH 8 to pH 6. by electrolytically producing hydrochloric acid

<xentrac>although the system diagram has a vacuum pump to separate the CO₂ from the acidified seawater

<xentrac>oh, but they recombine the acidified seawater with the lye solution that is also produced, returning it to its normal pH, before discharging it

<xentrac>so it isn't actually the same as dumping hydrochloric acid into the ocean

<xentrac>they had trouble with electrolytic mineral deposition inside their prototype cell but they think they've solved that by switching the polarity every hour or so

<xentrac>they didn't actually build the system with the vacuum degassing pumps

<xentrac>they just think they might be necessary

<xentrac>oh, they did prototype that

<xentrac>so they were getting 49 kWh/m³ H₂ from their prototype CO₂ recovery system, at a 3:1 H₂:CO₂ ratio, which is a pretty inefficient way to make H₂

<xentrac>they hope they can improve the efficiency in the future

<xentrac>because yeah that's like 70 grams of hydrogen, not very efficient

<xentrac>my conclusion is that this is a design that might work but it's still in very early prototype stages; it's not something you want to bet $2 billion on just yet

<xentrac>well maybe $2 billion Zimbabwean dollars

<xentrac>but it's almost certain that there are more efficient ways to capture CO₂ than this

<xentrac>because this approach pays a lot of energy to extract H₂, which is a really sensible thing to do if you want to Fischer–Tropsch it into J5 for your naval fleet

<xentrac>but probably not optimal if your objective is to stop global warming

<xentrac>because doing it this way would still be a multi-trillion-dollar expense

*fosslinux is getting a segmentation fault from mes-mw

<fosslinux>mes-m2 from wip-m2 branch on mes

<oriansj>xentrac: well electrical production of fuel is always more expensive than thermal.

<xentrac>oriansj: oh?

<vagrantc>janneke: apparently mes embeds the path to BASH, making it unreproducible in Debian: https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/mes.html

<vagrantc>looks like configure has some logic to set the SHELL variable to a resolved path for BASH?

<janneke>vagrantc: 'doh

<janneke>vagrantc: thanks, i will look into it!

<vagrantc>this might be a case where debian just needs to patch a hard-coded path to /bin/bash

<janneke>vagrantc: yeah or possibly i only need "bash"; i don't have time to look right now :)

<vagrantc>i'll fix it in debian and nudge you upstream later

*stikonas is making gentoo overlay to bootstrap java from gcc. Might be able to test if there is a slightly shorter bootstrap path

<vagrantc>janneke: are both configure.sh and configure used in mes?

<vagrantc>janneke: they seem like parallel implementations...

<janneke>vagrantc: yes, unfortunately they are parallel

<janneke>currently, configure.sh is used in a bootstrap build, ./configure for a developer build

<janneke>vagrantc: now that gash can execute autoconf configure scripts I will probably re-attempt to move to autotools and drop ./configure.sh

<janneke>when we move to the full source bootstrap where m2-planet builds mes, we can probably drop the parallel build.sh and bootstrap.sh too

<janneke>it's all a bit of a dance with possibilities :)

<vagrantc>ah, the debian package is currently building with ./configure

<vagrantc>i *think* anyways

<vagrantc>yup, confirmed

<janneke>yes, that's the idea

<vagrantc>would it be feasible to backport the arm/aarch64 patches to 0.20 ?

<janneke>i wrote configure in scheme, partly as an experiment and partly because it can be executed by mes

<vagrantc>or should i just wait till they land upstream?

<janneke>arm: i don't know, backporting should not be too much work

<janneke>dannym (not too frequently here) is really championing that effort

<janneke>i expect him to finish it some time "soon"

<vagrantc>cool, just wondering if i can get more green on https://buildd.debian.org/status/package.php?p=mes&suite=experimental :)

<vagrantc>by building for debian, we get a wide variety of architectures that attempt builds

<vagrantc>i suppose i should subscribe to bug-mes and carry on some of these questions there :)

<janneke>vagrantc: yes, that should work to reach dannym

<janneke>oh yeah, that page looks nice but the results are somewhat sad

<vagrantc>it's a young project with some very unusual constraints :)

<janneke>so i've heard :)

<oriansj>janneke: you can pull the bootstrap scripts from mes; mes-m2 will be caring that exclusively

<janneke>oriansj: yes, i will keep that in mind

<vagrantc>ok, i've got a working patch that just hard-codes /bin/bash, which is more-or-less correct for Debian

<vagrantc>for the curious https://salsa.debian.org/debian/mes/blob/debian/master/debian/patches/force-use-of-bin-bash