freenode/#lisp - IRC Chatlog
Search
21:09:52
Xach
copec: both - this isn't a good place to center a discussion about what is happening with racket
21:10:07
Xach
but i get the impression that few people here keep up with racket and could talk about it in a CL-centric way
21:10:52
copec
I'm not switching from my own CL use. I'm just interesting in thinking about and comparing what other languages do
21:14:44
aeth
##lisp is for the Lisp family of languages so you might get a better/fairer comparison than #lisp or #racket would give you.
21:30:09
jasom
copec: FWIW, something like #lang could be implemented on top of CL's reader macros, and it would be interesting to see.
21:49:25
phoe
postmodern is still alive and kicking, I remember contributing to it earlier this year
21:49:38
stylewarning
Shinmera: because postgres has been through 3 major version upgrades since 2012
21:51:10
stylewarning
Shinmera: I doubt it would, especially being a database, but the spookiest of things can happen in 8 years. (:
21:52:18
Shinmera
postmodern alone is why I would recommend CL people to use postgres over any other rdbms
21:52:52
pjb
stylewarning: I don't know about postmodern. I know that I need to patch pg to be able to run with postgresql 9.6, 10 or 11…
23:24:29
didi
I just noticed `defpackage' separates each option in lists, but `defsystem' doesn't. Coincidence?
23:28:33
pjb
(defmacro defsystem (name &key description author maintainer licence version proeprties depends-on …) …)
0:18:24
jasom
We were talking about qt5 bindings. The Go QT bindings has a tool that auto-generates extern "C" functions for everything in QT. They can't be used directly though because all callbacks are in autogenerated go files that export a C header through cgo. However, that could be used as a basis for a lisp qt5 generator certainly.
1:03:39
jasom
p_l: which Qt5 bindings use libclang to generate the interface? Most of the bindings seemed to be quick/QML only.
6:37:22
beach
Me? I'm doing fine. Progress is slow but steady. But I don't think that what I do is representative for #lisp.
6:42:27
elderK
I'm not quite sure how things are. They could be a lot worse, so at least there's that.
6:47:19
drmeister
Damn - ASDF appears to require fasl files to be files and doesn't allow them to be directories.
6:48:13
beach
ck_: A lot of discussion about which of several GUI libraries written in C or C++ to choose, is another.
6:48:22
elderK
beach: The problem might be with me. I'm not sure yet. I actually came here to ask advice: What have you guys done in the past when you needed to talk to like, I guess what you'd call an older-role-model. Someone who knows you, but isn't *too* close to you. Someone who's opinion you can trust, without it be influenced by the stuff you're talking about? You might say, talk to a senior colleague. That was my
6:48:23
elderK
first idea, but I haven't yet established strong enough connections with my colleagues to make that sufficiently safe.
6:49:19
ck_
beach: oh, the last point I hadn't witnessed yet. But you make it sound quite bleak in general.
6:52:39
beach
elderK: That seems quite off topic. Maybe try #lispcafe. I don't go there myself because I don't have time for random chat.
6:54:08
beach
ck_: But as I realized a few weeks ago, it's a perfect example of the prisoners dilemma.
6:56:41
beach
ck_: Ideally, Lispers should collaborate to fill the gaps in our collection of libraries and applications, but instead, everyone prefers to work on an immediate individual problem that needs to be solved. As a result, the collective effort is much higher than it could be.
6:59:58
ck_
I meant that as an attempt to nudge the focus towards doing that again. I know this channel isn't fertile ground for that, but one can hope.
7:01:34
fe[nl]ix
drmeister: you're better off going the JVM route: make your fasl a zip-encoded file which you can treat as a virtual file-system
7:03:48
drmeister
Could I generate a fasl inside of a zip-encoded file and then run dsymutil on it to generate a .dwarf file that also goes into the zip-encoded file?
7:07:01
lukego
Xach: Yeah clbuild. I think that worked as an "executable problem statement" i.e. a really quick and easy way to confirm that the latest version of everything is broken and incompatible. In those days I'd regularly "sit down to try some McCLIM hacking" and several hours later still be fighting with installation problems. Quicklisp is a hell of a better experience B)
7:07:26
drmeister
Yeah - and I get it. We talked about zip files. We thought directories would be less trouble. Now I'm not so sure.
7:08:31
fe[nl]ix
have compile-file output various intermediate files to a temp directory, call dsymutil, then package verything up in a zip fasl
7:08:53
drmeister
We are having a problem with multiple processes compiling the same asdf systems and clobbering each others builds. We need fasl generation to be atomic - so we are going to use rename-file as the atomic operation.
7:09:09
drmeister
The problem on macOS is building the fasl and debug info is two steps, not atomic.
7:10:26
fe[nl]ix
of course, as long as each compile-file a) creates a uniquely named temp dir b) creates the fasl in there and c) commits this "transaction" by an atomic rename-file
7:12:02
fe[nl]ix
if you do things right and ensure page-level alignment, you could even mmap directly from the zip file
7:12:07
drmeister
Sorry - I'm a bit disgusted at the moment. It's not just this - we found a bug in ld64 that is causing us grief with our compile-file-parallel.
8:03:28
earl-ducaine
I was just reading the SBCL style guide and noted that package prefexes were discouraged. Not a strong prohibition but I was surprised by it.
8:03:58
earl-ducaine
In my own code I tend to use them quite a bit, i.e. it makes it clear that a set of functons are from the same package and probably are documented there in how they work together.
8:04:47
pjb
earl-ducaine: when you are in the context of a local development, where you control the name of all the packages, you can choose short package names and be happy with qualified symbols.
8:05:20
earl-ducaine
I've noticed that there are a number of aspects to using package prefixes that are problematic.
8:05:47
pjb
earl-ducaine: but in the context of internet based development, where you use hundreds of libraries and dependencies, package names need to be unique and long, such as com.informatimago.common-lisp.cesarum.array etc, and then using qualified symbols is bad for readability.
8:06:17
pjb
earl-ducaine: note that it's the same problem with nicknames. If you want to publish your code, you cannot use shortnicknames.
8:06:36
pjb
earl-ducaine: Only the end-user that won't be publishing his code, can add short nicknames and use them.
8:07:39
pjb
earl-ducaine: one solution would be package-local nicknames or relative package names, but there's no complete portable solution yet.
8:09:57
earl-ducaine
Iterate is also a problematic example, it relies on a number of symbols being imported that are neither fuctions, macros or specials. Trying to prefix every one makes it an unreadable mess.
8:10:00
beach
earl-ducaine: I only ever :USE the CL package. So I use explicit package prefixes a lot.
8:11:21
beach
earl-ducaine: As pjb pointed out, using package-local nicknames would be the right thing, once they are widespread.
8:12:52
Shinmera
ECL,ABCL,CCL,SBCL is good enough coverage for me, and I hope pressure from libraries can convince the commercial implementations to catch up