freenode/#lisp - IRC Chatlog
Search
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
15:33:19
rpg
jmercouris: So in PL class we read the Algol report, a paper about Self, Prolog, McCarthy's Lisp paper, and probably some others I have forgotten.
15:33:49
rpg
I think ALGOL added a lot of clarity to the understanding of how arguments get passed to procedures.
15:34:41
Bike
"We gladly acknowledge the influence of manuals for MIT Scheme [20], T [21], Scheme 84 [12], Common Lisp [25], Chez Scheme [8], PLT Scheme [11], and Algol 60 [1]."
15:34:47
rpg
If I recall correctly, it took years and years for Algol 68 and Ada to be fully implemented.
15:41:07
beach
jmercouris: Learning about the history of programming languages, operating systems, and computer architecture is an absolute must. Otherwise, you will fall into the trap of thinking that what you have now is not only all there is, but that it's the best thing since sliced bread. And then you won't have the mental tools to want something better.
15:42:49
Odin-
ACTION would say that, somewhat simplified, ALGOL is to C and Pascal as LISP is to Scheme and Common Lisp.
15:44:26
rpg
I think that's mostly true, but I'm not sure that C fits perfectly -- it seems really off on its own.
15:49:35
drmeister
Does anyone know quicklisp well enough (hi Xach) to confirm that this is where quicklisp loads asdf systems?
15:49:36
drmeister
https://github.com/quicklisp/quicklisp-client/blob/master/quicklisp/setup.lisp#L161
15:49:56
drmeister
I'm trying to time individual quicklisp system loading by wrapping TIME around this.
15:52:23
splittist
Algol 68 - by contrast to Algol 60 - was a decade-long, international experiment in how not to create a language. I'm sure it informed the pragmatism of the CL spec.
15:52:42
drmeister
Yeah - that was naive. quicklisp/asdf are all kinds of recursive when systems are loaded.
15:54:10
rpg
splittist: but Algol 68 was still very influential in programming language design. Like Ada, it turned out to be an experiment in how not to create an IMPLEMENTED language, but they were nevertheless very influential in successor languages that WERE implemented.
15:57:03
rpg
drmeister: Could you wrap calls to ASDF:OPERATE? I think this would be the right place, but I haven't looked at it to confirm.
15:57:44
rpg
drmeister: The tricky thing is that you don't know whether the COMPILE-OP is going to be invoked or not.
15:58:17
rpg
drmeister: That's just a user interface function: internally LOAD-SYSTEM is never called recursively. It's a thin shim around OPERATE
15:58:54
drmeister
I hit Control-C in a quicklisp load and looked at the stack - in this ccase there are several load-systems on the stack.
15:59:22
rpg
drmeister: That must be stuff that's being done by QL -- it wouldn't be ASDF doing that.
16:02:13
vivit
Is there any way to change the directory in which quicklisp in installed without reinstalling quicklisp?
16:04:55
phoe
so `mv ~/quicklisp ~/slowlisp` and then `(load #p"~/slowlisp/setup.lisp")` *should* work to the best of my knowledge
17:11:57
albatroz
And when I try to use fstat to get the file's information from its file descriptor I get a "SB-POSIX:FSTAT: The storage control block address is invalid."
17:14:40
albatroz5
Actually no. But I was expecting to get a stat such as by using stat with a filename
17:17:43
albatroz5
`(with-open-file (stream "z:/.emacs.d/init.el") (sb-posix:fstat (sb-sys:fd-stream-fd stream)))`
17:40:26
albatroz
I beggining to suspect that the open of streams isn't "informing" the external library that implements fstat.