log☇︎
9 entries in 0.592s
asciilifeform: sbcl is a pretty interesting example of one of those spiked pits, like e.g. gcc -- items to which there is no practical alternative except 'throw away the comp and build log cabin'. but asciilifeform does not have phf's deep historical view of sbcl/cmucl ; asciilifeform arrived into the spiked pit directly
a111: Logged on 2016-09-17 02:43 adlai: this is funny: https://www.cons.org/cmucl/cmucl-build/00_README but this is funnier: https://www.cons.org/cmucl/doc/crosscompile.html
a111: 5 results for "cmucl build", http://btcbase.org/log-search?q=cmucl%20build
asciilifeform: !#s cmucl build
phf: well, you were right, it's the lack of threads. you can't build for cmucl green threads like it's native.
asciilifeform: phf: would you say that cmucl is more suited for 'iron' incarnation? (i.e., can it be build without gcc?)
adlai: this is funny: https://www.cons.org/cmucl/cmucl-build/00_README but this is funnier: https://www.cons.org/cmucl/doc/crosscompile.html ☟︎
phf: you only say that because you think sbcl is somehow "clean". chrodes managed a very neat hack, a build system improvement, that's where neat hacks have ended, and modernization began, but it's not like the legacy cmucl codebase somehow disappeared from sbcl
phf: yeah, i'm leaning that way myself, but i'm not fully convinced yet. i'm for example trying to build sufficient knowledge of cmucl right now, to be able to take full responsibility for the behavior of my deployed system, and it's a ~slow process~. it's handy to have paid professionals assist you