freenode/#lisp - IRC Chatlog
Search
13:17:15
xificurC
(read (process-output (sb-ext:run-program "/bin/sh" '("-c" "export-lisp") :output :stream))) is there something inherently wrong with such code? It keeps hanging in some cases even though the internal program always finishes when running from the shell directly
13:20:50
flip214
but the process will block if the pipe is too small to hold all the output at once.
13:21:38
flip214
use UIOP:launch-program (or use :wait nil), read the stream, and then explicitly let it stop (== read the return code)
13:25:42
xificurC
flip214: ah, I tried :wait nil and then (read (process-output process)) (process-close process) but forgot to return the read value... That works. uiop:run-program worked too so I knew it must be something me doing wrong
14:33:50
HighMemoryDaemon
Caveman uses a syntax feature of Lisp I have not seen before. Ex. '@route GET "/"' - What is this syntax feature called?
14:35:11
random-nick
HighMemoryDaemon: reader macros work by telling the reader to call a function when encountering a certain character on the beginning of an expression
14:36:29
random-nick
the simplest reader macro is probably quote ('), which reads the following expression and returns it wrapped in a (quote ...) form
14:39:07
antoszka
You can use reader macros to quite trivially create, say, a literal syntax for hashes.
14:39:35
HighMemoryDaemon
That is very cool. Not saying that it is worth doing at all, but using these macros, couldn't you do something like re-make the entire Python or Ruby programming languages..within Lisp?
14:44:04
HighMemoryDaemon
Well, that's me. I wouldn't have a need to use it but it's just cool that it's possible.
14:45:57
specbot
Standard Macro Characters: http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
14:48:21
beach
shka: Hello. Very well thank you. I had some very good ideas today. How about yourself?
16:46:34
beach
What is a good way for a Common Lisp implementation to distinguish between a source file and a FASL file when loading?
16:49:13
jasom
beach: what do you mean? Like having a magic number at the beginning of all FASL files?
16:51:53
jasom
I mean if someone starts their source file like ".. I AM A FASL AND I'M NOT LYING" then they deserve what they get :P
17:53:11
jasom
beach: I assume you saw https://blog.golang.org/ismmkeynote ? Of note is that they found the write-barriers to hurt throughput more than generational collection helped on programs with small heaps. They attribute some of this to good escape analysis in the compiler. They show typical pauses of 500us on an 18GB heap which is pretty good, though it sounds like heavy allocators can get starved for longer.
17:56:07
beach
I can't read it today because I am off to spend time with my (admittedly small) family, but I'll look at it tomorrow.
19:48:28
skidd0
so say i have a lisp package that does some cool thing. on SBCL i can (sb-ext:save0lisp-and-die ..) to create a binary and handle command line args [with unix-opts]. If I want to share that program, will each user need to install sbcl and then run the save-lisp-and-die stuff? Is there an easier way to share the binary?
19:49:03
skidd0
I haven't ever made a program to be distributed before, so please be understanding of any ignorance
19:54:57
skidd0
but (again, i'm ignorant and ill-informed here), that binary is only good for other 64bit Arch distros?
19:55:27
skidd0
so i'd have probably want to save-lisp-and-die on a Windows and a Mac, and provide build instructions for linux?
19:58:48
dim
the binary depends on the platform, much like a binary compiled with a C compiler does, you can build a binary per platform (architecture) and have users download it, and save-lisp-and-die is a good way to do that
19:59:24
dim
for instance I use that in the pgloader build system and we package the resulting binary for debian, debian users then apt-get install pgloader and it works for them, they don't even have to know the software is written in CL
19:59:46
dim
there's also a wrapper in uiop (that comes with asdf) that provides a portable facility around save-lisp-and-die
20:00:12
dim
(setf uiop::*image-entry-point* #'appdev::main) (uiop:dump-image *appdev-bin* :executable t #+sbcl :compression #+sbcl t)
20:00:53
dim
it might be that the binary that debian hosts would work on CentOS, but I don't know about that, really
20:03:55
dim
education is more about culture than practical craftmanship, in my opinion... see, you knew how to ask the right questions
20:03:57
dlowe
architecture covers "can this my code execute?" (i.e. CPU) and "does this use the same hardware access protocol that my code expects" (i.e. OS)
20:30:54
HighMemoryDaemon
Can I pass one variable to "format" and do replacements in multiple places?
20:40:44
jasom
windows is actually much easier than linux for this because if you depend on any DLLs you can just put them in the same directory (as that is in the default DLL search path)
20:43:54
jasom
as far as linux portability... the linux kernel has a very stable API, *but* the runtime will invariably depend on some dynamically linked shared objects, and possibly some dynamically loaded shared objects as well. This can pin executables to a very narrow set distributions (and a narrow set of versions within the distribution).
20:47:03
aeth
jasom: That's nonsense. In practice, if you get a Linux application outside of a distro (or third party repositories that are intended for a certain distro) you're not going to depend on the distro's libraries.
20:47:27
aeth
And such applications from 15 years ago can still run even if you don't recompile them.
20:48:10
jasom
Applications from 15 years ago will almost certainly not run due to glibc changes if nothing else.
20:49:10
jasom
oh, you are talking about applications with bundled libraries (or statically linked libraries)?
20:49:18
aeth
A properly written third party application that is neither source distributed nor distributed via a third party repository will bundle everything.
20:50:37
jasom
most binary applications I've seen assume $TODAYS_POPULAR_LINUX_DISTRO e.g. Ubuntu today, redhat a while back.
20:52:17
aeth
Well, the ones that assume Ubuntu are probably increasingly using Snappy, whose only problem is that it's an Ubuntu-first NIH reinvention of something that exists not once but twice: AppImage and Flatpak.
20:54:36
aeth
jasom: Anyway, I think the vast majority of proprietary software written for Linux at this point are Steam games that are written for the Steam for Linux runtime (or whatever it's called).