freenode/lisp - IRC Chatlog
Search
10:54:26
BW^-
what's the point with the Find/Union thing in disjoint sets?? i see some literature and videos but what's the use case.. so .Find is supposed to tell you what. ranking at union time to decrease the search depth of the , works how??
11:07:19
p_l
phoe_: well, I have some code spelunked somewhere which deals with bytes from 1 to 64 bit long...
11:12:50
phoe_
I really can't stop being amazed by Lisp's ability to make read-time and compile-time assertions.
11:13:47
scymtym
Xach: ok. maybe a problem with their git repositories or the quicklisp project definitions, then. the DEF{METHOD,GENERIC} improvements seem to affect at least one other system, though
11:15:58
scymtym
if possible, i would like to keep the improvement if it doesn't cause too much trouble for you
11:16:10
Xach
https://github.com/mmaul/clml/blob/master/time-series/src/ts-anomaly-detection.lisp#L110
11:16:53
phoe_
random-nick: MOP is not a part of the ANSI Common Lisp standard, but is nonetheless adopted and supported widely enough
11:17:36
scymtym
Xach: probably https://github.com/sbcl/sbcl/commit/cdbde685bcb7371d45621752e5284194b4e8feaa
11:32:52
phoe_
Basically - I want to mutate a copy of a list, since the original is immutable, e.g. comes from a &REST somewhere.
11:43:09
attila_lendvai
Xach: forgot to pull to the live repos, should be fixed now (perec and meta-model were involved)
11:43:40
antoszka
phoe_: I'd say, copying the list ok, but change the name, to make your intention clearer.
11:44:30
Xach
I don't usually change the name - I often do (setf bar (copy-list bar)) or something like that.
11:45:31
_death
phoe: it's ok to copy to the list inside foo.. naming it may not be necessary if the function is made to do one thing only
12:05:56
pjb
(setf (car bar) (cadr bar) (cdr bar) (cddr bar)) ; but it cannot remove the last element.
13:00:07
attila_lendvai
Xach: I'm looking at that ql output. why does perec get loaded when loading hu.dwim.util.test ? to the best of my knowledge that shouldn't happen.
13:01:29
attila_lendvai
Xach: I mean, is there something ql specific magic, or I should dig in my own garden to find out why perec gets loaded?
13:03:01
attila_lendvai
Xach: never mind, I found it, it's :hu.dwim.util/production. maybe I should move that code away from there into another system, or address the TODO to get rid of the perec dependency
14:59:13
beach
phoe_: I concluded the same thing, which is why I no longer use any testing framework.
15:01:03
beach
Just random generation of test cases. It is probably not applicable in all situations, but for what I do it is fine.
15:02:29
beach
Same thing for Cluffer. I implemented the protocol with the "real" code, and with a simple, slow, stupid implementation in the form of lists.
15:03:21
Zhivago
The tricky bit is to prove that your random generator has relatively uniform coverage of the space.
15:03:26
beach
This testing technique makes for much less code, and I am much more confident that I have complete coverage.
15:04:28
beach
Zhivago: It doesn't have to be uniform. However, there are some other issues. For example, with complex data structures, all rare cases have to occur.
15:05:14
Shinmera
Test generation coupled with evaluation of branch/statement/flow coverage would be very interesting.
15:05:56
Zhivago
Which brings you back to pretty much the test cases you should be writing normally, with some icing on top.
15:07:52
phoe_
I actually think that I will need to stand upon the shoulders of a giant that is 1am.
15:08:23
phoe_
And create not a test framework, because Lisp has enough of these, but a test case management tool of sorts.
15:17:02
phoe_
As I said before - I want to be able to declare test case information like this: http://paste.lisp.org/display/351712
15:17:50
phoe_
And to be able to retrieve the test case information for further processing, such as HTML generation.
17:41:35
phoe_
I'll most likely turn CL-PROTEST into something that can use multiple testing frameworks, somehow.
17:53:33
phoe_
it was inspired by how Javascript frameworks are made - it is important to have a name and a logo before you have any unit tests
19:52:42
Xach
part of it is defining a little system that does something trivial but somewhat hackable and covering a few different aspects of quicklisp and CL itself.
20:24:42
Xach
I really wanted something so simple that everything you see on screen is easy to map back to its line of code.
20:25:40
rumbler31
does anyone know why apis that expose udp sockets don't give the application a stream to read, instead insist on returning vectors, and even then, only the amount of the packet that you asked for while discarding the rest?
20:26:47
slark
what do you think as a rule of thumb to use (gensym) for all macro parameters to avoid one of the leak describe in chap 8 of PCL ?
20:28:46
Bike
you should use gensym for any bindings you generate. you might not use a macro parameter that way.
20:28:48
slark
rumbler31: not sure what you want to mean, but as udp is not a reliable way to exchange information this is probably the reason
20:30:52
Shinmera
rumbler31: Because that's how UDP works. It gives you messages, not a continuous stream.
20:31:12
rumbler31
usocket, and I think ccl's socket api does the same. at least from what I'm seeing, repeat calls to socket-receive on a udp socket give me the beginning of new packets. If the whole packet is available somewhere, just queue them up. at the lowest level I'm sure that there is some vector backing a tcp socket, its just that the kernel will give you the vector in the right order
20:31:46
rumbler31
but is there really a use case for wanting part of the data in a packet and discarding the rest, as provided for by the api?
20:32:16
rumbler31
yes. but streams are an abstraction. the underlying data is still a vector even if thats not exposed to the user
20:32:49
Shinmera
UDP does not give you a stream, it's as simple as that. UDP gives you messages that may or may not arrive and they may arrive in any order.
20:33:06
Xach
tcp sequences those vectors and delivers them to the user level in a guaranteed order (or it doesn't give you any data at all)
20:33:56
Xach
ACTION always liked the "Interconnections" terminology of "best effort" rather than "unreliable"
20:34:16
rumbler31
yes, but if I go to receive from a udp socket, a whole packet was received, and unless I ask for the entire thing, the next time I call receive will return the next new vector, not what was left over and "not asked for" from the first vector
20:35:04
Bike
slark: you want to use gensym when a macroexpansion establishes some bindings. like, if the macro expands into (let ((foo ...)) ...), and foo is not supposed to be used by the user, it should be a gensym.
20:36:26
_death
rumbler31: udp has no packets, but datagrams.. it has no connection, so it is stateless, "fire and forget"
20:37:11
slark
rumbler31: you can still create your own protocol based on udp but it is overkill as tcp already exists and it will be still not reliable cause you can just works on the "application" layer
20:37:30
rumbler31
a datagram doesn't span a packet (afaik correct me if i'm wrong) so I consider datagram equivalent to a network packet
20:38:06
_death
rumbler31: tcp is a much more heavyweight protocol that creates a "virtual circuit", i.e. a connection between endpoints
20:38:31
slark
rumbler31: well i think you can say this, a network packet which doesnt care of his predecessor or the sucessor
20:39:04
Shinmera
rumbler31: I'm not sure what part you don't get anymore. Are you asking about the length argument to socket-receive?
20:39:29
rumbler31
I understand that udp has no guarantees. at the moment i'm wondering why, at the api level, I have to provide an expected size, which if there is more data than this gets dropped on the floor instead of being available for the next call for "more data"
20:40:03
rumbler31
Shinmera: and further why if there is more data left than this max size that the api drops it on the next receive call
20:41:56
Shinmera
As for why there's a length, your buffer might be less than the udp max size, so you can fill only what you need.
20:42:08
rumbler31
is it the case that if I haven't called socket-receive, that datagrams will get dropped on the floor, or will datagrams be queued (until some max os buffer size), st that socket-receive *will* return all datagrams seen by the interface to this point in time?
20:42:43
Shinmera
datagrams that you do receive should be queued by your OS, but there's probably parameters in your OS that control this behaviour.
20:43:24
rumbler31
Shinmera: so if you fill only what you need, what I'm trying to figure out is what kind of protocol would benefit from the default usage of "drop the rest of the datagram on the floor" vs "queue the rest of the datagram for a subsequent read"
20:43:24
_death
rumbler31: there is a queue, but you cannot rely on receving all datagrams, on receiving them as sent, on receiving them not being duplicated..
20:44:03
Shinmera
rumbler31: a datagram encompasses a "message". If you don't need the max size of the udp datagram for your messages you can read less than that.
20:46:13
_death
rumbler31: like I said, it is a stateless protocol.. so why should a udp implementation keep state for partial datagrams
20:48:31
rumbler31
if the datagrams arrive out of order, I will still need access to the whole packet, because I can not simply peek the datagram. If I peek it and I don't need it, great. but if I peek it and I need it, then I lost the rest of the data
20:50:20
Shinmera
UDP just gives you a thing to copy contents out of a buffer. Why is this so difficult.
20:50:55
rumbler31
what purpose is there, because there must be some, for a protocol that only cares about part of a datagram?
20:51:46
_death
rumbler31: that's the way it goes with udp, you tend to need more guarantees and you pay for what you need by building it yourself.. at some point it may cross the threshold where tcp may make sense
20:52:10
Shinmera
rumbler31: The length is there for the length of /your/ buffer, not the length of the datagram.
20:52:52
Shinmera
Right, so if you know your messages are only going to be 10 bytes, you make a 10 byte buffer and say the length is 10
20:52:59
Bike
your problem is that you don't see why the OS doesn't have a storage for packets inbetween receive calls? right?
20:54:10
Shinmera
Or you make a buffer that's more than 10 and store multiple things in it by still specifying the length as 10.
20:55:09
rumbler31
Bike: yes. although it probably doesn't have to be the os. Shinmera: yes, although really the datagram could be any size I suppose, or so i've been told.
20:56:06
Bike
so you could have a protocol where all messages are going to be ten bytes. and then you can save a couple picoseconds not bothering with partial reads and such
20:56:40
rumbler31
but thats up to the network, I might have sent 1000 bytes but the network could have made them arrive as 2 500 byte datagrams. and at that point there is no problem, I just read 500 expected more, read more
20:58:14
Shinmera
It gives you messages which have an upper bound in size. You send a message and you might get it at the other end.
20:58:40
rumbler31
I know it doesn't implement a stream. but If I write the max datagram size, I do not receive 1 64k packet, I receive 1 MTU sized packet
21:00:30
Shinmera
And the message you get is also internally consistent, so the UDP message itself will be properly consecutive. Individual UDP messages may be reordered though.
21:02:08
rumbler31
that part I should have known, but thank you for clearing it up. but even with this in mind, would anyone feel constrained with an api that presents the byte vectors from udp datagrams received on the interface so far as a stream?
21:02:56
Shinmera
You already have a full message there. There's no point in turning it into a stream.
21:06:19
rumbler31
but I guess, if I find that i've ended up with datagrams out of order and thats important, a stream interface alone would not tell me how much of the following bytes were received in the datagram
21:08:38
rumbler31
whereas if I have to keep the individual messages around, I know that when I start examining the buffer and its not what I need I can throw it out
21:09:47
rumbler31
and that the udp datagram reception call, if a stream is returned, its only temporary because I'd have to read from a new stream on a new call
21:46:44
MrSleepy
Hello do people generally do graphics and gui programming in lisp using some sort of foreign function interface, or is there a more native approach to that sort of thing?
21:49:52
MrSleepy
Well generally just drawing to the screen. I am totally not very knowledgable about it graphics in general. My main experience is through tcl/tk and Qt in C++ but that isn't really drawing in the low level sense.
21:55:28
MrSleepy
phoe_, I just checked it it seems really useful, I also peeked at #lispgames and some of the resources in their motd seem useful too
21:59:09
z3t0
MrSleepy: For advanced things look at cl-opengl and lispbuilder-sdl and for a more high level interface look at sketch