libera/#commonlisp - IRC Chatlog
Search
4:41:08
loke[m]
beach: probably because they didn't try enough (not enough buy-in, causing fragmentation internally). That's the usual explanation.
4:42:36
loke[m]
beach: That sure sounds like internal fragmentation to me. One hand announcing something the other hand is still working on.
4:43:07
mayureshkathe
beach, agree about C++, but OO is definitely an overkill for an extension language.
4:43:35
loke[m]
mayureshkathe: why? The object orientation features should be the core of the extension API.
4:43:39
beach
mayureshkathe: That's part of my problem with it. Writing software in (say) a static language and then using Lisp as an extension language is like the words combination.
4:44:29
beach
mayureshkathe: You will get a much nicer, faster, and more maintainable system if you write everything in Common Lisp.
4:45:37
loke[m]
Is there a current issue with the version of static-vectors in QL and the latest version of SBCL? It appears static-vectors is trying to access SB-KERNEL:SYSTEM-AREA-UB8-FILL which is not available in recent SBCL
4:45:42
mayureshkathe
though, i had once noticed a cmucl implementation of a numerics library that far outperformed the c counterpart.
4:46:14
beach
mayureshkathe: As I often say, it is impossible to write a C++ program that is both modular and fast. And since modularity would be a requirement for such a large project, there is no way the code can be fast.
4:47:22
beach
mayureshkathe: Plus, combining a static and a dynamic language creates a maintenance nightmare.
4:48:11
mayureshkathe
beach: true that, our mechanical engineers at l&t used to rip out their hair at times while sharing AutoLisp code.
4:49:31
beach
mayureshkathe: Several projects I have known in the past chose C++ "because the compiler is known to generate fast code", but then to keep sane, the developers introduce smart pointers and reference counters, thereby slowing down the code by a factor 10 or so compared to the equivalent Common Lisp code.
4:49:43
mayureshkathe
another off-topic question; if my aim is to work with common lisp just as a hobby, would it make sense to migrate to LispWork from SBCL under Windows?
4:50:03
beach
mayureshkathe: But they still think their system is as fast as it can be, because, after all, the C++ compiler is known to generate fast code, right?
5:01:32
mayureshkathe
okay, in the meanwhile, i took a decision, i'm sticking with ubuntu + sbcl + emacs + slime
5:03:01
susam
mayureshkathe: I switched to Emacs after 18 years of Vim. I like it. It is just took a while to become comfortable with it.
5:03:25
edgar-rft
mayureshkathe: Ubuntu is based on Debian packages and if I remember right then CMUCL was dropped from Debian because it can't be automatically built by C-style autotools. Raymond Toy complained about this some time ago.
5:03:51
moon-child
I remain halfway between emacs and vim. And started working on my own texteditor so we'll see what happens
5:04:01
susam
The main reason I switched was because I was using Emacs + SLIME for Lisp already which gradually kept exposing me to Emacs' other features. Over time I realized that I could be equally productive with Emacs if I were to use it fulltime.
5:06:14
edgar-rft
One of the main reasons why SBCL was forked from CMUCL is because the CMUCL build process needs to be hand-tuned and is a bit whacky.
5:08:02
jackdaniel
beach: speaking of c++: this language is less than the sum of its parts (i.e there are numerous sensible parts of c++ but put together they don't really play)
5:09:20
edgar-rft
mayureshkathe: CMUCL is probably faster in some aspects but SBCL is *much* easier to maintain
5:13:41
mayureshkathe
beach: there was a numerical processing system written in cmucl which was way faster than all those written in c.
5:14:51
moon-child
I find it doubtful you can do numerical processing way faster than any existing solution; the bottleneck is generally memory bandwidth, and when it's not it's usually the hardware's numerical capacity
5:19:26
edgar-rft
CMUCL definitely is a great piece of work but the practical problem is that with today's multi-core and multi-level-cache CPUs mainaining *fast* assembly code is a real challenge. The low-level hardware has become a lot more complex than it was at the times when CMUCL had started.
5:20:12
moon-child
I don't know as it's more challenging per se, but the performance characteristics have definitely changed
5:24:05
raeda
What are people's opinions on Lem? I'm not an Emacs power user so the two are pretty much the same for me
5:47:23
beach
raeda: It looks like a pretty traditional Emacs clone to me, except that it is written in Common Lisp, of course.
5:48:10
beach
raeda: The result of that is that it will inevitably be missing lots of Emacs features, while not providing a substantial improvement to editing Common Lisp code.
5:48:30
raeda
coat: not sure what it stands for, but it's an editor written in CL https://github.com/lem-project/lem
5:49:24
beach
raeda: On the other hand, we are working (very slowly) on an editor that we hope will provide a much better experience with editing Common Lisp code, namely Second Climacs.
5:50:05
beach
Again, even when configured to look like Emacs, it will obviously lack tons of features of Emacs, but at least it will have the advantage over Emacs for editing Common Lisp code.
5:50:07
coat
does Lem support CL as a configuration language? the readme does not say a lot about the kind of things curious folks would like to know.
5:50:52
coat
one thing I like about Emacs is that it is first and foremost an Emacs Lisp interpreter and Emacs, the editor, the UI, etc. are coded in that Emacs Lisp interpreter. so Emacs Lisp interpreter starts first and executes the editor.
5:50:58
beach
coat: Since the entire thing is written in Common Lisp, it would be surprising if you couldn't modify it in arbitrary ways.
5:52:12
beach
Which is a better design in my opinion than Emacs Lisp. Though things were different when Emacs was written, so this is not an accusation of bad design.
5:53:39
beach
I frequently quote (from memory) my email to RMS when he announced GNU Emacs. I wrote something like "I think it would be much better to first write a real Lisp system, and then write Emacs in it" (as I had experience from with Multics Emacs), to which RMS answered "Sounds good. Let me know when you have implemented it".
5:59:26
beach
I am not sure he remembers that I was the author of that mail, but I have met RMS a few times much later, and he was in fact an invited guest of our department for I think two weeks at some point.
7:53:49
kakuhen
so i decided to look into libfixposix a bit more and now i have ruled out using io-lib for anything
7:54:19
kakuhen
did the mistake of testing libfixposix on mac os, and caused an annoying error that had to make me reinstall my os
7:55:09
kakuhen
earlier today i also tried out qtools, and that also failed, though in a considerably more graceful manner than the io-lib stuff.
7:58:37
kakuhen
well I was looking at my options for GUI toolkits in common lisp, just out of curiosity
7:59:26
beach
Then work on changing the appearance (but that is also being worked on) rather than taking on a huge foreign library will all the work that implies.
7:59:27
kakuhen
A lot of alternatives to McCLIM I found ends up using FFI voodoo to get the job done, except for Ltk
7:59:47
kakuhen
Ltk is very interesting because your lisp image just talks to the tcl interpreter, so there's no random ffi issues to worry about there
8:01:14
beach
McCLIM is being actively worked on, and it is getting better by the day. If more people put in a small amount of work (like another "look"), then others will benefit as well, and we will have a truly great GUI library.
8:01:56
kakuhen
anyway, CAPI from LispWorks looks very interesting, though I'm not sure if I want to spend $1,500 just to mess around with it :x
8:02:26
beach
Good. Also the #clim IRC channel is very active and help is given when people have questions.
9:22:06
kakuhen
ok i suspected as much, but now how does one introduce a common lisp implementation on another architecture? assuming the lisp kernel can be built for it and it works.
9:22:46
phoe
or you bootstrap ECL there and use it to load the SBCL compiler that then compiles a SBCL heap image
9:23:30
kakuhen
I was wondering theoretically, say CCL has a lisp kernel for freebsd-arm64 (they don't, but suppose one could be made)
9:24:26
phoe
if you tell the compiler to produce a heap of bytes made by the arm backend, you'll get an arm image
9:25:44
phoe
and the compiler knows how to make arm64 code no matter which architecture it is running on - it's just a program like everything else
9:26:10
kakuhen
yeah I just didn't understand the role of the lisp kernel in introducing a cl implementation to another arch
9:26:21
phoe
when you tell a compiler that's running on an amd64 machine to pop out an bit of arm assembly it's not like the FBI is gonna want to know your location
9:26:37
phoe
a kernel is the part that interfaces with the OS and performs garbage collection, in most cases
10:28:24
flip214
hmmm, ,@ (MAPCAR #'QUOTE forms) doesn't work.... How would a macro quote a list of forms, individually?
10:41:26
phoe
macroexpand is not strictly necessary in there, unless it is a part of your processing logic
11:14:38
jackdaniel
fare wrote at some point of time that three backquote programmers are the equivalent
11:16:19
jackdaniel
did you have a need for three stars without abstracting it away with a new type?
11:18:35
Cymew
Double pointer? Like an array of pointers pointing to subtables? Kind of basic in so much systems programming.
11:20:11
jmercouris
maybe it isn't /that/ basic, I think you could probably do Lisp for years without needing it either
11:22:36
jackdaniel
and the answer is: no, it is a reader macro, not a special form (it may be implemented as a special form)
11:24:28
jmercouris
I seem to recall phoe teaching me something about not needing to use backticks at all in a defmacro
11:24:31
jackdaniel
backquote is a syntactic sugar for the reader, it is not specified as a lisp form (unlike quote which is specified as a lisp form - also it is not a mere syntactic sugar)
11:24:57
jmercouris
there was some article or something showing how macro functions are just regular functions
11:30:01
jackdaniel
i.e cltl2 appendix suggests an implementation based on a special form but that's not always the case
11:30:24
jackdaniel
reader may simply imlpement semantics described in /the second entry of http://l1sp.org/search?q=%60/ and get over with it
11:33:09
jackdaniel
as of fare-quasiquote it takes one interpretation of the backquote specification (following cltl2 appendix that is /not/ part of the standard) and claims that it is the only correct interpretation
12:20:19
Guest6382
Saw some mention of LEM in the log - is it an acceptable solution for day to day coding?
12:23:48
Guest6382
I can see the benefit - I'm starting to explore building apps in Emacs directly, but having a CL base is better than Emacs to some degree (although you can run CL code directly from Emacs)
13:46:03
coat
phoe: read that you don't use Paredit. how do you manipulate the s-expressions? Say you type (concatenate 'string a b) and then you realize that you want to create a (let ...) expression and put the (concatenate ...) inside (let ...). how do you do that easily?
13:51:50
coat
beach: yes, that works. thanks. I guess I am so used to paredit that human beings have been writing code without paredit too.
13:56:07
coat
err... my last message is screwed up. I meant, I am so used to paredit that I forgot human beings have been writing code without paredit too.
13:56:24
beach
coat: I use only the existing Emacs S-expression functions. There are quite a few of those as you can see.
13:57:50
coat
beach: so long time Lisp programmers like you, how did you avoid using Paredit? almost any Emacs + SLIME tutorial I pick recommends paredit. Even Portacle comes with Paredit enabled. how did you never feel tempted to use Paredit?
13:58:27
coat
beach: was it that you began doing Lisp when Paredit was not popular yet? or you began doing Lisp your own way and never bothered with Paredit because vanilla Emacs itself was sufficient?
13:59:01
coat
beach: okay. makes sense. I found it confusing too. to be honest, I don't use much of paredit anyway. slurp and barf are the only two things I use
14:00:35
coat
phoe: okay. I misunderstood that you never used paredit. have you used paredit? do you like smartparens more?
14:03:19
susam
coat: I have a little mnemonic to remember slurp and barf. C-) is slurp because ) is nice and round like a belly. Thus C-) makes the parentheses grow outwards and consume the next s-exp and put it inside the belly. Nom! Nom! C-} is curly and ugly and barfs out s-exps from its belly.
14:03:50
susam
coat: of course, that is how I started when I used to get confused. Now it is all muscle memory, so I don't really need the mnemonic anymore.
14:06:23
coat
phoe: do you customize rainbow-delimiters colors? the default ones all look very faded and very similar to each other? do you change its colors so that they become more visibile and easy to pair up?
14:12:16
phoe
https://cdn.discordapp.com/attachments/214454452067893250/857261729779679232/Zrzut_ekranu_z_2021-06-23_16-11-54.png
14:13:37
coat
phoe: looks nice. I should also customzie to put bright colors like this. why do you have two consecutive parens inside (cond ...) colored the same? There are two consecutive parens both colored green. Did you decide that? or is rainbow doing that?
14:20:19
coat
Is this the code to customize rainbow-delimiters: (set-face-foreground 'rainbow-delimiters-depth-1-face "#f99") ? Seems to work but want to be sure.
14:24:53
patience_
A strange thing that I expected to work, but then didn't was using a symbol generated by gensym in a macrolet that was nested in a macro: https://pastebin.com/5j961anx
14:29:58
beach
patience_: That happens when you try to use a variable at compile time, but its lexical binding is available only later, at run time.
14:35:33
pjb
patience_: in your case you want to use ,',sym This is a comon pattern in double backquote expressions.
14:41:57
pjb
you may rewrite the defmacro without backquote to better see it. https://termbin.com/imjg
14:42:28
pjb
as you can see, you need to wrap sym in a (list 'quote sym) this is waht ,',sym does when you use backquotes.
14:45:45
patience_
I can see that I was trying to use an unquoted symbol in my macrolet, which means that it was trying to use the value bound to the symbol. Is definitely a tricky thing to hold in the head haha