freenode/#lisp - IRC Chatlog
Search
21:02:46
drmeister
I wonder if anyone has insight into an issue I'm seeing with docker and quicklisp - I'm trying to do something unusual.
21:03:25
drmeister
I've got a docker image (docker hub: drmeister/cando) that I'm mounting a ~/.cache and ~/quicklisp/local-projects directory into.
21:04:18
drmeister
These directories are on the host and mounted into the corresponding directories in the docker image.≈
21:05:13
drmeister
Everytime I start the docker container - quicklisp recompiles the systems from the ~/quicklisp/local-projects directory
21:05:47
drmeister
I'm trying to also mount the .cache directory - so that it can use the cached fasls - but that is not working.
21:06:21
drmeister
quicklisp/asdf use time stamps of the source files and fasls to decide if it should recompile something - correct?
21:07:15
drmeister
Hmm - the docker image uses UTC time by default. Maybe it doesn't like that the compiled fasls look like they are from a couple of hours in the future.
21:07:47
drmeister
But - fasls compiled in the future are always better than fasls compiled in the past. Hmmph
21:10:02
akkad
drmeister: you can fix that with updating the /etc/localtime and other /etc/ timezone items to match the hosts
21:11:23
akkad
that way you can avoid installing time related packages, and playing the time difference gam
23:41:52
aeth
What's the best way to deal with "multiple return value" C functions where you pass in pointers that it sets? I'm thinking static-vectors:with-static-vector and then pass in pointers to each element of that array.
23:43:52
Bike
assuming the function just uses the pointers for returning values, i'd just stack allocate, yeah
2:06:07
smokeink
circle is a class, shape is the instance object of it. shape refers to the object you pass to the function as the 1st param
2:41:47
on_ion
try to search git for a page of the different backends, afaik there is also descibed how to use them
2:45:44
Xach
I don't think beagle is still a going concern. (But I am not much of an authority in this matter.)
7:23:54
xificurC
makomo: I just read what you wrote me, thanks. I enjoyed reading let over lambda despite the code-walking issues and elitism. The sorting network chapter was pretty cool. It's also interesting to see how closures can be the building block of OO and how one can create ad-hoc protocols from it
7:26:05
xificurC
someone else (I never remember who) mentioned he doesn't like that (rephrasing) the values in closures cannot be changed, which is very non-lispy
7:28:58
xificurC
"Several remarks that might seem offensive are actually just phrasing mistakes on my part"
7:29:52
xificurC
the terminology throughout the book really sounded that way to me. All the right vs wrong, lisp vs. blubs etc
7:30:52
schweers
people often complain that lispers are elists and look down on other languages. But really, this is to be expected, given the current state of our field :/
7:31:54
beach
I still don't see how that is "elitist" though. But never mind. I am in a rotten mood, so I should probably be quiet.
7:32:04
xificurC
schweers: I agree and I sound like that to some of my colleagues too. Still it's something to look out for. Noone likes to hear their choices are "wrong" or downright "stupid" and I don't feel competent to judge anyone
7:33:11
xificurC
beach: sorry if the term offended you in any way. It was a subjective feeling not to be confused with what the author actually meant.
7:33:53
schweers
I also wonder ... is being elitist wrong generally? I feed that it can be justified
7:35:24
xificurC
I would say - knowing you are better at something is ok. Being a jerk about is is not.
7:35:26
beach
xificurC: I have often been accused of being elitist, which is probably why I reacted that way. But the people who accuse me of that say that because I happen to think it is a good idea for programmers to actually have some training. Just like I would like for surgeons, lawyers, accountants, etc., to actually have some training.
7:36:16
beach
xificurC: Many people seem to think that anyone who has written a 10-line program should be allowed to practice programming professionally.
7:36:58
schweers
shrdlu68, xificurC: it may be associated with negative behavior, but I don’t think it need be that way. Anyway, being a jerk about it and having prejudices(?) is not good. Not my point though.
7:37:54
xificurC
beach: sounds like kids calling you a swot to be honest. I try not to take those people's aggressive behavior to heart
7:39:45
aeth
schweers: Yes, but even beyond language choice, I'm not sure that software engineering has a solid foundation. Or, at least, if it has one, it doesn't seem to be the majority position.
7:40:03
aeth
If software engineering were to be treated like engineering (and maybe it should be), then it should be engineering first.
7:40:36
schweers
aeth: no, I guess the field is too young for that kind of maturity. Also, software is very different from regular engineering
7:40:49
jach[m]
jdz: even homeopaths are trained to properly dillute the thing.. but also, you can write a 10 line program that does something useful, vs homeopaths that aren't actually useful
7:41:23
xificurC
I think too much work has come too quickly and now everyone is trying to do whatever they can to code. It's not exactly anyone's fault, the field is just young
7:41:25
beach
schweers: I agree that software is very different from the artifacts that engineering is concerned with.
7:42:21
schweers
xificurC: I agree. No one entity is at fault, but the result is still very bad and needs fixing. And I don’t see much fixing going on.
7:43:28
jdz
I think this is relevant, if you have ~40 minutes to spare: https://www.err.ee/836236/video-google-0-projekti-tarkvarainseneri-ettekanne-cyconil
7:43:43
shrdlu68
Does every other company need a web developer? This is a bizarre field, and Im struck by how ephemeral our work is.
7:43:50
jach[m]
A better analogy might be writing fiction. "Real authors" and readers of them tend to be pretty snobby against things like fanfiction, and even teenage authors producing highly derivative original-enough books.
7:43:55
schweers
xificurC: some, yes. I found a job where I can write software in CL, so that’s a start. I must say that I’m the only one here, and my collegue insists on using scheme :/
7:45:42
schweers
I know, but using CL really has made me see how it is a better language (and has better implementations) than others, even scheme.
7:48:09
aeth
That's the problem with Scheme. You're (usually) not a Scheme programmer, you're a programmer of some Scheme dialect.
7:48:23
aeth
And if you like an obscure one (like Gauche) you don't get access to much of an ecosystem.
7:48:28
schweers
several things, but its slow and doesn’t have a debugger, so there are two things to start
7:49:27
xificurC
I saw someone mention femtolisp in reddit comments on r/lisp, has anyone had any experience with it? It's an undocumented lisp with 700 stars, how can that even happen?
7:52:56
schweers
shka: I don’t get why people use it at all, other than trying it out for educational purposes and the like
7:55:49
akkad
ecraven: it's fine, has a good stdlib, but runtime it tends to use a lot more ram for the stuff I've done. Just saying there are better schemes to compare directly with cl
7:58:09
makomo
xificurC: i really wonder if some time into the future people will get used to those various macrology tricks that usually seem convoluted or fragile/error-prone
7:58:35
ecraven
aeth: I'd prefer Scheme from a theoretical standpoint (I like the language "design" better, I like Lisp-1), but library-wise, there's no question that CL is far ahead
7:58:39
makomo
xificurC: doug says that some of the stuff he talks about "hasn't been fully explored and/or understood yet", and that that is the reason for it not being used
7:58:41
jach[m]
Does Racket still count as Scheme anymore? I guess maybe it's sort of like Scheme++ with all its extensions.
7:59:24
ecraven
and regarding debugging, I've never seen any other lisp that even deserves to be called debugging, compared to SLIME
7:59:42
schweers
any scheme which has a defmacro or syntax-rules is a deviation from the standard (as far as I know)
7:59:43
ecraven
akkad: no, but my suspicion is that chez would at least be in the same ballpark as sbcl, if not faster
7:59:54
xificurC
I never understood the claim that lisp-1 is bad for writing macros. When not capturing vars but using gensyms how does a lisp-1 pose any problems?
8:00:23
aeth
ecraven: the difference with a fast Scheme and a fast CL is (almost) everyone here could switch to a faster-than-SBCL CL tomorrow
8:01:00
edgar-rft
jach[m], AFAIK the main point of Scheme since ever was that only a minimal core language is defined by rNrs and everything else is a big mess :-)
8:01:06
makomo
xificurC: hm i didn't connect that he disliked lisp-1s because they "made macro writing hard". i thought it was just a stylistic issue really, and a huge annoyance also, having to name your variables like "lst" and similar
8:01:07
schweers
xificurC: I didn’t get it for the longest time either, but there are in practice fewer problems in a lisp-2. But I won’t pretend that I can explain it very well.
8:02:13
ecraven
if I won the lottery, I'd fund a Scheme that has CL's introspection and debuggability
8:02:19
makomo
i'm in the lisp-2 camp :-). i can't stand having to rename variables to something silly just to avoid name clashes
8:03:19
mrm
As someone who primarily uses scheme/racket, I'm pretty envious of CL's assembly stuff and annotations.
8:03:49
ecraven
shka: for example, I don't think you can "enter" a module in racket and redefine things. and I don't think that will ever work
8:04:06
White_Flame
xificurC: yeah, it was me. One of my major complaints is that you can't change the behavior of LoL-style objects via recompiling the source code
8:04:25
makomo
i've never really used scheme. tried it a couple of times but i like CL better i think
8:05:03
ecraven
I've even pondered creating a small wrapper around CL to make scheme code run, but I cannot figure out how to make CL into a lisp-1
8:05:29
mrm
I was pretty taken in with Racket's promise of an extensible api to the compiler, but I feel like CL delivers on that front so much more.
8:05:39
White_Flame
xificurC: it's simple runtime editing. Change CL source code, and next time you call a defun, the new behavior is there. Change LoL-based source code, and next time you call an object's method, the behavior is still the old behavior
8:06:31
mrm
ecraven: Maybe a macro that defines '(define x y)' as something that binds both slots to the same thing?
8:07:14
shka
I don't think anyone with sane mind would attempt to use LOL style objects over CLOS objects
8:09:10
White_Flame
xificurC: and even in the (defun do-something-to-object (obj var) ...) case without CLOS, that's still runtime modifiable for all objects without additional indirection, simply because it's not hidden inside object instance closures
8:10:02
White_Flame
now, of course, objects that are configurable in their behavior might want to contain function objects themselves, but when you have a 'class' of object, being unable to edit that general class's behavior during runtime editing is a limitation
8:10:43
White_Flame
and also, introspection of those objects then requires creating facilities to access the closure fields. Without LoL, you can easily see & introspect the object state
8:14:10
shka
White_Flame: i think that most of things in LOL are demonstration of what CAN be done, not what should be done ;-)
8:18:23
White_Flame
it would be nice if there was some standard, programmatic way to access closed-over variables from function objects
8:18:49
White_Flame
but I'm sure there are weird nesting cases that would make access ambiguous or unwieldy
8:21:28
phoe
there are other standard CL facilities that support logging and debugging, CLOS being the first thing that comes to mind
8:22:11
White_Flame
phoe: I simply mean that logging & debugging might want lower level access to data than normal code
8:22:36
shka
White_Flame: panodric macro can be usefull here in there, but when they spread in code it quickly becomes turbocancer
8:23:30
shka
as for debugging, slime inspector can show you values that are closed over the function
8:23:46
phoe
the moment you split the code into lower code and upper code, then you lose when you want to debug this lower code
8:26:25
xificurC
how much different is using CLOS compared to clojure's way of using (hash-)maps for objects
8:28:14
beach
xificurC: I don't know what Clojure does, but from your description, it sounds like it would be very slow.
8:29:09
makomo
shka: "oh god, how horrible code would become if people would work like this" -- reminds me of stuff that non-lispers say about lisp's macros :-), but i do agree that it would probably be a mess
8:29:44
xificurC
beach: data structures are immutable, it's not a hash table lookup but I think maps are trees with 32 nodes at each level so lookup is like O(log32 n)
8:29:50
beach
makomo: One hopes that those non-lispers also don't write abstractions in the form of functions.
8:30:31
makomo
beach: hmm, how does CLOS do it? or rather, what's the usual technique of speeding it up?
8:30:59
shka
xificurC: honestly, i find clojure lack of true object orientation to be it's biggest flaw
8:31:23
p_l
shka: doesn't it have proper object orientation which tends to be ignored in favour of passing maps around?