libera/#commonlisp - IRC Chatlog
Search
12:05:55
kami_
I am sure I've asked this at least once in the past (on freenode), but I'm getting old ... so: what are my options if c2ffi says 'Not all C basic types are covered! The outlier is: :long-double' on x86_64-pc-linux-gnu ?
12:06:49
kami_
(":void" ":_Bool" ":char" ":signed-char" ":unsigned-char" ":short" ":unsigned-short" ":int" ":unsigned-int" ":long" ":unsigned-long" ":long-long" ":unsigned-long-long" ":float" ":double" ":long-double")
12:11:26
jackdaniel
I think that this would be easier if you had constructed a minimal example with code
13:15:35
kami_
jackdaniel: that's definitely a very good idea. I thought it might be a commonly encountered problem and someone would be able to tell me my mistake off the top of their hat.
13:17:06
kami_
And with cffi stuff, it is often difficult to create a 'minimal' example, as you just give it a header file and the person who wants to reproduce the problem has to have at least the header files installed on their machine.
13:18:55
jackdaniel
in practice often issues with libraries come from typos. and a person who makes them is usually typo-blind (at least I don't see my typos until either the compiler or a person tells me about it)
14:14:54
ludston
Does (intern "blah" :keyword) hold :blah in memory forever or are keywords a special case somehow?
14:17:06
ludston
Most of our json libraries like to intern, which is a bit scary considering that json might be coming from possibly hostile 3rd parties
14:18:56
ludston
The concern would be that someone would send json messages like {"A":"", "AA":"", "AAA":""} which will eventually DOS the system
14:20:17
jackdaniel
doesn't that apply also to excessively long string values? (that's what I've meant that symbols are heavy, but not super-heavy)
14:22:53
ludston
No, because you can trivially filter out long string values by validating against incoming stream size, vs receiving many small strings with unique values that get interned uniquely
14:25:31
ludston
The json libraries I'm looking at are interning because it is convenient to convert "{"A":1,"B":2}" into '(:a 1 :b 2)
14:26:47
splittist
I guess if you're snarfing arbitrary JSON, and I can spam you with (expt #x10FFFF n) entries you might be in trouble. But wouldn't the same thing happen with strings?
14:27:07
_death
ludston: well, I often use com.gigamonkeys.json which doesn't intern.. but often interning may be convenient because you want to have references to particular keys in your source, so you could have a hybrid that find-symbol in some package, or for some delimited set of keys
14:29:10
ludston
_death: I'll have a look at it. I'm liking jonathan the most out of the libs so far, and it's pretty trivial for me to hack it to *not* intern.
14:30:45
ludston
splittist: The problem is that you don't know if the json is arbitrary/valid until you have parsed it, and at that point it has already interned. Strings aren't a problem because they are garbage collected.
14:30:46
_death
ludston: you could also count the number of newly interned symbols to make it possible to detect such anomalies, or intern them in a non-keyword package.. there are a myriad of approaches
14:40:18
ludston
_death: I might set up long-term monitoring for that. I'm trying to think of a case where I'd actually want interning. Maybe a local config file? But then I would just use Lisp.
14:44:20
_death
so I guess interning could be helpful if you want to use EQ to compare things (but then you could also use a hash table of strings)
14:44:49
ludston
e.g. https://github.com/Rudolph-Miller/jonathan/blob/fb83ff094d330b2208b0febc8b25983c6050e378/src/util.lisp#L33
14:46:24
SAL9000
you could intern as a postprocessing step, I guess? json -> (list string) -> (list symbol)
14:49:57
ludston
One of the reasons that common lisp is the best, is you can just redefine some function in someone elses namespace that you disagree with.
14:51:56
SAL9000
That's one of the many double-edged swords/footguns, to be honest. This kind of thing -- while awesome for us -- is probably a major obstacle to large scale/commercial adoption of CL.
14:59:45
ludston
_death: But nowhere near as clean as (progn (in-package :jonathan.utils) (defun make-keyword (str) str)))
15:05:27
ludston
I guess you have to be careful though because it might be a breach of the software license
15:32:48
dieggsy
huh, for some reason i can't use *standard-output* in slynk with allegro's excl:run-shell-command. has anyone run into this before?
15:34:55
dieggsy
er, sly that is. it uninformatively says the stream "can't be used for output". I'm sure it's some weirdness to do with how sly handles output
15:42:08
etimmons
slynk's *standard-output* is a gray stream. Not all implementations can use that type of stream for their external command functions
15:42:21
splittist
dieggsy: I know nothing about excl:run-shell-command, but is it talking about output from the process, which would need a lisp INPUT stream
15:42:46
etimmons
UIOP's {run,launch}-program says that allegro can handle handle streams that are of subtype FILE-STREAM
15:44:45
dieggsy
huh. maybe i can work around it by having it return the stream and use that to print myself....
15:49:38
etimmons
That's similar to how other implementations handle it internally. I know that in cases like this, ECL spawns a new thread that shuffles data from a new stream associated with the program to the stream where you want it to go.
16:11:50
dieggsy
or actually, if i run uiop:run-program in a thread, will it only block that thread?
16:19:30
etimmons
It should, but that really depends on the implementation you're using since it's a thin veneer to give a uniform-ish API over the implementation specific functions
16:40:35
Xach
Hmm, is there anything standard-ish (cltl2 included) to get the name of the function enclosing a macro or compiler-macro at macroexpansion time?
16:43:10
Bike
What do you mean by enclosing? Like, if a macro is being expanded, the name of the function whose body the macro form is in?
16:43:28
Krystof
don't think so. a cltl2-ish environment might have information about block names, but I think even allegro doesn't have a "list-all-blocks-in-this-environment" exported operator
16:52:36
Xach
Krystof: thanks. block names were my first thought but the env object I have is a bit more opaque to me than SBCL's
16:57:07
dieggsy
with slime/sly is there no way to make sure all output is shown in the repl buffer (as opposed to some going to the inferior lisp buffer) ?
16:58:52
scymtym
Xach: the log4cl library must have something like that but i doubt it is even remotely standard-ish
17:02:42
Xach
Allegro would be most useful to me in fact. Time to scrape around the env object a little more.
17:59:04
jackdaniel
(1+ most-positive-fixnum) ways for making repl unusable: (setf *print-right-margin* (1+ most-positive-fixnum))
18:24:33
pjb
jackdaniel: it's a non-negative integer, so (1+ most-positive-fixnum) is perfectly conforming.