freenode/#lisp - IRC Chatlog
Search
5:32:37
vivit
I've had trouble getting quicklisp to work. It installs just fine, but whenever I try to load anything, it tells me that no such system is found.
5:34:36
beach
If you add a local project to ~/quicklisp/local-projects, Quicklisp does not automatically find it.
5:36:43
beach
vivit: Does it fail when you try to load a system provided by Quicklisp, or does it fail when you try to load a system defined by yourself?
5:37:30
vivit
The quicklisp website says that the quickload function "will automatically download any supporting software it needs to load [a] system." I feel like I'm probably making a very silly mistake.
5:43:40
vivit
I have a big manually-curated .asdf/ directory. Is there anything I should do to migrate what I have there to quicklisp?
5:51:22
Nilby
I tossed most of my huge manually-curated asdf directory, and had much fewer links only as needed in quicklisp/loccal-projects.
5:55:53
White_Flame
(to be extra clear, add a symlink inside local-projects/, don't make local-projects itself a link)
10:06:46
m7v21z42
how do I become badass and write + compile code live, on-the-fly like Baggers does? I love writing lisp, I've studied a few of his videos with CEPL. When it comes to making a project or learning further though, I seem to not fully comprehend lisp just yet
10:08:09
beach
Then you need practice. And you need to expose your code and take into account the feedback you get so that your code respects conventions.
10:11:29
jmercouris
There is no universal recipe for how to learn. You will have to figure that out for yourself I am afraid.
10:11:52
m7v21z42
is there a good online live runtime compiler / interpreter or something like Pico-8 for rapid testing and learning?
10:11:52
jmercouris
One thing is pretty certain though, exposure to source material and practice will likely improve your skills
10:12:15
beach
m7v21z42: You may also need to practice typing, and you might need to know more commands in your editor to make things fast.
10:13:03
beach
m7v21z42: Any Common Lisp implementation can be used with Emacs+SLIME and you then have an incremental compiler that will do what you want.
10:15:14
beach
m7v21z42: Common Lisp is a "dynamic" (or "interactive") language meaning that the semantics are defined as a suite of interactions, as opposed to "static" (or "batch") languages that have a strict separation between compile time and run time. This feature of Common Lisp is what makes live coding like that possible.
10:15:35
m7v21z42
thanks for suggesting portacle, seems like a good toolset of what I was already using
10:18:37
m7v21z42
sorta. I have maybe 10 or 20 hours of experience working with it and learning basic important functions
10:19:25
beach
Emacs allows for navigation and editing by expressions, as opposed to just characters and words.
10:21:56
beach
jmercouris: Things like C-M-a, C-M-e, C-M-f, C-M-b, C-M-t are absolutely necessary to get up too speed with Common Lisp editing.
10:23:04
beach
I also tend to use M-/ a lot, especially if my variable names are long as they usually are in my code.
10:23:13
splittist
m7v21z42: when I want to do something with a new tool, I tell myself to take the time to find the 'right' way to do it (e.g. moving by word or by sexp), then make a note (perhaps on a sticky to be stuck to the monitor) and take the time to use that new way even if it is slower to begin with. After a while your fingers will take over and you can move to learning the next thing.
10:24:38
beach
m7v21z42: If it is not a Common Lisp implementation, then this channel is not the right forum for it.
10:24:56
splittist
My latest thing is C-c C-] in slime modes, to close all the open parens. Although sometimes closing them one by one and watching the corresponding paren being highlighted is a good check that what I think is happening is actually happening.
12:13:49
phoe
I have a foreign array of five u8s. Is there any clever way of turning that into a Lisp integer, other than manually reading that into a (vector u8 (5)) and manually LDBing the bytes into the result?
12:15:50
phoe
The latter. I don't care about endianness - the only thing I care about is that these values are unique.
12:16:15
phoe
So in my case either all of them are big-endian or all are little-endian, which is good enough for me.
12:18:50
phoe
I can read that as a foreign array of (:array :unsigned-char 5) and then sum it up manually, I just wonder if it can be done in a nicer way.
12:45:17
didi
Just a fun found in SBCL: (defun 1- (number) (declare (explicit-check)) (1- number)) turtles all the way.
12:47:11
phoe
didi: that definition is there for the sake of e.g. source location finders, the actual 1- is implemented elsewhere.
13:09:49
didi
In other news, here's an implementation of Algorithm L of reservoir-sampling: <https://paste.debian.net/hidden/2f53652a> Admittedly, it's less useful because we're inputting a list that's already in memory, but oh well.
13:17:41
jdz
You're already doing COERCE. But then again, I'd also COERCE the input list into an array instead of using NTHCDR.
13:46:20
jdz
didi: I'd also write the whole method like this (maybe after thinking of ways to make it prettier): https://gist.github.com/jdz/c59f46053f7e79b69380f222a08cc5f9
13:48:00
Xach
sjl: i want to make it easy for anyone to find out exactly what, when & how I got something that's in a dist.
13:49:41
jdz
didi: Right, I don't know what the algorithm L is (but I can guess); I was rolling with the method name. And the effect should be similar. If it's not, there's something wrong with the algorithm L (if my guess is correct).
13:52:27
jdz
I might also be talking nonsense, in which case I'd kindly ask you to point that out :)
13:53:04
didi
jdz: Better yet, here's an Wikipedia page: <https://en.wikipedia.org/wiki/Reservoir_sampling#An_optimal_algorithm> :-)
14:21:54
_death
not sure how much better it is in practice, since non-cryptographic PRNGs are quite fast ;)
14:45:41
_death
(i.e. if there's a big speed difference between skipping M items and scanning M items.. for example, querying items from a server)
14:48:40
_death
also, since the indices are independent from the items, they can be pre-computed for each sample size
14:56:10
didi
_death: My list version scans the list, the original version only uses indices, so I'm guessing you get a speed up by skipping items.
14:58:33
didi
_death: Even worse: the list is all in memory, so the reservoir advantage is non-existent.
14:59:21
_death
didi: well, there is still some advantage, as you don't have to know the length of the list a priori
15:06:58
_death
didi: so it seems a good interface would be a lazy sequence of indices.. then user code can skip items and update the sample accordingly
15:10:09
didi
_death: It seems to me that the point is not having all the source in memory. I think Algorithm L advantage is avoiding calling `random' at every source element.
15:11:11
_death
didi: right, it not just avoids calling random, but it avoids doing anything, hence items can be skipped
15:12:24
_death
I would write a short snippet to make my interface idea clear, but I have to leave soon
15:12:25
didi
Tho my use case, i.e. reading large files from disk, would still force someone to read all the items sequentially.
15:13:07
_death
didi: can you not seek? (do you not have an index for each item position, or fixed size items?)
15:15:05
_death
the way I've been using it also required scanning, but it helped not having to know the length beforehand
15:23:20
beach
I keep wondering whether GSoC takes place in December-January in the southern hemisphere.
15:28:37
jmercouris
i thought the difference was that their parentheses have to be like )print "lol"(
15:29:49
splittist
jmercouris: Australians were using parens 10,000 years ago. What goes around comes around, as they say.
15:30:04
rpg
beach: GSoC is done through the project, so it would have to be someone like your Uni, or the SBCL project, or something like that.
15:30:40
rpg
jmercouris: ALGOL was sort of the Ur-language for structured (post FORTRAN) programming. It gave rise to a lot of key PL ideas.
15:31:34
Bike
unlike with lisp, modern languages closely derived from old ALGOL aren't really called ALGOL, as far as i know anyway