10:57:35no-defun-allowedI was drawn to Lisp since the other alternatives I knew were Java (which required a bulky IDE that was too slow on my dinky computer at the time for any serious work), Haskell which I couldn't read, C or C++ which I could read better but couldn't ever get to work, Python which was slow, and BASIC which requires no justification really.

15:03:19katcoXach: 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:57flip214Bike: but defering constant macro constant expansion to compile time makes the comparison to C++ compile times worse! Raaaaah! ;)

15:09:22dlowehard to compare compile times meaningfully when you can insert arbitrary computation into your compiler

16:06:49thijsoSo, 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:41thijsoThis 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.

17:11:26beachremexre: Your application should build its own types, and its own protocol functions for those types.

17:12:37beachremexre: 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:40beachremexre: 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:52:51katcoXach: 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:07thijsoShinmera: 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:11thijsoMaybe 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:40thijsoI 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...

20:11:39BikeOr 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:07thijsoSo, 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:36thijsoFor some reason the timeout on the condition-wait is interrupting the call to socket-receive.

21:25:03thijsoI 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

22:30:54gordonfish(Sort of like saying "learn C" but it's actually C++ or C#, heh)

22:35:22edgar-rftgordonfish: 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.