freenode/#lisp - IRC Chatlog
Search
17:58:22
fraktor
I'm pretty new to lisp, and I've been trying to learn using SBCL. Is there a (relatively easy) way to make a mostly-portable executable out of lisp code?
18:00:13
aeth
fraktor: Usually you keep one session running, often in an IDE like in SLIME on top of Emacs. Then you launch everything from that session.
18:00:46
aeth
Obviously if you're going to e.g. distribute a desktop application then you'd need to build a standalone executable, though.
18:01:26
HighMemoryDaemon
fraktor: There's also Chicken. It's a Scheme, produces C code, and creates an executable from that. https://call-cc.org/
18:02:18
aeth
Even if you're running a server in production, though, I'd personally assume you'd be running it from the REPL. Standalone executables (afaik) ship the entire implementation so that's for if you don't assume one is already installed.
18:03:59
Bike
pfdietz: guessing at likelihood of delivering something to someone else basedon "I'm pretty new"
18:07:08
fraktor
I would like to be able to distribute programs to other users without making them install sbcl.
18:07:55
Bike
sometimes we get people in here who expect a compile-run cycle like with gcc, and that doesn't work, is all
18:09:45
fraktor
Bike: That's certainly what I'm used to. I've used REPLs for other languages, but not usually with a running program.
18:10:09
pfdietz
If you want to deliver a command line program, you will have some lisp function that gets called on program invocation. You can call this function (or one that it calls after argv parsing) when running your program from the REPL, as you would likely be doing during development.
18:11:27
pjb
Popularisation of Lisp will have to pass thru linux distribution of widely _USED_ lisp software, compiled with a toolset simiar to that of gcc.
18:11:38
aeth
it would look something like this in SBCL: sbcl --noinform --non-interactive --load foo.lisp --eval "(foo:main)"
18:12:09
aeth
foo is the package name and must be included, and main is just a convention so people know where to look for a function like this
18:12:17
pjb
Only once people will notice that several of their unavoidable tools are written in CL, will they start to be interested by and use Common Lisp.
18:12:25
aeth
I probably should have said foobar.lisp to emphasize that the filename and the package name can be different
18:21:51
aeth
pjb: Does your program allow certain implementation-specific flags to be set? e.g. sb-ext:*derive-function-types*
18:38:40
pjb
aeth: I try to avoid writing implementation dependent programs. This driver uses clisp. It would have to be rewritten using portability libraries…
18:54:33
jcowan
FWIW, ten Schemes deliver standalone executables, 8 by compiling to C and 2 by clever packaging of their regular runtimes.
18:58:26
gendl
LispWorks can deliver a "console image" at least as a single file (and probably a full-blown application although I don't have enough experience with LW).
18:58:36
jcowan
Quoth CLiki page: "Another form of disk image requires a copy of the particular Lisp implementation to be installed on the recipient's machine."
18:58:53
pjb
Well, this is FreeNode. We don't know any specifics of Commercial implementations. Only some echoes.
19:00:43
jcowan
pjb: No, obviously not. I said that at least one could do so in the past, which is true. I was not claiming any superiority of Scheme here, merely offering facts.
19:01:36
pjb
jcowan: you're offering wrong facts. Most implementations can deliver stand alone executables. You would have to spend half an hour researching implementations to find a strange one that cannot.
19:01:50
fe[nl]ix
jcowan: that sentence doesn't say that the the implementation requires that, but only that the particular form of disk image does
19:02:10
younder
Snap packaging can round all dependencies up in a nicke packet so you are less dependent on that on file problem. (look up SNAP)
19:02:30
fe[nl]ix
jcowan: in other words, that there are images that are disjoint from the CL runtime that is required to start the image
19:04:06
gendl
jcowan: but statements like "at least one CL has done so in the past" are vague and misleading.
19:04:33
gendl
I do think this is more of a problem with outdated content cluttering up Cliki than a problem with any actual reality.
19:05:49
jcowan
gendl: I grant that my remark was misleading, as obviously several people have been misled by it.
19:08:07
jcowan
I would be interested to know if there are any implementations today that can generate {C,JavaScript,whatever}.
19:09:41
shka_
jcowan: not sure about that, but from what i understand it goes directly into bytecode
19:10:35
jcowan
Yes, that's what I would expect. It's on the whole easier to generate bytecode than Java.
19:10:35
phoe
How do I make postmodern output timestamps as non-integers? I need higher resolution than integers.
19:10:36
minion
phoe, memo from shka_: czy mógłbyś mi dać znać czy masz jakiś problem z treścią mojego nowego posta? Chcę opublikować w tą sobotę (dopiszę tylko kod demonstrujący)
19:11:01
phoe
Loading simple-date after loading postmodern doesn't change anything, (postmodern:query "SELECT now();") ;=> ((3748964957))
19:11:54
jcowan
whereas it is on the whole harder to generate machine code than C, and it is subject to possible obsolescence issues
19:12:06
shka_
phoe: first of, you have to ensure that correct column type is set up in the postmodern
19:13:24
phoe
shka_: the examples at https://sites.google.com/site/sabraonthehill/postmodern-examples/postmodern-time-functions don't say anything about column types.
19:21:35
phoe
I found a system called :cl-postgres+local-time but loading it doesn't change anything
20:11:26
younder
Do any of you have any experience with template Haskell. Is so how do they compare to CL macro's.
20:12:56
jasom
younder: as most non-lisp metaprogramming there is extra overhead of having to learn a second language, as the AST of haskell is a very different representation than haskell is usually programmed in.
20:14:50
oni-on-ion
i'd say the type system of haskell is much more powerful and closer to macro than TH.
20:18:51
oni-on-ion
prolog i set right next to lisp for macro, not sure about scheme and hygenia, but julia right below it because im still a newbie with it
20:22:36
jasom
hmm; python lets you manipualte the AST, but I don't know that it makes it homoiconic; we may be getting OT at this point going too-far down the Julia path
20:22:45
oni-on-ion
although there is one thing, if you have a macro 'john' and want to call it, @john is how. i forget the reasoning behind this but i think it is just syntax sugar. not sure where CL stores its own macros; in the function slot ?
20:23:55
jasom
In a homoiconic language, the primary representation of programs is also a data structure in a primitive type of the language itself. <-- obviously this doesn't just mean AST, otherwise all self-hosting languagese would be homoiconic (assuming the compiler or interpreter parses to an AST at some point)
20:26:19
oni-on-ion
i am really not sure about julia macros. have to play with it more, the manual is too dry
20:26:27
jasom
oni-on-ion: all lisps can use symbols for many things; lisp-1 v lisp-2 is just a question of if the function-call position is separate from the value
20:28:14
jasom
lisp-1 v lisp-2 is a question of (X X) <- does X represent the same thing when this is evaluated.
20:29:49
oni-on-ion
that is the second thing i like about scheme. which julia was written in (chez) but anyhow, homoiconicity to me is extremely important for 'real' macros. and to 'flip the switch' with quote/unquote
20:31:08
jasom
and of course if you make a hash table that is keyed with symbols, you've added a new namespace.
20:31:29
oni-on-ion
jasom: and also very important for the ability for anaphoric macros =) as nickname reminds me
20:32:21
oni-on-ion
change package, change namespace. wouldnt that count for 'how many namespaces' there are
20:33:25
anamorphic
From page 836 (apparently, I don't have my copy in front of me) of PAIP he says Common Lisp has 7 namespaces
20:33:29
jasom
oni-on-ion: that's because symbols are string-designators, and defpackage/in-package take string designators
20:36:48
jasom
oni-on-ion: don't forget that symbols are upcased so you need to do e.g. (in-package "CL-USER")
20:38:14
jasom
oni-on-ion: if packages were named as symbols, you might see code written like this https://github.com/jasom/spm-reader/blob/master/spm-example.lisp (I wrote a proof-of-concept reader macro that uses symbols to name packages, with the keyword package being the root namespace)
20:39:30
oni-on-ion
whoa that is trippy, is this file copied twice ? if i page up/down in emacs it looks the same.
20:40:15
oni-on-ion
i see 4 of the same thing, my dyslexia is acting up and im starting to see moire patterns
20:40:44
jasom
oh, the first line of each are: json:encode, clj:encode-json, :yason:encode, :cl-json:encode-json
20:43:19
_death
I think he wants a macro to "abstract" the 4 forms.. not realizing it would serve no purpose but obfuscation
20:44:52
aeth
oni-on-ion, jasom, etc.: You can't do "FOO-BAR" and be fully portable. If you use literal strings you have to generate them at read time with #.(symbol-name '#:foo-bar) to get "FOO-BAR"
20:47:23
_death
aeth: someone who changes the readtable case and expects things to work is deluding himself
20:48:11
aeth
_death: As long as the readtable case doesn't change *multiple* times during the execution of the program #.(symbol-name '#:foo-bar) will work.
20:49:42
jasom
aeth: if the readtable case has been changed, then #.(symbol-name '#:cl-user) will not work.
20:49:49
aeth
oni-on-ion: I use it everywhere in my code, e.g. if I wanted to prefix foo- in a macro I would use #.(symbol-name '#:foo-)
20:50:02
jasom
if it's e.g. case-preserving then it will look for "cl-user" which is not required to exist, while "CL-USER" *is* required to exist.
20:50:41
jasom
I'm fine with #. for such short uses, but in this case it's flat out worse than using a string, as a string will always be right.
20:52:13
jasom
also (in-package #.(symbol-name '#:foo)) is going to be identical to (in-package '#:foo) since there is an implicit call to symbol-name (probably via cl:string) in the in-package macro
20:52:31
aeth
_death: There are two acceptable uses for #. imo. symbol-name (like above) and to get a constant number in an unquoted type specifier like (let ((bar 42)) (check-type bar (integer 0 #.(isqrt most-positive-fixnum))) bar)
20:53:15
_death
aeth: in most-positive-fixnum that may work.. in your own constants that may not depending on when you define them
20:54:06
aeth
_death: Just wrap the constant in eval-when and that fixes it, at least for CCL, which does complain about such things. But almost all of the time it will be something like most-positive-fixnum
20:54:17
oni-on-ion
shift 3 dot shift 9 symbol-name quote shift 3 shift semicolon foo shift 0 shift 0 ..... thats a lot of dang-ed typing !!
20:55:55
aeth
_death: something like this: (defun fixnum-square (number) (check-type number (integer 0 #.(isqrt most-positive-fixnum))) (expt number 2))
20:56:22
jasom
aeth: I'm also trying to figure out why you are using #. for the symbol-name; symbol-name 'foo will never change since foo is read in once; is it just an optimization?
20:59:40
aeth
jasom: I've been doing this for a while now but I believe that the reasoning was to get the performance of "FOO" but with more reliability. I don't think it would make a difference in SBCL, though.
20:59:58
aeth
At the very least SBCL seems to turn (defun foo () (symbol-name '#:bar)) into a function that constantly returns "BAR"
21:05:41
aeth
Why specify a boundary? All that's required is to prove to the compiler that is remains a fixnum so the arithmetic stays inline. The actual bounds are your memory and patience.
21:06:01
aeth
It would be impossible to leave fixnum with that algorithm, though, because you would certainly run out of memory.
21:09:15
younder
The marshaling and representation stands the potential of being a major bottleneck.
21:15:04
aeth
No, what I actually care about is generating the primes as quickly as possible. I would rather have every implementation generate as many as it is capable of doing efficiently than artificially limit 64-bit SBCL or create a misleadingly high bound for the rest.
21:15:55
aeth
I can use fixnum, I can create something that is efficiently only in 64-bit SBCL, or I can artifically limit what 64-bit SBCL is capable of doing. (This is the case because 64-bit SBCL has the largest fixnum.)
21:16:02
_death
but, if you have an array of things, then you don't care about fixnum, but a subtype of it
21:19:39
aeth
Don't run a high-performance prime sieve on a 16-bit CL with the standards-specified 16-bit-friendly absolute minimums for everything, then.
21:22:00
aeth
If you use double-floats in a computationally intensive way, CLISP exists to make your life hell.
21:25:07
aeth
In general, though, in my personal experiences, code involving numbers will run almost instantly in SBCL, may run almost as fast in SBCL or have unexpected slowdowns in CCL, will sometimes be much slower in ECL, and will usually be basically unusable in CLISP.