freenode/lisp - IRC Chatlog
Search
7:45:06
no-defun-allowed
And it's intended to be read linearly, so I still don't get it. But I'd rather not discuss it, because it depresses me that the book may have seen some success.
8:17:12
beach
daphnis: If FOO is a special variable, it is badly named. It should have earmuffs on it.
8:19:42
MichaelRaskin
You could macrolet something right around the loop, then let a macro check the presence of this macrolet and decide before expansion, not in runtime
8:20:56
MichaelRaskin
Or you could just save the external value into a different name using «with», and use the same name for the loop variable as you use outside
8:59:21
aeth
yeah... most syntax highlighters highlight keywords in a special way, so LOOP's keywords make sense as keywords, at least if you don't expect syntax highlighters to support LOOP as a special case
9:00:56
jackdaniel
I mean -- I know that top-level defun defines a function, it doesn't need to be blue ;)
9:01:43
jackdaniel
one could argue, that trivial highlight of variables that are not lexical in the scope of a function would be far more useful
9:02:26
beach
Yes, there are so many more useful ways of highlighting. But Emacs can't handle those ways in general.
9:03:10
jackdaniel
right. my point is that syntax highlight is not useful for someone who knows the syntax, and for those who don't know it it won't help much
9:04:20
aeth
jackdaniel: maybe not useful for you, but it helps me visually distinguish between the parts of a long, complicated :for... which seems to happen all of the time in my LOOPs
9:04:22
jackdaniel
another useful thing (but only as an opt-in mode) would be marking how new the code is
9:05:15
jackdaniel
i.e green code is >1y, red code was modified yesterday, and a gradient in between
9:05:45
jackdaniel
MichaelRaskin: sure, my point is that you have a visual marker what could have caused a regression you are investigating
9:06:24
jackdaniel
(not necessarily because the new code is wrong, it might be that it has revealed undetected defect, still it is a useful clue)
9:08:51
aeth
jackdaniel: oh, that's actually really easy, if you define "new" in terms of the git (or other) repository's data. I wouldn't be surprised if someone has already done that. It saves a step over something like magit-diff if you only care about the new half of the diff
9:09:48
jackdaniel
"that's actually really easy" are famous last words of programmers who died in pits of despair
9:11:05
jackdaniel
either way, that's beside the point. I'm only arguing that color is very easy for the eye, so it is a waste to use it for syntax highlight
9:13:11
aeth
jackdaniel: one advantage of syntax highlighting is that you can instantly catch certain typos, especially if you have a string or block comment that's not properly closed (assuming the syntax highlighter understands the full string and comment syntax of the language)
9:15:07
jackdaniel
ACTION has voiced his opinion and dives back into pits of despair, because he is working on something what is actually really easy ;] ciao
9:22:55
MichaelRaskin
beach: the difference is that you assume the information from the text is easily available and Nilby wants the usecase when the colours are the only information
9:24:00
Nilby
I guess I only need a vauge idea, so coarse syntactic coloring is okay. If I need to really know, I'll slow down and read. I've tried doing the subtle shade thing to convey more precice info, but I usually don't see it.
9:24:21
aeth
if you really like colors at a glance... s-expressions probably make it easy to color entire expressions
9:26:26
aeth
maybe s-expression-aware highlighting could be the "killer app" of an Emacs competitor for CL programming
9:27:14
aeth
Yeah, that's the real problem. Terminals don't offer you many colors, and they're usually a pretty bad selection (which could remove some colors just because of the combinations not going together)
9:33:32
Nilby
woe be upon my terminal colors when I try to run on windows, phones, and barren servers
10:20:11
Xach
daphnis: symbol availability is managed through the package system. the tools in this case are defpackage, import, or use-package.
10:50:31
phoe
if you Ctrl+C in the terminal, this sends a unix SIGINT to the process which usually causes SBCL to enter the debugger
10:51:19
daphnis
just quit without printing anything, like normal programmes do. i used --non-interactive, so it doesn't wait for input, but it still prints stuff
10:52:42
daphnis
Xach: that's a bit too advanced for me at the moment. i suppose i can live with this for now.
10:53:02
phoe
or https://github.com/LispCookbook/cl-cookbook/blob/master/scripting.md#catching-a-c-c-termination-signal
10:53:24
Xach
I use https://github.com/xach/buildapp/blob/dd00f18938ccae0a9b406bfcfd882ad32abeb757/buildapp.lisp#L169
10:54:41
Xach
daphnis: if that's the case, i suggest not trying to build a standalone executable yet.
10:55:16
Xach
no-defun-allowed: that's a nice, simple option. for sbcl sb-ext:*invoke-debugger-hook* would be a nice variation.
10:55:30
no-defun-allowed
You can use C-d to tell SBCL to exit like C-c. Honestly, I would keep the debugger because it would be nice if "normal programs" broke into a debugger when they break.
10:55:50
phoe
Xach: trivial-custom-debugger exits for cross-implementation setting of invoke-debugger-hook or whatever it's called everywhere
12:22:48
pve
Hello! I'm thinking about a protocol, but have trouble deciding between two approaches. Which do you think is better? I'm leaning towards #1.
12:24:14
Xach
pve: i like unary predicates (and functions in general) if i intend to map them or do general higher-order programming with them to reduce the use of (lambda (token) (token-kind token 'foo)) vs #'token-foo-p
12:25:07
Xach
although sometimes i make something like (defun =token-kind (kind) (lambda (token) (eq (kind token) kind)) and do (remove-if (=token-kind 'foo) list)
12:27:42
phoe
also, if you want to go full CLOS, CHECK-VALID-TOKEN-KIND could be a generic function with the default method returning NIL and other methods, EQL-specialized on symbols, returning T
12:28:12
phoe
...and then I guess it should be VALID-TOKEN-KIND-P and be a predicate rather than an assertion
12:39:37
Xach
i'd expect a function named check-<something> to signal an error rather than return nil
14:10:17
MichaelRaskin
Does anyone know if there are any recent changes in how monolithic-compile-bundle-op is supposed to be used on recent ASDF (with SBCL on Linux)?
14:22:53
MichaelRaskin
Hmm. It feels like before it sorted dependency closure by inter-dependency, and now just takes the order in the top-level ASD file