freenode/lisp - IRC Chatlog
Search
23:45:54
s3a
Bike, I felt that disassembly would require that the function passed to it has its arguments passed to it. so, the disassembly function should have, say, some_function passed to it and some_function should have, say, arg passed to it, and I thought disassembly was going over every single step the algorithm would have taken.
23:47:28
Bike
when you compile a function it is translated into some kind of format that is easier to do quickly. on sbcl it's machine code, on clisp it's virtual machine bytecode.
23:50:56
s3a
but how do we know that that is more efficient? couldn't apply be "beautifully" abstracting away something even less efficient?
23:51:39
s3a
basically, what's a reliable way to compare two algorithms? whether theoretically or using some kind of tool
23:52:36
Bike
we don't know it's more or less efficient, i am thinking heuristically based on my experience as a programmer and compiler developer
23:53:21
Bike
you want to compare "non-higher-order" to "higher-order" but the problem is that you leave too many degrees of freedom
23:54:44
Bike
the iterative implementation will probably be faster on a computer based on sequential execution of instructions, but that's not the only kind of computer there is, you know?
23:55:58
Bike
there are other issues as well, for example i can imagine a reasonable compiler design in which sum-list1 could be compiled more efficiently sometimes
23:57:04
Bike
or, a more reasonable example, with apply #'+, that could hypothetically be compiled by splitting up the problem into a binary tree and adding in parallel (not with standard +, but in general), whereas sum-list1 is rather forced to be sequential and eliminates this possiblity
23:57:30
Bike
usually when you compare algorithms you just compare number of steps, in some sense, but that sense is not defined here, yeah?
0:03:46
s3a
Bike, as a much-simpler approximation, though, the higher-order function uses the + function in an interative manner and so that is faster than recursion?
0:06:27
s3a
i didn't mean it like that. basically, iterative is always better performance-wise, right?
0:09:06
s3a
Bike, ok so whether + uses iteration or a binary tree, in both cases, it'd be faster than the recursive program from the non-higher-order function, right?
0:09:56
Bike
it could be written iteratively but really badly. what i'm saying is that you have not defined this for your question, so i'm going to avoid general statements
0:26:40
s3a
Bike, Hey. I'm back just for a quick question before going again. The apply function converts the list to a series of non-list arguments for the + operator?
0:28:20
Bike
with that kind of question i think it's helpful to just write a basic lisp implementation and see how it works
0:30:39
s3a
so, basically, the compiler just sees the (apply #'+ (list 1 2 3)) and switches it to (+ 1 2 3) with very little overhead?
0:31:07
Bike
in the general case, of (apply foo bar) where neither is known and the compiler can't do something like that, it still has to work
1:17:38
knusbaum
Looks like read-sequence will block until the sequence is filled or EOF. Is there a way to just read a bounded chunk from a stream, returning whatever's available, like POSIX read(2)?
1:36:12
knusbaum
My problem is regarding usockets. I have to be careful not to get into a situation where I'm blocked on a client who's never going to send anything, but I don't see how to do that without checking for available data before each call to read-byte.
1:47:04
knusbaum
Hmm. Looking for something in usockets to do that. Or should I be using something else?
2:37:02
emaczen
What is a file format for writing persitent objects? I was thinking (type :id id :slot-name slot-value :slot-name2 slot-value2 ...)
2:38:03
emaczen
Also, what would a typical access entail w.r.t opening the file reading in the data etc...
3:01:21
diegs_
Anyone used the dbus library? I'm trying to replicate this: https://gist.github.com/therockmandolinist/f2d3fbcde760435fd1ca98c83c335d4d functionality based on https://github.com/death/dbus/blob/master/examples/notify.lisp that example, but rather unsuccessfully
4:09:39
emaczen
Can someone point me to or give me an overview of how object persistence works, maybe even beyond the MOP?
4:35:04
beach
emaczen: I am guessing it is pretty messy in a system (OS + Common Lisp implementation) that was not meant for it in the first place.
4:36:54
beach
emaczen: You may consider looking at this one: https://github.com/robert-strandh/Clobber
4:49:15
White_Flame
emaczen: the biggest issues to deal with are serializing function objects and dealing with multiple references to shared objects
4:49:49
White_Flame
different libraries deal with such things in different ways. The only "standard" way persistence happens is saving your lisp image, which isn't even in the spec
4:54:21
beach
emaczen: If you can describe your needs, that might make it easier to give you advice.
7:22:24
jackdaniel
emaczen: cl-store is a very versatile and complete library for serialization, reading its sources may be beneficial
10:19:55
rk[ghost]
that brings up an interesting thought.. what do you all use for serialization of function objects?
11:08:25
_death
generally you avoid serializing those.. but see http://www.discontinuity.info/~pkhuong/common-cold/
11:40:26
phoe
generally you serialize those by (if at all) capturing their source code at compile time and storing the source code, then compiling it again during deserialization