15:37:32beachdbotton: I am sorry to hear that. Because then the books are not describing the Common Lisp language correctly.
15:38:51beachAnd in fact, many examples in the Common Lisp HyperSpec also use SETQ directly. But then, examples are not normative, and it is clear that they were not worked on enough.
15:39:20pjbThey're not self-sufficient chunks of code. They assume the reader understands that.
15:39:39beachYeah, there is that. Still, it is not great.
15:40:09dbottonpjb I am not convinced that they assumed the reader understands, it seems most lisps were ok with it
15:41:02dbottonMaybe sbcl should say something on first warning about it
15:43:00beachBut this latter case is unfortunately defined by the standard.
15:43:08beachSo only a style warning is justified.
15:43:30AadVersteden[m]It is handy when doing quick and dirty experimentation on the repl. I like the way it works with warnings. Warnings are real warnings with SBCL.
15:44:03beachAadVersteden[m]: Why is it more "handy" to do SETF than DEFPARA
15:44:48beachAadVersteden[m]: If you just get into the habit of using DEFPARAMETER instead, then you get the same effect, AND your code is conforming.
15:44:55AadVersteden[m]I rarely ever do that, but for generic functions it can be nice.
15:45:58beachAadVersteden[m]: It is a trade-off as usual. Quick to do sometimes, hours of wasted debugging time some other times.
15:46:25AadVersteden[m]I can imagine other people sharing a different opinion, especially due to the length difference between setf and defparameter (which is silly, I know, but some people seem to have their keyboard in a time dilation field)
15:46:54dbottonIs there a common object database solution being used these days with CL? Or other non-traditional database?
15:46:55beachDefine an Emacs abbrev "dp" for DEFPARAMETER then.
15:47:26AadVersteden[m]It's probably in the spec for compatibility with other lisps, I guessed. For setf that is, for implied defgeneric: no clue.
15:48:14Fadecalling setq on an indeclared variable seemed to be the style in the seventies in the maclisp days.
15:48:41FadeI tend to view pretty much all uses of setq in real code as archaic at best, but a smell for sure.
15:49:08AadVersteden[m]dbotton: I constructed some approaches. The broader ecosystem has some interesting approaches. Much would depend on what you're looking for.
15:49:14beachFade: Sure, but SETF is also not allowed on undefined variables.
16:36:37dbottondid it work well? Is there an automatic persistence to disk? ever have data loss issues?
16:42:56beachdbotton: Often, I just use PRINT with a special syntax for instances of standard classes, so that I can use READ to read back my entire data structure of the application model.
16:43:10beachThat idea might not be acceptable to you of course.
16:43:53AadVersteden[m]<dbotton> "did it work well? Is there an..." <- used it, was fun. Worked. Built something else later.
16:47:44dbottonbeach have an example of it easily available?
16:48:41beachI do, but dinner is imminent here. Maybe hayley or Bike can help. We use this system for external representations of ASTs in SICL.
17:06:37Josh_2I have also found a bug with bknr where previous instances stored in the db do not take a slots :initform when you add new slots to an already existing class
17:06:57Josh_2I dont think i'm going to use bknr anymore
17:07:49Josh_2I think for a persistence library for a program like Nyxt then I think it would fit perfectly
18:33:49nij-When an error is signaled and unhandled, a debugger is invoked. Backtrace could sometimes be helpful, but not always. For example, the experience today is that the backtrace skips so many steps.. and to manually find out what the problem is it took me one hour.
18:34:17nij-Given the rant, the question is why is this the case? Is it a hard problem to make the backtrace better and more informative?
18:34:51White_Flamedo you have a bunch of tail calls?
18:35:30White_Flame(defun a () (foo) (bar) b) (defun b () (baz) (bort))
18:35:47Bikearranging good backtrace info can be kind of an ordeal for an implementer, it's true. and a lot of optimizations (or really, most) eliminate stuff you'd want to keep for debugging. but probably you had a low debug setting and so it didn't save all possible debug information.
18:35:51White_Flamewhen A calls B, that's a tail call (eg, wont' return back to A), so A's stack frame can just be replaced by B's and isnt' noticeable anymore
18:35:52nij-In principle, for any thread at any time, a function calls a function and so on.. so isn't it in general possible to have the backtrace to have every function which is now on the stack?
18:36:23White_Flamea tail call reduces to just a cheap jump and a little stack shuffling
18:36:41White_Flameespecially when you're recursing
18:37:00nij-White_Flame Is there a way to "turn off" that optimization, just for a faster debugging experience?
18:37:09nij-And yes, I think there are many tail calls.
18:44:57Bikelike i said, a lot of useful optimizations will screw things up for a debugger. the basic point of an optimizing compiler is to turn your code into some completely different code that has the same overall effect without actually performing every operation exactly as written
18:45:30Josh_2You could maintain two versions, a test and a live, in the live you can enable safety 1 etc
18:47:03Josh_2"How much error checking should be done. If speed, space or compilation-speed is more important than safety, then type checking is weakened (see weakened-type-checks). If safety if 0, then no run time error checking is done. In addition to suppressing type checks, 0 also suppresses argument count checking, unbound-symbol checking and array bounds checks."
18:47:04nij-safety 3 means..? it doesn't check at all?
18:47:22Nilbynij-: to rebuild a system with debugging on: (uiop/lisp-build:with-optimization-settings ('((debug 3) (speed 0))) (asdf-load :your-system-name :force t))
18:48:11nij-so conclusion: while programming, set debug and safety to 3, and speed to 0.
18:49:41White_FlameI tend to make macros for things, so I can set a flag, which will generate my declarations one way or the other
18:50:22Josh_2My live systems are also built on this machine so even they have safety 3 speed 0
18:51:34hexologydo you use some kind of cross compilation, or do you develop on the same os that you deploy on?
18:52:16Josh_2enabling safety 3 debug 3 initially caused me some issues because I was setting slots to incorrect types, but because of the sbcl defaults this was ignored
18:52:25hexologyim also very curious what people use lisp for in production nowadays. id have a very hard time convincing a manager to let me use lisp at work, even if its something i solely maintain!
18:52:57Josh_2hexology: My machine and my VPS are both linux, not the exact same OS though
18:52:58nij-hexology Have you tried writing codes in lisp, and write wrappers for other people to use?
18:53:19hexologyJosh_2: makes sense, i guess linux + x86 is pretty much standard
18:53:25nij-You can now deploy lisp codes as C libs easily.
18:54:55hexologyso instead of an executable it produces a shared library and you can call individual functions therein
18:55:08nij-yeah I think we need more things like this
18:55:23hexologythat actually makes a lot of sense. file size is probably big but file sizes on shared libraries can get pretty big in scientific software anyway
19:04:13Bikea while ago a quant consulted with me a bit about how to improve clojure's compiler to be better at arithmetic like common lisp is.
19:04:19Josh_2As far as I'm aware they were using Clojure top to the bottom with a tiny amount of C here and there
19:05:21Josh_2Ofcourse they were paying big bucks for a commercial implementation of the JVM
19:05:36hexologythats interesting, i thought the jvm was known to only be so-so for numerical computing
19:06:40Bikethe general impression i got from him was that as far as actual numerical performance goes, clojure is middling to terrible, indeed.
19:06:52Bikebut this is apparently not always a big deal for fintech.
19:08:58White_Flamedepending on the trader, fintech often does not do a lot of math
19:09:18White_Flamemany of the algos are very simple accumulators and looking for trigger conditions & thresholds
19:10:12Josh_2I do not think that my frens business was numerically intensive, it was more about placing orders in the right place at the right time as fast as possible
19:17:26nij-But I think it'd be more practical to export lisp code as C(++) libs.
19:17:32nij-Most big players out there still use C++.
19:18:00nij-You either pick a lisp team, convert your c team into a lisp team, or export your lisp code to C++ libs.
19:18:09nij-The latest sounds the most achievable to me.
19:22:34hexologyim still a bit surprised that they went for clojure and not lisp
19:22:42hexologynot that i have anything against clojure