libera/#commonlisp - IRC Chatlog
Search
20:57:34
Xach
White_Flame: yeah, i guess if you want max control, different startup/config files seems plausible
21:42:58
White_Flame
Xach: I actually have a number of setup/loader functions in my .sbclrc, that I call at the repl at the beginning of an image, depending on what I'm doing
21:43:28
White_Flame
I guess because of the global nature of the load path setup, especially if it's symlink or directory location based
21:43:58
White_Flame
however, I guess the *whatever-registry* variables could be bound just for load time, but since some dependencies might auto-load components at runtime, I don't trust that
21:53:44
Bike
oh, i see. i was asking because the project i work on is a lisp compiler framework that i thought maybe you could use. but if the code is all in C that won't really work
22:28:09
rotateq
you could also try spacemacs if you're more used to vim for the editing part like me
22:29:46
rotateq
but on the working computer (on which I don't have root) i can deploy portacle what is also nice to have ^^
22:35:22
mayureshkathe
rotateq: i'm impressed with what "vlime" has achieved even in it's nacent state.
22:43:21
rotateq
but no, I can remember it now quite well, the same year when the ANSI CL standard was finalized
22:44:56
rotateq
but it was also good to have practical exercising with different types of regexes. reminds me i must go on really being able to use cl-ppcre
22:47:22
rotateq
mayureshkathe: and all "modern" IDEs converge to the idea of emacs (not a certain implementation)
22:47:31
mayureshkathe
phoe is considering writing a book on 'mop' and 'clos'. that's like "yay". :)
22:47:57
phoe
hey come on it's only plans and it'll only happen in like 2024 earliest gimme a break yo
22:52:42
rotateq
mayureshkathe: ah yes as I asked heisig to read parts of his new PhD thesis and plz don't get me wrong, not for any technical things, but to look if someone on some steps lower can get the central ideas
22:57:41
rotateq
phoe: with the Common Lisp Recipes 2 book you told me about what is now laid on ice, was there a first concept what to add or change?
1:35:41
Guest74
i hope he responds. Sounds like an interesting idiom. I wonder the language it comes from.
1:40:06
Guest74
well, there's put on ice in english. but that doesn't seem to work with what was said.
2:50:32
fe[nl]ix
beach: you need to switch to HTTPS for metamodular.com otherwise browsers will soon start showing a warning, since it's HTTP-only
3:55:50
mfiano
Any idea why this blows my stack at macro-expansion or compile time (when loading)? https://gist.github.com/mfiano/a8144dfc20656866e45f95e41776f78d
3:58:39
Bike
probably isn't what's causing the problem, but is that double backquote intentional? doesn't seem like it
3:59:25
mfiano
Yes for now I just want to test that it expands to that form in each defmethod (I don't want #'g-c-a-t evaluated)
4:00:29
Bike
i see. well, i don't see anything obvious. and i assume none of the lists being mapped over are circular.
4:04:48
Bike
mfiano: well, this is the only thing i can think of, so i'd throw in a check to see that illuminant-pairs does not in fact end up circular
4:05:59
Bike
it wouldln't be illuminant-pairs that would be screwed up if its elements shared structure, but rather the elements would be
4:06:12
mfiano
Bike: inline expansion: https://gist.github.com/mfiano/8f9351dbc41afd17c2c91be56af4edb1
4:06:19
Bike
but if you're looking at it printed out you're presumably only seeing two element lists, so that can't be it
4:11:14
Bike
maybe the compiler is just choking on the hundreds of method definitions. does it work if the lists are shorter?
4:14:25
mfiano
My problem is, each method will be performing the same algorithm, and that can be reduced down to a single array that I want to expand to (load-time-value some-unique-array-per-method)
4:17:28
Bike
like instead of (progn a-million-defmethods) you have (progn a-hundred-thousand-defmethods) (progn a-hundred-thousand-defmethods) ...
4:17:53
Bike
if the compiler is choking on the amount of code, it's probably more because of having them all in the same top level form, rather than just having them at all
4:19:16
EdLangley[m]
I ran into this when I tried to use babel to turn a node project into ES3 and then load the generated code with cl-js
4:19:36
EdLangley[m]
For some reason, cljs can't handle the tremendous amount of code in the typical node project :)
4:22:01
fe[nl]ix
I imagine they have a control panel somewhere where you can setup HTTPS hosting with automatically renewed certificates
4:22:44
beach
fe[nl]ix: Maybe so. My problem is that there were 5 words in that phrase that I don't understand. But I'll investigate. Thanks.
4:30:51
mfiano
Bike: I am at a loss. Here is 1 type only, that takes about 30 seconds to macro-expand (and the permutation list generates instantaneously). I don't think this is a correct expansion, because perms length is only 552
4:36:08
Bike
throw (macroexpand-1 '(generate-chromatic-adaptation-methods :bradford)) at the profiler
4:39:51
mfiano
Well that completed instantly, so I guess it is just the inline macrostepper that is slow. However, I get a very strange error at load time now.
4:47:17
mfiano
I don't understand why macroexpand-1 in the statistical profiler completes too soon to give any profiling data, but it takes like 30 seconds to compile/load the fasl
4:48:49
Bike
compiling things is hard. even if it doesn't build up the discriminating function until it's called, you're telling it to compile several thousand method bodies.
4:49:53
Bike
also, i don't remotely understand what you're doing, but several thousand eql-specialized methods is probably not the best way to do it
4:49:54
mfiano
ok and considering i didn't even get to the meat of the computationally expensive method bodies, I fear I need to find another solution
4:50:52
mfiano
The whole point is so I don't have to run a 20 line linear algebra matrix multiplication pipeline at runtime for each pixel of an arbitrarily sized image. just multiplying the pixel by a single matrix (that i want these methods to reduce to) would be FAR more efficient
4:51:25
mfiano
I am avoiding hash tables completely because of thread contention when synchronizing with a mutex
4:52:11
Bike
i mean. there's like a pretty decent chance that method lookup will also go through a hash table.
4:52:39
EdLangley[m]
So, if you precompute the hash table and then only read, you shouldn’t need to synchronize, right?
4:53:01
Bike
are you saying that each of these methods is supposed to return a matrix, and then the caller applies that to some vector representing a pixel
4:58:20
Bike
and as a dumb little test i just spawned a few threads to read from the same key of a hash table a million times, and that went fine
4:59:28
mfiano
Interesting. Maybe I am mis-remembering, though I'm not sure how SBCL could know that another thread isn't currently writing
5:00:19
Bike
don't think it does. i checked the source, and this error is signaled when sbcl determines a hash table has been corrupted. like, if some previous operations broke it, a subsequent operation might result in this error
5:02:04
mfiano
There are 3 specializers in the GF. I don't really want runtime EQUAL testing on a 3-tuple per pixel just to hash to get the right value out.
5:02:49
Bike
i think you are being optimistic to think that method dispatch will never do runtime testing on a tuple
5:03:35
mfiano
I very well could be. I just like methods because now I have to think about extensibility
5:06:16
mfiano
I was planning on having the user define a set of 3 different methods to define a color space, that can be easily introspectible with M-., but now I have to stick everything in a single global opaque hash table, without some other convenient introspection interface.
5:07:04
EdLangley[m]
The other option is to figure out some way to only define the methods the user wants
5:07:29
Bike
scrolling through a list of thousands of methods on the M-. screen might not actually be that easy
5:08:35
mfiano
Eh it's not that difficult with search. At least not with my thousands of GLSL-like vector swizzle operators :)
5:12:26
mfiano
In any case, I'm not sure I wouldn't run into the same problem with a hash table. The matrices are the product of a computationally expensive algorithm. I'm running into compile times taking too long without even performing the algorithm, just by the shear number of what will be hash table entries to populate.
5:15:31
mfiano
Ah but that could happen any time at runtime, with multiple threads, so throws the hash table idea out for memoization.
6:02:21
mfiano
Well, the funny thing is everything compiles instantly if I just populate a defvar at compile time with all 6960 matrices, including the computationally expensive algorithm for each to derive them.
6:02:53
mfiano
So I have a hash table that is populated instantaneously. Something a macro was having a very hard to with.