IRC channel logs

<jackdk>Catching up on scrollback. It's a shame that Yale Haskell is written in a non-standard lisp, but I think we do have a bootstrap for at least SBCL: when I asked my nixos for it with substituters disabled it build ecl from source and then used that to bootstrap sbcl

<Googulator>jackdk: it's standard, specifically Common Lisp

<Googulator>but as soon as you want to compile native binaries using a Common Lisp program, you start to depend on implementation details

<Googulator>SBCL and Clisp are bootstrappable, yes

<Googulator>well, Clisp doesn't even need to be bootstrapped, since it's not self-hosting, but written in C

<Googulator>It's unclear if Yale Haskell ever worked on Clisp - it certainly doesn't run on modern Clisp

<Googulator>interestingly, Yale Haskell 2.x wasn't directly written in Clisp, but rather on top of a Lisp dialect then called "T", with a T-to-Common-Lisp compatibility layer below it

<Googulator>Shortly after Yale Haskell's development was seemingly stopped, T would morph into what's known as Scheme today

<Googulator>but the Yale Haskell dialect of T is different enough from any modern Scheme that ripping out the compatibility layer and running the rest on Guile is not trivial either

<Googulator>For Haskell, besides Pandoc, there's also xmonad

<Googulator>and darcs, which would be important to bootstrap for archiving source code stored in that format

<Googulator>plus, Haskell is probably the best known lazy language today - AFAIK no lazy functional language has been bootstrapped so far

<Googulator>many other languages derive their laziness from an implementation written in Haskell (in lambda calculus-like languages, lazy or eager evaluation propagates from compiler to compiler; the same source code, compiled with a lazy compiler yields another lazy compiler, while an eager compiler would make the output also eager)

<aggi>Googulator: with pandoc i am not aware of an alternative to it

<aggi>although it's not necessary to bootstrap haskell to compile pandoc

<aggi>reminds me of another issue with TeX, which was non-trivial to salvage at least one capable implementation for that was written in C (and is portable with tinycc)

<aggi>finally i settled with some TeTeX from year 2006

<aggi>in common pandoc and TeTeX have, they're both relevant to scientific authoring utilities at stake

<aggi>same with ghostscript, that i had to rollback to some ancient version (when testing the static compile/linking with tinycc)

<aggi>gnuplot and texlive didn't cause notable problems

<aggi>and well, some pdf/ps-viewer for framebuffer terminal, that could be compiled/linked statically with tcc, soaked another week or two

<aggi>finally i managed somehow to retain that (which was non-trivial when tightening acceptance criteria as mentioned)

<aggi>for long-term stability of crucial free software components written in C, if you will

<aggi>xentrac: i didn't mean to discourage anyone either

<aggi>it's just nowadays developers tend to think it's ok and no problem at all if basic components pull in hundreds of millions of lines of code (often C++ and a dozen other)

<aggi>which didn't at least remain portable with a GNU/ANSI C compliant c-toolchain

<stikonas>not sure if there are lots of repos left in darcs format...

<stikonas>probably most of them were imported into mercurial or git by now

<aggi>pandoc may not be necessary if scientific documents are authored and/or exported into TeX or markdown

<aggi>i stumbled upon pandoc once, when trying to convert LibreOffice though

<aggi>meanwhile, various free/open initiatives in public government offices place their bets on LibreOffice

<aggi>pandoc may extract/convert various other document formats, didn't check all of which of those could be relevant to free software

<aggi>i don't recall in detail anymore, why i finally removed pandoc and haskell from the tcc-driven system profile

<aggi>maybe it's just been the fact another 500 ebuilds did need regular maintenance and patching already, to confirm cross-compile/static-linking with all those

<aggi>and no more time for haskell (and there's no other distribution or maintainer who ever bothered with tcc-toolchain verification, static linking and full cross-compilation of _all_ software)

<aggi>and there's no incentive to get on board development man power for this

<aggi>i didn't succed with any contracting, cooperation nor anything; i doubt anyone else could

<aggi>even when presenting those concerns to various universities, nothing but ignorance

<aggi>the situation surrounding TeX, i mean, i couldn't care less, i doubt i'll ever author another scientific paper myself again

<aggi>yet which TeX distribution would you throw at students (knowing it's portable and long-term stable)?

<aggi>bootstrapping criteria for TeX and document formats are different though, in essence it's not bootstrapping if you will

<aggi>so i summed up the reasoning to portability with a vendor-neutral C-toolchain

<aggi>which disclosed many problems without remorse, good luck compiling any ghostscript with tcc or any other like it

<aggi>of cause, you might pull in c++ dependencies, that's no problem

<aggi>the problem is you couldn't yield a capable TeX nowadays _without_ c++ when desired

<aggi>and with it another 100millions lines of code

<aggi>for a while i too compiled entire LibreOffice from source (gentoo)

<aggi>which then intersected with gcc-versions necessary, and c++ feature regressions

<aggi>to give you an idea which trouble awaits to keep that long-term stable (from a developer/system-integrator perspective too)

<aggi>then i decided to roll-back to gcc-4.7, as a baseline, then had to backtrack to any LibreOffice version...

<aggi>at that point, i decided to remove that once and for all

IRC channel logs

2026-09-18.log