freenode/#lisp - IRC Chatlog
Search
17:42:15
beach
srandon111: Most people in your situation would not understand the essence of the examples. They would either dismiss them as solving a non-problem, or they would show how to use a non-Lisp language to get the same effect. This phenomenon has been called the "Blub paradox" by Paul Graham.
17:49:50
amerlyq
when I compile lisp to exe -- how to get exe name? I.e. analogue to <arg0> of other languages
18:18:26
Xach
amerlyq: command-line options are not standardized but there are portability libraries
19:03:36
puchacz
I found #-sbcl macro with-timeout in bordeaux-thread that creates a new guarding thread for each caller, and the guarding thread will quit only after timeout passes, no matter if the caller is over or not.
21:01:56
aeth
re "SBCL is much more at home on 64bit windows"... I wouldn't use 32-bit x86 on any CL implementation that also has x86-64, on any OS. Even if it got equal attention (and it probably doesn't) it has a lot more limitations that you don't really notice in something like C that doesn't have boxing.
23:09:33
aeth
I was thinking that a lot of elaborate macros are just very parallel things that could probably speed up compilation greatly without actually having true parallel compilation or parallel ASDF just by parallelizing those macros.
23:38:35
aeth
pjb: Technically, since threads aren't in the standard, they might be an edge case that's not supported for whatever reason
23:39:31
pjb
That's your problem. You're asking a silly question, you get a silly answer: https://pastebin.com/LWfjZ9vP
23:40:38
aeth
I was just wondering if I'd get issues with in-use implementations using BT (directly or indirectly) in macros.
23:41:18
pjb
The only problem I can see, is that since the compiler of the implementation may be using threads, you might overflow the maximum number of threads…
23:42:27
aeth
pjb: There are three different threads that might be at use... the compiler, the build system (e.g. poiu, except threaded instead of process-based), and the libraries doing fancy things with parallel functions in read/load/macro/etc. time.
23:43:10
pjb
aeth: And imagine reader macros using threads to parse strange things, and using AI to infer smart things!
23:43:50
aeth
If parallel compilers/builds/macros were more common, it might be useful to have some de facto standard so they can tell how many threads something is using
23:44:51
aeth
It looks like it should be a priority to me because we're entering a world of 8-64 core desktops.
23:45:27
aeth
And when AMD's pricing a 12-core around the price of an Intel 8-core, I'll choose 50% faster compilations over 5% faster games.
23:48:28
aeth
pjb: I'm guessing, though, that if you were really going to have a lot of parallel macros, you'd do something like lparallel does (or just use lparallel) and have a pool of worker threads created early and reused.
23:49:45
aeth
I'm sure there's something out there that would benefit greatly from parallelism, probably one that's embedding a language
23:50:08
pjb
ok, so now, find ONE program using C++ templates that you can expand in parallel in ONE lisp program!
23:50:44
aeth
pjb: well, as far as templates go, all I know about is https://github.com/markcox80/template-function/
23:51:07
pjb
Because if you had code that would justify parallelizing a macro, then you would have to rewrite it so that you wouldn't have to parallelize the macro anymore, because that code would now be generated instead.
23:51:43
pjb
In the time you fork threads and join them, you could easily process tens of thousands of accessors in my macro!
23:53:31
pjb
The code is not a parallel structure, so it's silly to try to parallelize its processing by-hand, and doing automatically will require low-level and global tools.
23:53:34
aeth
pjb: What about a macro that creates and instantiates a large, elaborate array at macro-expansion-time (which is then simply loaded later), splitting the instantiation into n threads for n regions of the array based on the available cores?
23:54:31
aeth
pjb: It's not purely theoretical, large numeric arrays could be useful for e.g. Project Euler.
23:55:24
pjb
Project Euler is purely theorical. That kind of code never occurs in real application, the ones all the users install on all their computers and renders a language popular.
23:57:07
aeth
pjb: Well, I would say computer graphics, but you can't really do fancy stuff like putting your assets into a FASL because then I don't think you can get it into OpenGL without copying, which kind of defeats the point.
23:58:09
pjb
I'm waiting you to code the lisp macro that will watch thru the camera the programmers specifing the program he wants, and generating the corresponding code…
23:59:27
aeth
pjb: plenty of programs do what the programmer says... what you want is a macro that does what the programmer *means*
4:20:40
beach
It would be interesting in an editor for Common Lisp programs or an IDE for Common Lisp to signal things like (let (x) ... (use x)) and (let ((x nil)) ... (setf x ...)), and that tells me that one should not canonicalize LET forms too early.
4:50:52
beach
And, of course, in order to avoid code duplication, it would be best if the editor/IDE would run the compiler, capture its style warnings, and alert the user.
4:54:06
beach
And I don't mean that the editor/IDE should run the compiler as a result of the user typing C-c C-c or similar, but after every keystroke.
4:56:21
LdBeth
Common Lisp is very different. For many blub languages, using compiler to do analysis is not a efficient choice