freenode/#lisp - IRC Chatlog
Search
22:03:30
no-defun-allowed
If you are going to use jsown, I would strongly suggest you go into the sources and change every (declaim (optimize ... (safety 0) ...)) to (safety 1) at least, because you will get some very strange conditions if you make a mistake otherwise.
22:08:57
phoe
does the standard actually guarantee that top-level DECLAIM OPTIMIZE settings do not leak out of the currently compiled file?
22:10:00
no-defun-allowed
"As with other defining macros, it is unspecified whether or not the compile-time side-effects of a declaim persist after the file has been compiled."
22:10:44
no-defun-allowed
I'm not good at reading CLHS-ese, but I think this means there's no guarantee.
22:14:28
no-defun-allowed
Can't say, but it's still incredibly impolite to use (SAFETY 0). I had to spend a good half hour debugging with a friend because we got memory faults by giving it the structure (:obj ((a . b) ...)) instead of (:obj (a . b) ...)
22:26:29
no-defun-allowed
(EVAL-WHEN is one of the parts of CL I don't get, so I think you should wait for someone more knowledgeable to answer.)
23:06:12
aeth
no-defun-allowed: yet another piece of evidence that every JSON library for CL that I've heard of is awful
23:07:16
aeth
For whatever reason, every JSON library looks to me like an irredeemable failure that fails to understand either CL or JSON. I've ranted about that before here, though.
23:31:35
no-defun-allowed
aeth: I have a *very* large JSON file I want to analyse, so I will probably have to make my own with some kind of "stream"ing.
23:32:28
no-defun-allowed
And I remember jsown didn't understand some part of the \u syntax until recently, FWIW
23:44:21
jfrancis
I got almost three years into a work project using cl-json before hitting a missing feature that forced me to jsown. That was six months ago, and I still haven't gotten around to re-writing all the cl-json stuff with jsown. I just have one single file that uses jsown instead of cl-json. Every time I look at that project and compare it with all the features I have yet to complete, it moves further and further down the list of priorities.
23:45:00
jfrancis
Which is why good software projects have project managers, to force stuff like that up to the top.
23:47:44
White_Flame
of course, that's also why having application-specific functions which wrap your libraries are also good
0:14:15
Josh_2
I keep getting the error bad-file-descriptor when calling socket-accept on my listen socket, the fd is -1 for some reason
0:17:59
aeth
jfrancis: Well, I think you brought up a good point with project managers, but most people do CL on their own time, in which case the problem is motivation, so the order to do things in imo kind of reverses. Instead of building a solid foundation of libraries and then the application, you need to get a MVP of the application/library done as quickly as possible to maintain motivation. At least, imo/ime.
0:18:22
aeth
So it doesn't surprise me that people work with an 80% good-enough JSON library instead of writing a perfect fit one, even though 80% good-enough isn't actually good enough.
1:28:55
lavaflow
from what I understand common lisp doesn't guarantee tail call optimization in every scenario, but does it in any specific circumstances, like a procedure invoking itself in the tail position?
1:29:42
lavaflow
I'm reading land of lisp and some of the examples have procedures invoking themselves in the tail position to loop. I thought that was a scheme-ism
1:34:05
Xach
lavaflow: implementations might convert calls like that in some circumstances but nothing is guaranteed by the standard
1:38:21
PuercoPope
no-defun-allowed: an alternative to modifying the sources, if you use SBCL, is to restrict the compiler policy. ie. (restrict-compiler-policy 'safety 1)
4:31:18
vsync
huh... why is it allowed to have a zero-dimensional array? or more properly, why does a zero-dimensional array have an element?
4:32:37
aeth
vsync: (make-array '() :element-type 'double-float :initial-element 4d0) ; now you have a box
4:33:15
no-defun-allowed
The size of an array is the product of its dimensions, i.e (apply #'* (array-dimensions <the array>)).
4:33:16
aeth
vsync: a 0D array of a double-float or (unsigned-byte 64) or (signed-byte 64) in 64-bit implementations that support such optimizations is essentially micromanaging your own box instead of automatically heap-allocating that number
4:34:59
aeth
vsync: technically speaking if you're writing hyper-optimized numerical code it's more efficient to pass in a 0D double float array containing an element and then optionally perhaps setting that with the new result rather than actually passing in a heap-boxed double float. Do you need to do this? Probably not. Does a library you use that wants to compete with C/C++/Fortran need to do this? Maybe.
4:35:15
pjb
(mapcar 'array-element-type (list (make-array '() :element-type 'double-float :initial-element 4d0) (make-array '() :element-type 'number :initial-element 4d0))) #| --> (double-float t) |#
4:35:55
aeth
The difference between a length-1 array and a length-() array is (aref foo 0) vs. (aref foo)
5:48:38
vsync
haha, turned out I could just do what I wanted with (map-into (make-array N) #'WHATEVER)