freenode/#lisp - IRC Chatlog
Search
7:12:50
svillemot
loke: This is not how distributions work. Sharing libraries between several applications is at the core of the distribution model (for minimizing disk space, propagating security fixes, standardizing on a single system version…)
7:14:18
svillemot
Note that this tension between the system package manager (apt) and the language package manager (QL) is not specific to CL. It also exist with other languages (Python, Ruby, R, …).
7:14:28
loke
svillemot: That runs counter to how Common Lisp development tend to work though. And it's no secret that the current Debian situation causes more problems than it solves.
7:15:01
svillemot
IMHO, both systems are useful and serve different purposes. Developers tend to prefer the language package manager, while sysadmins tend to prefer the system package manager.
7:15:10
no-defun-allowed
Yeah, except for flatpack and other braindead portability kludges, package managers and their respective distributions are designed to decrease duplicate code.
7:17:18
svillemot
loke: I'm happy to help if you can be more specific about the issues with Debian packages. As dim told yesterday, he has improved the situation a lot, and I'm following on his path.
7:17:40
svillemot
For example, in the upcoming Debian 10, all CL packages should be up-to-date and working fine with recent CL implementations.
7:18:42
loke
svillemot: well, personally, the most important thing would be that if you have Quicklisp installed, it should never touch the Debian packages but only use QL, when you have a dependency on, say, alexandria.
7:19:36
xantoz
NixOS has solved the issue pretty neatly. e.g. for python it packages pretty much everything in pip in nixpkgs
7:19:56
svillemot
loke: It's basically an ASDF configuration issue. So you can probably tell QL to do precisely that.
7:20:49
svillemot
But I also like the fact that QL is able to only download packages that are not installed via APT. So ideally this should be a configuration switch.
7:21:03
loke
svillemot: yeah, that's the problem. The people who suffer from this are precisely the people who wouldn't know how to do that.
7:22:21
jackdaniel
in an imaginary lisp system it should be possible to modify the code of a dependency per-application (or per-user) basis, so file-based global installation wouldn't work well with that
7:24:34
svillemot
loke: maybe you could open an issue against QL, asking for a change of the default behavior, i.e. not looking to system directories for ASDF systems by default (but keeping a setting to revert to the previous behavior)
7:25:10
loke
svillemot: I could, but IMHO this is a problem on debian's side, as they are the ones messing up normal system loading.
7:25:36
loke
Also, I'm not a party to either of this. I just observe the current mess and comment on it.
7:25:40
svillemot
I don't see how it "messes": by default ASDF looks to system directories, and distributions are expected to install stuff in system directories
7:27:30
loke
QL doesn't search anywhere exept its own directoris, AFAIK. THis is ASDF we're talking about, no?
7:35:34
svillemot
if I understand correctly, QL adds its own directory to ASDF search path, and then relies on ASDF for loading systems
7:36:30
svillemot
the problem that you are raising comes from the fact that /usr/share/common-lisp/ is in the default ASDF search path
14:10:04
djeis[m]
append and nconc basically ignore nil args entirely, cus there's nothing for them to do.
14:14:56
djeis[m]
Depends a bit on the code you're writing, but in general yea- you ought to use the result of destructive operations instead of relying on side-effects.
14:17:09
djeis[m]
Because most destructive functions don't have well defined side-effects, and because of the edge case where the place you're trying to append to holds nil.
14:20:16
moldybits
is it considered good style to use-package alexandria? as opposed to accessing it with the alexandria prefix.
14:20:57
_death
my rule is to onle use CL and packages that I control.. otherwise I usually import-from
14:21:30
djeis[m]
If there were any package I'd consider it okay to use I'd say alexandria, but I generally don't.
14:22:13
djeis[m]
Ofc, I sometimes break portability and use local nicknames, so I'm probably not the best person to ask.
14:24:46
djeis[m]
Well, for the specific code in which I've used the alexandria package, if that eventually leads to a conflict I'm willing to have to deal with it then.
14:25:47
_death
it may not lead to conflict, but to redefinition, which can make it hard to trace the issue.. this has happened before
14:27:12
djeis[m]
But it's enough for my peace of mind, for the small bits of personal code where I've cut that corner.
14:27:22
Ukari
I have some doubt about function naming. I found 'queue-empty-p' is a widely used name for queue empty predicate, then is 'heap-empty-p' a suitable name for a heap? and is 'ring-empty-p' a suitable name for a circular array? or just use 'emptyp' as a empty predicate is better for all of queue, heap and circular array? or use 'empty-p' instead?
14:28:36
djeis[m]
https://cliki.net/naming%20conventions There's a spot near the bottom where they explain when to use p vs -p
14:29:37
djeis[m]
Whether you want to provide a generic emptiness check or specialized ones is fairly specific to your application tho, not a lot of generic advice to give there.
14:37:50
pjb
there's also a newness and some packing factors involved. For a new defining macro you would be tempted to use define- more than def, and more so if you expect it to be rarely used.
14:39:46
pjb
Ukari: note that the rule of p vs. -p is not trivial: string-lessp because it's the lessp for a string. What does it mean to be ring-empty or to be queue-empty?
14:40:06
pjb
Ukari: if you want the emptyp operator for a ring or a queue, it should be ring-emptyp and queue-emptyp
14:41:04
pjb
On the other hand, if you want to test for the more-optimized-speed it will be more-optimized-speed-p
14:52:38
pjb
with define- you would use in-extenso name, while with def, you can use abbreviations or even puns. What's those UNs we keep DEFining all the time with DEFUN?
15:35:34
nwoob
I apologize if what i'm about to ask has been asked many times and you guys are fed up with these type of question.
15:35:37
nwoob
I want to learn a different paradigm language and I stumbled upon CL and posts and answers saying how great CL is and it has features which todays languages are still catching up to. One must learn lisp to become a good programmer.
15:35:54
nwoob
I want to simply know (if possible) will I learn things that I won’t be able to learn in other languages? Is learning CL still beneficial in 2019
15:37:54
jcowan
nwoob: Definitely. A great many things that have to be laboriously worked around in other languages are already built into Common Lisp, or can easily be implemented. It's called "the programmable programming language" (see the topic line) for a reason.
15:41:48
splittist
nwoob: do, or do not, there is no try. Commit to learning CL on its own terms for period. If it grabs you, great. If it doesn't, you'll have learnt something about yourself and CL. The biggest mistake when learning CL seems to be trying to understand CL concepts in terms of things you already know.
15:42:36
nwoob
it does grab me. I have actually started learning it and i must say i have never enjoyed learning something this much
16:59:55
polezaivsani
Learning ASDF by slogging through manual and best practices, am i missing out on some other good material?
17:46:22
Demosthenex
i've now coded a proof of concept for a CRUD TUI in both npyscreen in python, and tview in go... and i just keep beating myself up for not using lisp. ;] have i missed a tui library for CL?
17:50:21
Demosthenex
there's a big difference between having a screen control lib and having editable widgets
18:02:49
verisimilitude
If you don't want to use Common Lisp linking to C, there's my ACUTE-TERMINAL-CONTROL, Demosthenex.
18:03:24
Demosthenex
i've looked at cl-charms and croatoan, didn't quite fit. verisimilitude yours was just character control again... i didn't want to reinvent the wheel just to update a tiny DB over ssh.
18:03:26
pjb
Josh_2: also, in clisp, there's an implementation dependent SCREEN package, which is very simple to use.
18:09:12
pjb
verisimilitude: it includes the standard itself! and generates the code from the standard.
18:09:33
pjb
ok, a sexpified form of the standard, but it's basically a copy-and-paste, and some search-and-replace.
18:09:54
verisimilitude
I specifically didn't want to create a derivative work of the standard document in this way.
18:10:28
verisimilitude
I wonder if this performs the same optimizations of the control sequence that mine does.
18:11:14
verisimilitude
Is this the only other implementation of the ECMA-48 standard in Common Lisp?
18:15:46
pjb
Note that the ideal situation for me would be to just parse the standard text and generate the code from it, not to include it as sexp. But there are always irregularities…
18:17:19
verisimilitude
That's one way to do it. It was much easier for me to simply write it out in a machine-readable way once and let that be it.
18:18:17
verisimilitude
I see this supports the seven-bit and the eight-bit forms; I've been mulling over how to elegantly work that into mine, but haven't done so yet.
18:19:06
verisimilitude
I'm also lazy, which is why I didn't write code to parse a standard document.
18:21:38
verisimilitude
It doesn't seem this implementation performs the same optimization mine does.