freenode/#lisp - IRC Chatlog
Search
16:29:02
Demosthenex
in case anyone is interested, humble bundle's doing a coder book bundle atm which includes land of lisp (ebooks). https://www.humblebundle.com/books/learn-you-some-code-books
17:08:17
cgay
I wonder where Land of Lisp's summary came from. "...but it's cryptic syntax...." Way to sell books, guys.
17:13:46
aeth
I recently looked through the book (it was part of an ebook bundle a long time ago) and it didn't look as bad as some people said. It moves pretty slowly, though. Takes a while to get to useful features of the language.
17:14:37
aeth
It's dated, though. It recommends CLISP, whereas these days people generally recommend SBCL. And it mentions Clojure and Arc as up-and-coming Lisps.
17:28:27
russellw
What would be the most idiomatic way to order parts of a name? That is, in Scheme, there are lots of names like string->number. In my opinion, it would arguably make more sense to write such names like number-string or number-of-string when we are dealing with pure functions, because the function name is written before the argument, but string->number is the Scheme idiom. What is the idiom in
17:31:27
Bike
so e.g. the thing to get a string out of a symbol or character is just called 'string'
17:32:26
russellw
right, which is why the distinction does not show up in the standard library. But as far as you are concerned, the idiom is from->to, not to-of-from?
17:33:26
Bike
i'm mostly talking about my preference. i don't know that it's something there's really an idiom for.
17:35:19
russellw
the specific use case that prompted the question is a pair of test functions, one of which tries reading and then writing, the other of which tries writing then reading
17:36:25
pjb
russellw: indeed, number<-string in scheme, number-from-string in CL would lead to more readable code. But still, left-to-right transformations are more common.
17:40:42
pfdietz
For accessors of structure types, the common part is a prefix. (defstruct human head arms torso legs) gives human-head, human-arms, etc.
17:41:45
pjb
(sign (hand-of-arm (arm-of-human (human-ceo-of-enterprise 'apple))) (employment-contract *me*))
17:42:37
pjb
the -of- or -from- or <- connectors leads to more readable code than the -to- or -> or just - connectors.
17:42:59
pjb
Notice on the other hand, that in CL, you can specify the prefix in defstruct, and you can use foo. instead of foo-
17:44:04
russellw
and I think given that the idiom is as it is, it is probably better if I follow it rather than doing things a different way
17:44:23
pfdietz
The alternate style is that of generic function accessors for standard classes. These typically omit the prefix entirely. arms, head, etc.
17:51:26
shrdlu68
I have a binary tree data structure such that each node consists of 'left-child, 'right-child, and 'data (which is some arbitrary object stored at the node). I'm currently using a vector to hold the values, initialized as (vector nil nil nil). What's a better alternative, performace-wise?
17:53:20
russellw
I would expect on theoretical grounds a structure should be slightly faster because the bounds check can be omitted, but the actual performance difference too small to measure
17:54:47
pjb
russellw: actually, I don't think structures can do without the bound check: (defstruct 2d-point x y) (defstruct (3d-point (:include 2d-point)) z) (3d-point-z (make-2d-point)) vs. (2d-point-y (make-3d-point))
17:55:06
shrdlu68
The results of profiling are: https://gist.github.com/shrdlu68/081a78c6196b676395ca518a268d9119
17:56:40
pjb
But you should realize that it's silly to opimize the access to the node slots of a binary tree, when the access to the tree is a slow O(logn), when you could have O(1) with a hash-table!?!
18:04:09
shrdlu68
The keys are bit vectors of length 1-240. I just walk the bit vector going left or right.
18:05:12
russellw
if all you want to do is lookup, I would expect a hash table to be both faster and smaller
18:10:45
shrdlu68
I tried using an octet vector rather than a bit vector, but octet vector was a bit slower than the bit vector.
18:11:52
shrdlu68
Yes. I had to subseq and mask some of the bits of the last octet where length was not a multiple of 8.
18:12:46
russellw
how many of these things are you storing, that you need to worry about 32 bytes per key?
18:14:58
russellw
supposing you have an atom to convert to a (read)able string, is this the fastest/simplest way to do it? (format nil "~s" a)
18:16:19
whartung
uh.. “all 240-bit prefixes”, we only have 64 bit addressing…arent; you going to run out? “I know, I’ll use virtual memory! — Now you have 2 problems.”
18:18:27
shrdlu68
whartung: I take a file, read it into an octet vector, convert that into a bit vector, and, for each bit, look back 240 bits, keeping track of the last (n=240) bits.
18:28:06
russellw
also '5s to process a 36k file'? on a modern computer, it should be much faster than that. Calculating hashes is nowhere near that slow. By orders of magnitude. Have you profiled it? What compiler are you using?
18:33:25
shrdlu68
russellw: Profiling: https://gist.github.com/shrdlu68/081a78c6196b676395ca518a268d9119
18:36:00
russellw
so if I understand that correctly, you are using SBCL, which is generally reckoned the fastest available compiler, and it is indeed spending a large percentage of the total time calculating hashes. Okay, that is bizarre, and I have no explanation for it. Should be several orders of magnitude faster
18:36:38
shrdlu68
russellw: Other implementations take so long I haven't really let them run to completion.
18:42:09
whartung
3.7% shouldn’t dominate the discussion. It’s interesting, but obviously not “the reason” its slow
18:42:43
whartung
I assume this: (FLET "BODY-FUN-0" :IN SB-IMPL::GETHASH3) includes the body of the function?
18:43:52
shrdlu68
The profiling without inlining, and removing one function (forgot to update repo): https://gist.github.com/shrdlu68/081a78c6196b676395ca518a268d9119
18:52:21
shka_
no idea, but i would expect sbcl to have different logic for short bitvectors and long ones
18:52:30
shrdlu68
"enhancement: The value of SXHASH on bit-vectors of length equal to the word size now depends on the vector's contents instead of being constant; its value on bit-vectors of length divisible by the word size now depends also on the contents of the vector's last word." => http://www.sbcl.org/all-news.html
18:53:58
jasom
it uses a poor mixng function though; the longer the bit vector the more the difference, but even with 30 bytes the first 9 decimal digits are identical
19:21:05
jasom
also how many bit vectors are there supposed to be? I'm seeing 4M already and it hasn't yet run out of ram on my 1GB heap
19:22:15
oni-on-ion
heh @ last bullet item "(only with users permission and for maintenance reasons)" isnt that FB
19:23:13
oni-on-ion
if you dont need to modify the data as they come from files, perhaps using a more efficient data structure than that ?
19:24:35
oni-on-ion
https://www.reddit.com/r/lisp/comments/5oezj6/how_to_interface_with_a_mysql_database_in_lisp/ ?
19:32:40
dim
shrdlu68: try CCL, the GC is much better than SBCL's one in my playing around with pgloader
19:43:00
jasom
shrdlu68: heap will almost always be exhasted during GC; its either during GC or during a point where GC is excluded.
19:44:08
jasom
it looks like the hash table is about to grow to ~600MB and we are using 500MB, so that checks out.
19:44:08
dim
vtomole: when using pgloader users often reach heap exhausted/game over message in situations where CCL pile through the work at a fraction of the memory usage; it might be my code though
19:44:42
dim
but when users report problems with SBCL and big/huge data sets being processed by pgloader, I know I can just recommend CCL and it's going to be ok.
19:44:43
jasom
sbcl is very conservative about *when* to invoke the GC, so I've seen heap exhausted when there would have been room had the GC been run sooner
19:47:36
jasom
but in this case it's jsut that its growing the hash-table to be more than 1/2 the heap which just isn't going to work
19:50:20
jasom
but it looks like we have 4M objects in less than 2k buckets, which explains a lot. However ~200MB of simple-bit-vectors seems excessive if the original statement that it's only 1 vector per bit in the file.
19:52:51
jasom
oh, that makes sense then. Space usage isn't that high; looks like its 8bytes+size of bit-vector per bit vector and then thhere's another over 100M for the single-float arrays
19:53:08
jasom
so it's ~300M of data for 100M of hash-table overhead which isn't great but not terrible.
19:54:53
jasom
however, it looks like it may be copying the data on a rehash, as that's the only thing that makes sense for a 600M allocation. I'll inspect the code
20:01:14
jasom
also it looks like it always rounds the hash table size up to a power of two, which makes the default rehash-size of 1.5 rather stupid
20:03:28
jasom
total hash-table overhead seems to be 4 times the word size of the number of elements rounded up to a power of two
20:27:22
aeth
pjb: whenever I have something where a compose macro/function/whatever might seem useful, I find that it's probably better just to combine two of the three compositions into one new, trivial, inline function
20:28:34
aeth
i.e. instead of (another-function (some-function (symbol-to-keyword foo))) I can have (another-function (some-function* foo)) where the variation of some-function converts symbols to keywords
20:29:08
aeth
(I say i.e. instead of e.g. because it's pretty much always that, usually even symbol-to-keyword!)
20:31:35
aeth
This is common when I have a function with a case working on keywords but I take in arbitrary symbols from a macro.
21:30:46
Bike
is that supposed to be set intersection? because those expressions are not necessarily true
21:30:49
jasom
qapples: I considered implementing something like racket's language features using a reader macro
21:38:31
jkordani
well that doesn't really make sense. I've dabbled in racket, but why do you need people in lisp who aren't also in #racket
22:17:01
LdBeth
That was a macro system proposed for both CL and Scheme, but seems never been adopted
22:44:45
aeth
qapples: ##lisp is the channel for the Lisp family of languages and #lisp is the channel for Common Lisp
22:46:18
aeth
ober: If #lisp had the topic of ##lisp and we were in #cl or some other channel instead, then #lisp would be as dead as ##lisp is
22:52:09
aeth
(It's a coward move to make a claim and then leave before anyone can respond. So I posted my response even though I noticed the person I responded to left.)
22:54:40
housel
I've been in this channel off and on since 2003, I don't remember him ever coming here and opining about the channel topic
22:54:48
dto
any parenscript experts here? i'm a bit confused. the function APPEND is in the manual, but showing up as undefined.
22:58:45
aeth
There isn't even one definition of "Lisp". You could mean "traditional Lisp", in which case only elisp and CL count (for the living, modern Lisp languages). You could expand it a bit and include Scheme (and probably have to split this expansion in two, one excluding Racket because of its immutable conses and one including Racket). You could also be all-inclusive (e.g. Clojure, Hy, etc.). And there are probably other, messier ways that would
22:59:33
aeth
And an active channel devoted to the Lisp family would probably debate over definitions half of the time unless it had an official definition.
23:15:29
aeth
Personally, I would divide Lisps into traditional Lisps (CL is one), CL-likes (e.g. Parenscript, which calls itself "an extended subset of Common Lisp"), Schemes (e.g. Guile), Scheme-likes (e.g. Racket), and other.
23:18:49
oni-on-ion
why u so mean to parenscript, its use case is for outputting javascript, not being a CL implementation =)
23:37:52
dto
jasom: it seems to not like when i call append as assigning an initial value to a defvar .hangon
23:42:55
dto
(ps:compile-script '(defvar *oppressors* (apply #'append (mapcar #'first *oppressions*))))
23:43:27
jasom
parenscript doesn't define any functions as a requirement is that it is usable in isolation.
1:21:46
oni-on-ion
is it trivial to swap out packages? ie. if i have two implementations of something, with the same interface, could i swap them at runtime? i amassuming so, like with find-symbol etc
1:33:35
jcowan
Can anyone suggest use cases for `copy-symbol`, either with or without copying properties (value cell, function cell, p-list)?
1:35:22
oni-on-ion
see the examples there.. it would seem that testing for inequality might have some interesting cases
2:09:17
jcowan
The examples for copy-symbol show what the function does, it doesn't give any indication of why you'd use it in practice.
2:09:55
aeth
hyperspec examples are usually interesting edge cases for implementors, perhaps something you'd want to put in a test case for standards compliance.
2:10:53
jcowan
But I still wonder what the utility of the function is, especially without copying properties: it's just (make-symbol (symbol-name 'fred))
2:11:33
aeth
I'd run a big usage search over ~/quicklisp/dists/quicklisp/software if you have a large amount installed and see if it shows up
2:15:27
aeth
Sorry, it's not actually used in mcclim, it's just part of a giant list called all-ansi-symbols
2:19:11
jcowan
aeth: Thanks. In uiop is used so that you can pass a symbol rather than a string to make-symbol variants.
2:23:46
jcowan
in cells it's used in two places in the format (copy-symbol 'foo), which is just '#:foo
2:29:07
Bike
"Two apparently uninterned symbols S and C are similar if their names are similar. " i guess.
2:33:21
jcowan
3.2.4.4 says "If [two literal objects] are either both symbols or both packages, they may only be coalesced if and only if they are identical."
2:33:35
specbot
Additional Constraints on Externalizable Objects: http://www.lispworks.com/reference/HyperSpec/Body/03_bdd.htm
2:36:23
Bike
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf enjoy
2:37:25
loke
If I remember correctly, they assembleds the binary from the source listings that are available on bitsavers
2:37:57
jcowan
THe link above definitely does not contain full source, though it contains snippets of the Lisp-level source
2:39:13
jcowan
http://www.softwarepreservation.org/projects/LISP/lisp15_family/#LISP_I_and_LISP_1.5_for_IBM_704,_709,_7090_ seems to be it
2:40:48
jcowan
http://recycledknowledge.blogspot.com/2011/11/john-mccarthy-inventor-of-lisp-died.html is a trivial translation of McCarthy's theorem prover from 1959 into Scheme
2:43:52
loke
asarch: most of us are too young... Remember that was back in the 50's. Also, very few people did.
2:45:35
loke
asarch: Also, you don' tneed a legacy mode for SBCL. You can implement it in very little Lisp code yourself. I beleve pjb did that and ran some Lisp 1.5 code in common lisp.
2:53:47
aeth
Nowhere near enough work preserving stuff. And I'm not sure things have gotten better in an era where things are continuously patched, either on the server or with daily updates
2:54:52
aeth
I'm sure for some things you could see what version was used in 2011-02-12 and even have the binary stored, but even keeping the source repo(s) and rolling back to that day might not get you the same build.
3:02:26
asarch
Now than I can understand Lisp, I see the code and I get disappointed. Then I get back to other languages and I get even more disappointed. Then, I get disappointed not about Lisp but about me and then I realize about its beauty. One very easy and natural way to solve problems
3:08:04
aeth
asarch: Imo, there's nothing in Lisp that can't be done in another language. What's rare is the combination in one language.
3:22:35
asarch
I think it would be great for girls, since they actually don't like to complicate things
3:28:30
loke
aeth: They don't write any lisp. They learned some, and them promptly went back to doing something else.
3:28:56
loke
However, I noticed that Roblox is a great game for creative people. Roblox Studio is pretty amazing.