freenode/#lisp - IRC Chatlog
Search
19:17:43
_death
remexre: actually you can easily extend the pretty printer to print such objects in a special way
19:19:36
_death
remexre: the pretty printer function can discriminate objects in any way you see fit, so for example you look them up in some registry to know their semantic type..
19:21:24
_death
remexre: if you need it for interactive use, and use slime, then I have a patch that might be interesting https://github.com/death/slime/commit/abcaefe272394799f151bb6ff8232cb9e456f55a
19:37:35
_death
there are limits in your use case though.. for example if you (copy-seq ip-address) the resulting vector will print ordinarily
20:05:42
thijso
Why do I get a TYPE-ERROR in identical code when I switch from (declaim (space 1)) to (space 2)?
20:10:02
thijso
Yeah, so then I would expect to get *more* TYPE-ERRORs with lower priority to space, right?
20:11:39
Bike
Or for example, with higher priority on space, it might try actually enforcing dynamic-extent declarations it didn't before, which might entail being stricter about some types so it knows what sizes to allocate
21:15:07
thijso
So, I have an issue with usocket, bordeaux-threads, and ECL. A blocking (or with timeout) call to usocket:socket-receive will give an USOCKET:UNKNOWN-ERROR if there is a bt:condition-wait call being done with a timeout on a different thread.
21:15:36
thijso
For some reason the timeout on the condition-wait is interrupting the call to socket-receive.
21:21:06
fe[nl]ix
thijso: https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-ecl.lisp#L75
21:25:03
thijso
I also see an issue in ECL that might have something to do with this. The line "but the short answer is that alarm is delivered to the signal servicing thread during handling another thread." is making me suspicious. This is in https://gitlab.com/embeddable-common-lisp/ecl/issues/420
21:52:10
thijso
I've created an issue in ECL: https://gitlab.com/embeddable-common-lisp/ecl/issues/525
22:23:35
gordonfish
Where does the filter built-in come from? In sbcl I get "The function COMMON-LISP-USER::FILTER is undefined"
22:25:57
gordonfish
edgar-rft: Curious; where did they get it from at this link (#7) https://hackernoon.com/learn-you-a-lisp-in-0-minutes-e0c1a060a178 ?
22:26:31
gordonfish
I was just reading that page but the examples look a little different from what I normally see.
22:29:04
edgar-rft
gordonfish: the tutorial says "I should specify that this test is based on WeScheme."
22:35:22
edgar-rft
gordonfish: Lots of people (like the author of that tutorial) confuse Lisp and Scheme :-) Scheme is technically a LIsp dialect, but the Common Lisp standard was meant to unify all other Lisps into a single Lisp language. Nontheless Scheme still has an active community on #scheme.
22:52:32
adom`
Hi! I'm wondering about concatenating arrays with concatenate. Is it more efficient in runtime than setting each element to each corresponding index? Where can I find information about that kind of thing?
22:53:29
no-defun-allowed
Unless the array has a fill pointer and can fit both array's active elements, I don't believe you can "set each element" since there would be no room for the other array's elements.
22:54:32
adom`
And then I want to delete an element from some index and then fill the space it was in. And move each element by one.
22:54:45
no-defun-allowed
And you can probably assume NCONCATENATE is faster than CONCATENATE ever so slightly because it may use the first array as storage instead of allocating a new one (which is basically just incrementing a pointer on most implementations).
22:56:21
no-defun-allowed
So you're doing something like (concatenate 'vector (subseq vector 0 n) (subseq vector n))?
22:57:08
no-defun-allowed
Yeah, you'd be iterating over the array three times (or two if you count each subseq as "half").
22:58:11
no-defun-allowed
No, a vector is layed out as contiguous memory (on a self-respecting implementation) and each element takes O(1) time to aref.
22:58:19
Bike
anyway, you can make a vector of 1- the length of your starting vector, and then call replace twice
22:58:37
no-defun-allowed
But to subseq, the implementation would probably make the new vector, loop over the old elements and set the elements of the vector.
22:59:05
no-defun-allowed
To concatenate, the implementation would make the new vector with size the sum of the input vectors and loop over those elements too.
22:59:20
adom`
oh I see. I was misreading. You were just saying 2 new vectors (1 for each subseq... it's very clear now)
22:59:47
no-defun-allowed
All up, it'd iterate over the vector length twice, as opposed to just once (worst case, or half in the average case).
23:00:46
Bike
with the concatenate subseqs you'd actually have three new vectors, since concatenate makes one too
23:02:58
adom`
I'm still unclear on whether concat/replace is just doing the same iteration I would do
23:03:33
Bike
the concatenate function essentially: gets the lengths of all the sequences, makes a new sequence with the summed length, and then iterates over the sequences.
23:03:49
no-defun-allowed
I still believe iterating over the vector an average of two times rather than half of the vector is the slowest part.
23:06:09
adom`
Thanks bike/no-defun-allowed. But yeah, is there documentation that says this kind of thing clearly? Like the O(n) of different builtins?
23:10:12
aeth
adom`: you don't need to iterate, either. If what you're doing is what no-defun-allowed said and it's (concatenate 'vector (subseq vector 0 n) (subseq vector n)) then you can just use replace twice to skip having the inefficient subseq and to skip having to manually iterate
23:11:52
aeth
So you can e.g. just replace the upper range and the lower range of a fresh vector from the two source vectors (or ranges of one vector).
23:22:57
pjb
Now, you could displace sequences to arrays, and concatenate the sequence, then displace an array to the resulting sequence. But you would have to find some consistent dimensions.
23:24:08
pjb
Finally if you are considering sequences, try to implement concatenate yourself, and see if you can find a more efficient way to do it.
23:24:40
pjb
If you don't want to implement concatenate yourself, you can always go have a look at the sources of your implementation.
23:25:31
adom`
I haven't really gone through the basics yet, so it wasn't obvious to me that a vector was not a sequence. I should definitely learn that stuff though.
23:25:55
adom`
And yeah, checking the source of my implementation definitely seems like the way to answer my question
23:27:18
pjb
adom`: well, checking the source of your implementation is a nice way to get some idea, but it is also dangerous, because you will see one specific implementation, but Common Lisp is a language, and several different implementations are possible.
23:30:22
pjb
adom`: now, the CLHS doesn't specify in general the algorithms or the complexities of the operators. Only for a few operators, some hints or some restrictions are given. But since there are several competing implementation, they will often use the best algorithms they can.
23:32:10
pjb
adom`: as indicated, the constraint on concatenate, is that it must return a new sequence. Therefore the only overhead, beside copying, is that it must allocate the space of the result. The advantage is that it's purely functional: you will be able to mutate the result without having an impact on the pre-existing sequences.
23:32:20
aeth
This differs from how some other programming languages handle this. For instance, in C++ a vector basically an adjustable vector in CL terminology and there are C arrays and there are new std::arrays and, well, C++ probably was a poor choice of comparison
23:33:35
pjb
adom`: you may design an algorithm where you could pre-allocate the space of the result, and use REPLACE instead of CONCATENATE to store it repeatitively, without having to allocate it each time.
23:33:35
aeth
Unlike some languages, CL has true multi-dimensional arrays. You don't need to put an array-in-an-array, or use 1D arrays with special accessors to pretend that it's 2D (or more)
23:34:22
pjb
adom`: you can also use a vector with a fill-pointer if the result size may change, or an adjustable array if it may extend what you pre-allocated.
23:35:45
aeth
And vectors that aren't special in that sense are 1D simple-arrays, but not necessarily simple-vectors, because simple-vectors have to be T 1D simple-arrays, iirc.
23:40:34
aeth
from the perspective of the type system, arrays have three relevant components: simple or not, the type they can hold, and the dimensions. 1D arrays no matter what are vectors (and vectors are sequences). simple-arrays are simple arrays, and simple-vectors are T simple vectors, not just simple vectors. The length (or dimensions) is part of the type, but usually it's * for anything and often even that is optional.
23:42:16
aeth
And in case the "type" thing is unclear, an array/vector that holds T holds anything, since any type is a subtype of T (except NIL, but nothing is of type NIL, even the object nil is of type NULL, and not of type NIL).
23:44:02
aeth
(The standard mandates character (1D character arrays are strings... yes, strings are just vectors) and bit, but practically speaking (unsigned-byte 8), informally octet, is near-mandiatory. Other integer sizes vary, but are usually included if they're signed/unsigned 8 16 32 64 as well as fixnum, and single-float/double-float are included in everything but CLISP.)
23:45:01
aeth
(You'll also see base-character, etc. The pattern is that it's basically just for numbers and characters.)
23:47:29
aeth
I think that covers everything that arrays can do, normally via make-array. http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_ar.htm
2:02:54
raghavgururajan
Hello Folks! I am trying to learn LISP for first time. I am interested in Common LISP, Emacs LISP, Scheme and Guile. Should I be learning these dialects in particular order? Thank you!
2:03:33
Bike
i don't think there's any required order. also, this channel is actually for common lisp specifically. i think the "general" channel is ##lisp or so
2:04:07
no-defun-allowed
Learn Common Lisp, don't learn Elisp if you want to do work outside of Emacs with it (since, well, you can't), Guile is Scheme so learn Scheme after, and do all that after you remember to release the Shift key after writing the L in Lisp.
2:12:21
no-defun-allowed
Is there an external-format I can use to read lines from a "DOS-formatted" line with CRLF line endings without having nasty CRs at the end of those lines?
2:16:24
no-defun-allowed
Never mind, I'll use (remove (code-char 13) <string>). It'd have to work in ABCL too.
2:36:46
fengshaun
and https://sourceforge.net/p/sbcl/sbcl/ci/master/tree/ is hard to navigate for someone unfamiliar
3:02:12
beach
fengshaun: APPLY would not be a Common Lisp function, so SLIME probably can't find it.
3:10:05
White_Flame
however, there are compile-time shenanigans happening too, so each of the hits that M-. brings up is some different path it might take
3:10:33
White_Flame
since DEFUN APPLY calls APPLY itself, that inner APPLY is actually something different
3:11:28
beach
I don't see how that could be done in Common Lisp, because it would involve direct access to machine registers and such.
3:12:30
White_Flame
inside DEFUN APPLY, there are type checks on the parameters. The nested APPLY then is in scope of when types are known, and compiler shenanigans do the low-level replacements there
3:14:01
White_Flame
and of course, if the types are known in user code (basically if the last parameter is a list), then the shenanigans can happen there directly
3:40:48
pjb
beach: I don't know about sbcl, but in ccl, slime usually can find the source of CL operators.
3:46:21
ck_
pjb: this looks to be more of a 'implementation platform" problem. More to do with windows than sbcl.
3:51:18
beach
pjb: What I meant was that fengshaun should not expect the code that spreads the argument to be written as a standard Common Lisp function.
3:54:18
pjb
Yes, but at least you should get some sources. It's true that it won't necessarily be clear, unless you know the internals of the implementation.
4:39:22
fengshaun
beach, no, it found the definition and I looked it up, it's a 'normal' cl function
4:39:45
fengshaun
pretty much cons'es the list together so the end result is it removes one layer of nesting
4:53:06
beach
fengshaun: Oh? So how does it pass the arguments to the function being called? I would be surprised if it conses anything at all.
4:55:35
beach
I can see that, in some implementations, every function would receive a list of arguments, but that would be a not-very-efficient implementation.
4:56:45
beach
fengshaun: An efficient native-code Common Lisp implementation would pass arguments in registers and on the stack, and neither the registers nor the stack are available to a standard Common Lisp function.
4:58:04
ck_
beach: I'd guess this is the source code they're looking at: https://github.com/sbcl/sbcl/blob/master/src/code/eval.lisp#L328
5:03:02
beach
But yeah, it seems to be consing. The comment suggests that this is not the way it is typically handled though.
5:22:36
beach
fengshaun: The SBCL compiler treats a lot of stuff specially. For example, here is the definition of the function CAR: https://github.com/sbcl/sbcl/blob/master/src/code/list.lisp#L30
5:38:48
no-defun-allowed
The representation of stuff isn't specificied in the CLHS, so it's probably useless if you want to read about the implementation of CAR.
5:39:39
beach
CAR was just an example of how the SBCL treats things specially. Nobody expressed interest in the implementation of CAR.