libera/#commonlisp - IRC Chatlog
Search
4:49:44
asarch
Ok. You get a new job and in the company's server there is no any Lisp (CLisp, SBCL, etc) at all. How would you compile the source code of SBCL in that situation?
4:51:07
asarch
Is there a way to do a cross-compile for the kernel? (Maybe you at your home with your PC...)?
4:53:08
moon-child
beach: cross compiling and installing a binary don't seem mutually exclusive to me. Any binary you install will have been compiled at some point; maybe by a cross compiler, maybe by a native one
4:58:49
moon-child
pjb: sbcl can be bootstrapped; I seem to recall hearing (maybe from beach?) that lispworks and allegro cannot be meaningfully bootstrapped in such a fashion. Which does make it an interesting question (if not a practical one, since lw and acl are not open source)
5:00:07
asarch
I mean, the image not the kernel (From Common Lisp Recipes, 16. Developing and Debugging: The main idea of developing in C OMMON L ISP is that the whole system is one “image” that you continuously modify until it fits your needs.)
5:00:13
moon-child
yeah, from the els paper: 'Rhodes claims that Allegro, Lispworks, [...] are only possible to build using older versions of the same system, and only using image-based techniques'
5:01:28
moon-child
asarch: many lisp compilers have the ability to save the in-memory image to a standalone binary. This is what sb-ext:save-lisp-and-die does in sbcl, for instance
5:13:56
beach
moon-child: The scenario asarch describes doesn't seem to involve generating an executable file for a new architecture. It sounds to me like asarch just needs a Common Lisp system on a machine that currently has none installed.
5:14:32
beach
If the scenario is that there are no binaries available for the particular architecture of that server, then the problem is greater, of course.
5:16:05
beach
asarch: An image contains instructions for a particular processor and a particular operating system (for system calls etc). That's why it is not cross platform.
5:18:15
beach
asarch: Or, perhaps you are just interested in how the SBCL maintainers generate those binaries the first time?
5:22:28
asarch
(I was planning to build an image from my Debian 10 Buster for AMD64 to use it with CL-REPL on my Android-based cellphone)
5:23:49
beach
asarch: An executable file is just a sequence of bytes, so you can create it on any operating system using any language.
5:24:15
beach
asarch: You just have to instruct the cross compiler about the architecture you are building for.
5:28:11
moon-child
webassembly is a particular architecture that can be targeted as easily as any other
5:28:23
moon-child
(though I don't know of any extant common lisp compilers targeting it; one would have to be written)
5:32:08
moon-child
as I recall, some sbcl developers attempted to influence the design of webassembly to make it more amenable to running lisp (something to do with multiple values, maybe?), but their input was not heeded
5:51:44
asarch
The good news is that the new Linux distro, Windows 11, will support Android apps out of the box (they say) so you could use CL-REPL with no problem at all
6:46:32
pjb
asarch: the CL language doesn't really impose image-based development. It's not even offering any guarantee to help supporting it. (eg. no source (sexp) tracking utility, function-lambda-expression and documentation can return NIL at any time, etc). Even writing the required tools would require to go metalinguistic (have a look at ibcl). But foremost, ecl. (ecl is not image based, its compiler produces elf object files).
8:59:13
lotuseater
Hi beach nice that you're writing. :) Don't worry I have no silly questions atm. ^^
9:18:55
lotuseater
I thought about constructing a LET-like macro named ILET for defining lexical immutable symbols by looking at the macro body if there are none of '(DECF INCF SETQ SETF) in the body paired with the symbol name. okay actually I did that some weeks ago
9:20:49
lotuseater
Was about two years ago around 2 months I stumbled into the CL world that i wrote a macro HLET* where it wasn't needed that the dependent symbols are given in linear order. It looked for references of symbols and sorted this topologically and that worked. :)
9:26:24
beach
lotuseater: You could have (let ((x ...)) (f x)) where F is a macro that expands to (setf x ...).
9:33:33
moon-child
lotuseater: and on the topic of macros, it's possible that a macro expansion could generate code like (when nil (setf x ...)), which _is_ ok, but which it's not possible in the general case to reject statically
9:35:59
moon-child
if you would like a high-quality conservative implementation of immutability, haskell is probably a better choice than cl
9:39:37
lotuseater
oh damn, the Halting Problem o_O so wait to when quantum computers ship out in hobby editions
9:40:45
beach
As I recall, quantum computing doesn't pretend any additional computational power over Turning machines.
9:41:22
lotuseater
yes static typing locks one out I learned, not even in prototyping, but could of course by powerful with a good mathematical based type system (so there is no void type)
9:42:51
moon-child
yes; quantum computers are algorithmically faster than traditional computers at certain, but there's nothing they _can_ do that an ordinary turing machine can't
9:43:14
moon-child
and the strong form of the church-turing hypothesis says that hypercomputation can't be realised
9:46:38
kakuhen
i come from a mathematics background so i'm not too acquainted with the wisdom in computer stuff
9:47:27
moon-child
kakuhen: I'm going to bed now, so not going to stick around and chat, but: it devolves into dynamic typing
9:49:21
lotuseater
are there also some video conferences the next weeks? I saw videos from the Common Lisp study group, they do much topics of interests.
13:14:54
_death
it uses sbcl internals, which have changed.. so you can (i) work to fix it (ii) switch to a different library (maybe one that doesn't make use of FFI)
13:54:30
francogrex
Hi, for learning, I am trying to "optimize" this (and it's not high level optimization), only at the declarations level: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/pidigits-sbcl-3.html
13:57:10
francogrex
a lot of unable to do inline fixnum arithmetic, because of the integer/fixnum thing there
14:07:19
jackdaniel
sbcl tells you that if /you could/ guarantee that these integers are fixnums, then it would be able to apply a certain optimization
14:16:00
francogrex
jackdaniel: ok, i am sure i cannot guarantee that the output of the arithmetic operations will be fixnum (actually i can guarantee that they will not be :( )
14:18:07
francogrex
i though there would be a way for optimized integer operations without using fixnums
14:21:21
aeth
some notes are inherently unfixable, but you probably still want optimized code to be optimized so you can just hide the remaining notes in a LOCALLY
14:21:40
aeth
well, no, sometimes SBCL complains that the problem isn't... an easier to optimize problem
14:22:07
aeth
Especially when there's division. Like, thanks, if I was solving a different problem, it would really work out.
14:23:16
aeth
You could experiment with TYPECASE and having a fast path and a slow path, but the slow path will then always complain (unless moved to a separate function entirely)
14:37:42
aeth
That being said, depending on the problem, you could make your own "bignum" out of a fixed-size array of numbers that are all known to be of a fixed size and thus fully optimizable. Definitely doable for simpler things (especially if you just want the bits of an integer, or just want to add). Probably not doable if you want to use all of the features of a bignum (writing your own EXPT, division, etc., is