freenode/#lisp - IRC Chatlog
Search
13:52:59
_death
remexre: you can add in-array to iterate.. or you can use a displaced vector (make-array (array-total-size array) :displaced-to array)
14:12:18
remexre
_death: oh, didn't know you could use displaced-to that way, I thought they were like slices
14:21:51
flip214
remexre: if you want to loop across a multi-dimentional array, you can use (DOTIMES (i (reduce #'* (array-dimensions array))) ...) and a (row-major-aref array i)
14:25:06
flip214
heisig: ah yeah, thanks. I thought there's some function for that, but CLHS ROW-MAJOR-AREF doesn't cross-reference it
14:36:08
flip214
Shinmera: sorry, got distracted and didn't read all the new lines before completing mine.
14:38:04
Shinmera
I'd like to go, but I don't know if I can. Austria is close to me, but it's right during busy university time.
14:57:51
Bike
also yeah, if with-mongo-connection evaluates those arguments you don't need them in the macro
15:03:19
katco
Xach: i was playing with zs3 and digitalocean's spaces last night. i am unsure if i have the time, but are you open to new issues? prs? is the project still being maintained?
15:06:57
flip214
Bike: but defering constant macro constant expansion to compile time makes the comparison to C++ compile times worse! Raaaaah! ;)
15:09:22
dlowe
hard to compare compile times meaningfully when you can insert arbitrary computation into your compiler
16:06:49
thijso
So, how can threads make usocket:wait-for-input barf? I have minimal code, depending on verbose and usocket, and when I open a UDP socket (socket-connect) and then do (usocket:wait-for-input ..) with some error logging, every second or so I get: "got error #<a USOCKET:UNKNOWN-ERROR>; restarting server in 0.1 second"
16:07:41
thijso
This is on ECL, btw. I know verbose starts up a controller thread ( #<process "verbose-thread" 0x55f6f1219d00> ) but I'm not seeing how this can interfere with the socket.
16:08:20
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=a372d28d will be valid until 16:15 UTC.
16:09:29
thijso
The socket implementation in ECL goes through a call to read-select on the socket, which does a c call 'select'
16:51:32
minion
The URL https://gitlab.common-lisp.net/users/sign_in?secret=8690c457 will be valid until 17:00 UTC.
17:01:14
remexre
is there a way to make a struct with a :type that includes that type as its member?
17:02:42
Bike
it means an "instance" of foo is actually a bit vector. so of course it can't have a slot that's another bit vector, its slots can only be bits
17:03:32
Bike
i'm talking about the defstruct :type, not the defstruct slot :type, just to be clear. they're different things
17:04:09
remexre
I thought it made it a subtype, so it'd "inherit" all the functions of the representation
17:04:24
Bike
But with more slots or something? No, there's no capability to subclass built in classes in the language.
17:07:30
Bike
Would it be possible for you to use different printing functions in different contexts? Like call print-as-ip instead of print.
17:07:43
Bike
If not, you might be able to manage it with the pretty printer but it'll be kind of weird.
17:08:40
Bike
You could also make an object that wraps bit vectors, i.e. has a slot that's a bit vector, and have it print however.
17:09:56
remexre
I'm doing something evil with the values though, so I need e.g. aref to work on the object
17:10:58
beach
remexre: It is very strange to hijack the built-in functions like the printer and AREF and such for application purposes.
17:11:26
beach
remexre: Your application should build its own types, and its own protocol functions for those types.
17:12:37
beach
remexre: You can consider an array (including a bit vector) to be a "concrete data type", i.e. it is meant to be used for implementing abstract data types for your application to manipulate.
17:13:40
beach
remexre: So, again, it is very strange to just import the built-in concrete data types as your application types, and then try to twist the way these built-in concrete data types are accessed, printed, etc.
17:15:10
Bike
if it's causing you problems you might want to consider its evilness is an unironic way
17:17:23
Bike
if you tell me something is evil, and that it's causing you problems, but you don't elaborate beyond that, i'm pretty much going to have to stop at "don't do the evil thing"
17:52:51
katco
Xach: ok, thanks. i've only done a cursory examination, but i think it might be an issue with the unmarshaling of xml being inflexible. are you open to prs? or issue first, with some discussion?
18:28:07
thijso
Shinmera: I'm looking at verbose again, and run into another error on ECL, namely when I stop the *global-controller* it gives a SIMPLE-ERROR with the msg: "Cannot interrupt the inactive process #<process verbose-thread 0x5556eee81700>"
18:29:11
thijso
Maybe I should just give up. Something in my stack just seems not mature enough to use. ECL, bordeaux-threads, usocket, verbose, I don't know.
18:29:40
thijso
I have a feeling it's actually ECL, but I could be wrong. I'm surely not the only one trying to use it for something more than just playing around...
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