4:11:43beachblep-on-external: Either you have TABs in your code that pastebin can not handle, or you line starting with COLLECT is incorrectly indented.

6:51:29shrdlu68"In general, Common Lisp is a type-safe language. A Common Lisp compiler is responsible for inserting dynamic checks for operations whose type safety cannot be proven statically. However, a programmer may indicate that a program should be compiled with a lower level of dynamic type-checking." -- What does (safety 0) do?

6:52:10shrdlu68Does it mean I won't get the usual "var is of type X, expecting type Y"?

8:08:40beachjackdaniel: The concept of a standard that is independent of implementations and of the organizations that supply implementations is pretty hard to grasp, especially these days, when single-implementation languages and benevolent-dictator languages are not only commonplace, but also used by industry projects that think of themselves as being serious.

8:17:17jackdanielI like to look at standards from the humanism standpoint

8:21:24beachBut, and I know I have said this before, for any industry project that thinks of itself as being serious, using a language with an independent standard is a must, or else they must take precautions and figure out what to do if the "language" they have chosen should disappear, quit being maintained, or be altered in some major way.

8:21:46beachThey might have to hire compiler experts then. And they probably don't even know where to find one, nor what to pay such a person.

8:28:00dimbeach: what about companies using their own home-grown and home-steered projects/language, such as Google with Go or Mozilla with Rust (I think), or Oracle with Java?

8:40:29aethakkad, jackdaniel: I find a good compromise between painful portability and no portability is to write for one implementation and then test it on one or two supported others. Technically, they could all violate the standard in the same way, but at least you're not tied to *one*

8:42:49aethIt's pretty easy to run on both SBCL and CCL. On the other hand, ABCL and CLISP are probably the hardest to support.

8:43:17CymewAren't CLISP that old crap that should just go home and die?

8:45:24dimas soon as that's possible, I'll have a look at having pgloader.jar and also using JDBC on that platform, that'd be great really for supporting some commercial databases and other niche ones

8:45:43aethCymew: CLISP is the interpreted implementation that's semi-active (no new release in a long time, but not dead), but tons of resources from 2000-2010 recommended it so it'll live for a long time.

8:46:00White_FlameI don't recall CLISP ever being characterized as being incompatible

8:46:01aethIt's also possible that it'll be active again because it's not dead.

8:47:01White_Flamethe 3 major things is that it's slower than native compiled implementations, it has fast bigmath, and it's easy to get running on new/unsupported platforms

8:47:05CymewWhite_Flame: I have read descriptions of its implementation of CLOS to be very peculiar.

8:47:26beachCymew: karlosz is in fact writing a Cleavir-based compiler for CLISP as a GSoC project.

8:50:03aethI'd say that the most annoying thing about CLISP is that it doesn't support single-float and double-float specialized arrays. When a specialized array isn't supported, you just get T arrays instead. *Tons* of libraries assume float arrays (or byte arrays) even though the standard only requires bit and character arrays. Those libraries will (slowly) run in CLISP, but without any sort of benefit in the type system.

8:51:23aethImplementations with long-float (not just CLISP) also have an interesting issue with pi. pi is technically long-float, but in most implementations that's also a double-float so some people erronously assume pi is a double-float. So CLISP has the opposite issue there, where it supports something (long-float) that most popular implementations don't.

9:00:38White_Flameyeah, flexi-streams will build a vector for me, then I need to convert to simple-array to give it to the websocket lib

9:02:09_deathflexi-streams has many faults.. some of them can be fixed without creating backwards compatibility issues, but that particular one I'm not sure

9:02:16aethA simple-array is usually what you want if you even remotely care about performance (assuming you're not using one of the features that a nonsimple array has). It gives more guarantees as to the structure of the thing.

9:08:17aethYou would need some way to communicate that it's only meaningful up to a certain index. A general library should probably just use the 2nd return value to do it, but I'd personally put it in a struct to store the value.

9:09:07aethObviously this is probably going to waste space (but also risk running out of space), but make things faster.

10:07:57lthmsanyone really, I don't have any strong opinion on the matter

10:07:59phoebeach: I'm alive, I just did things that I didn't really enjoy doing. The stuff that's required to function and such, but nothing really enjoyable.

10:08:37phoelthms: that's a pretty big question when it comes to choosing databases though; what are your needs? what kind of data will you store? what functionality for modifying and retrieving it will you need? how is your data modeled and structured?

10:08:51White_Flamelthms: threads, messages, just the same as any other language. Just make sure your DB connector library is threadsafe

10:09:16phoebecause there are object stores in pure Lisp, there are bindings to various SQL and NoSQL databases out there.

10:09:47White_Flamelthms: depending on your workload, maybe put your requests into a job queue and have some fixed number of DB connections pulling from it

10:10:15White_Flamebut again, that's no different in Lisp than any other language

10:10:45phoewell, yeah, I've been using postgres recently and it's just a matter of making ten connections to the database, and suddenly you can have ten DB queries running at once.

10:11:30lthmsphoe: which lib did you use to use postgres? I saw there are plenty