<jcowan>
Back when the pname was on the alist of a symbol, you could mutate it, but that wouldn't affect the inaccessible hash table that maps pnames to their symbols.
<jasom>
jcowan: what about (setf (get nil ...)...)? If the plist is part of the symbol, you're mutating the symbol, no?
random-nick has quit [Ping timeout: 258 seconds]
<jcowan>
The story is about mutating symbol names. in Lisp 1.5, pnames were on the plist, but they were not Lisp objects (no strings yet), so you could only mutate a pname by assembly-language operations. And even if you mutated the plist of NIL to be T, it would still *work like* NIL in the sense of evaluating to itself and being the empty list. So typing in NIL would print out T, because that is the new pname of NIL.
franco has quit [Read error: Connection reset by peer]
<pjb>
jcowan: the story is foremost that modern implementations implement protections. The standard doesn't mandate them. It only forbids conforming programs to perform any retrospection on the CL stuff.
SAL9000 has quit [Ping timeout: 272 seconds]
igemnace has joined #commonlisp
leo_song has joined #commonlisp
trocado has quit [Read error: Connection reset by peer]
yewscion has joined #commonlisp
zacts has joined #commonlisp
derelict has joined #commonlisp
zacts has quit [Ping timeout: 245 seconds]
zacts has joined #commonlisp
rbtEngrDude has joined #commonlisp
Lycurgus has quit [Ping timeout: 264 seconds]
yewscion has quit [Remote host closed the connection]
rbtEngrDude has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
yewscion has joined #commonlisp
zacts has quit [Quit: bbl]
dsk has joined #commonlisp
waleee has quit [Ping timeout: 272 seconds]
Bike has quit [Quit: Lost terminal]
waleee has joined #commonlisp
waleee has quit [Ping timeout: 252 seconds]
lottaquestions has quit [Remote host closed the connection]
rbtEngrDude has joined #commonlisp
frgo has joined #commonlisp
unyu has joined #commonlisp
frgo has quit [Ping timeout: 244 seconds]
rbtEngrDude has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
mindCrime_ has quit [Ping timeout: 252 seconds]
taiju has quit [Ping timeout: 272 seconds]
ad-absurdum has joined #commonlisp
taiju has joined #commonlisp
<beach>
Good morning everyone!
Lord_of_Life_ has joined #commonlisp
akoana has quit [Quit: leaving]
Lord_of_Life has quit [Ping timeout: 250 seconds]
SAL9000 has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
rbtEngrDude has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
jemoka has joined #commonlisp
jemoka has left #commonlisp [#commonlisp]
jemoka has joined #commonlisp
<hirez>
morning beach
<hirez>
another day of enjoying mcclim
<hirez>
ive finally caught my stride
<hirez>
implementing drawing the convex hull was a breeze
<beach>
Excellent!
<beach>
People need to know how good McCLIM has become, and that it is going to get even better.
<hirez>
call me old fashioned but I love the command interactor
<hirez>
I cant explain why
<hirez>
but its just...nice to have
<beach>
I agree.
<beach>
But it can be hidden in applications where people don't want it.
<hirez>
if they could reskin this to use a native-looking skin (or an approximation) I could probably sell this easily
<beach>
I think that's one of the plans.
<hirez>
judging by the hour I spent with LispWork's offering this fields remarkably similar
<hirez>
im guessing CLIM was a gui kit from days gone by?
<hirez>
because they feel very similar in terms of programming (though lispworks IDE makes life marginally easier...)
<beach>
I think it has roughly the same age as the standard.
<beach>
CLIM used to be supported by Allegro, LispWorks, and also Genera I think.
<beach>
I discovered the specification a little more than 20 years ago when I needed a GUI for Gsharp, and I didn't want to attempt an FFI solution.
<hirez>
you've been programming lisp since the cowboy days
<hirez>
thats pretty cool
<beach>
Oh, I learned Lisp (not Common Lisp obviously) in around 1977 or so.
<hirez>
did you ever get to play with a real life symbolics machine?
<beach>
Then, it turned out that Mike McDonald and gilberth had written pieces of a free implementation. Mike had made "horizontal" progress (with the address-book application), and gilberth had done "vertical" progress with regions and transformations.
<beach>
No, I did not.
<beach>
So, I think in 2000, gilberth merged his and Mike's work, encouraged by me, and that was the start of McCLIM.
<hirez>
wow so you've had your hand in mcclim for a while
<hirez>
no wonder you seem to know a lot about it ;D
<beach>
You can say that I was the one that made it happen, even if I didn't do it myself.
rbtEngrDude has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<beach>
It happened at an event called the Libre Software Meeting, in Bordeaux.
<hirez>
hah, now that I think about it bordeaux has come up a few conversations about computational geometry
<hirez>
I think inria hosts a computational mathematics seminar there
<beach>
Ah, that's possible.
<beach>
Otherwise, I was a grad student at Johns Hopkins when Joe O'Rourke and Subhash Suri were doing good work in computational geometry. They are fairly well known in the field.
yewscion has quit [Ping timeout: 245 seconds]
<hirez>
O'Rourke is a demigod in the field.
<beach>
Subhash is still a friend of mine.
<hirez>
Also OR is one of the few people that would actually answer my emails
<hirez>
gave me very good graduate school advice
<beach>
Great!
<hirez>
I actually have the second edition of his book on my desk.
<hirez>
Its basically the seminal work in introductory CG
<beach>
Yes, I see.
<beach>
Small world.
<hirez>
Very small haha
<hirez>
I've found lisp to be a natural fit. Despite pressure to use python and what not I'm committed to porting everything over this direction.
<hirez>
Conses are natural representations of points. Functional composition is extremely useful.
<beach>
Good. Python would be horrible for that kind of computation. You would have to write your code in C.
<hirez>
And I have. In the process of running experiments in one of my papers python's GC was so aggressive I had to retool it in Cython
<beach>
It is usually estimated that Python has a factor 50 or so performance penalty compared to a good Common Lisp implementation like SBCL.
<moon-child>
hirez: could you not disable the gc entirely? That's frequently a reasonable tradeoff for batch processing work, even with a good gc
<hirez>
moon-child, not in python. At least not easily. Cython let me "get around" the GC by redefining structures as C structures.
<hirez>
Its mostly industry pressure. CG is trying to fit in with the ML guys these days.
<moon-child>
huh
<moon-child>
oh--I suppose cpython uses reference counting, so the main cost would be incrementing and decrementing reference counts, not actually allocating and freeing or tracing objects
<hirez>
Thankfully I am focused on robotic path planning. A nice fit for lisp and symbolic computation imo :D
<hirez>
moon-child, that and the representation of structures in the VM. They are extremely heavy. 80% or more of my GC penalty was coming from dicts/sets getting collected as I dumped them.
<hirez>
The fact I can tune SBCL's GC already is a huge selling point.
<moon-child>
ah, yeah, python's objects are quite heavy, and it can't really leave them unboxed
<hirez>
yeah and outside of Cython there's no way to just get a simple C-like structure.
<hirez>
Tuples are close but not perfect, and classes are really the only other way. Each of those has a huge penalty in terms of all the free stuff it gives you.
<hirez>
Anyway, this all to say with McCLIM working and finally starting to really grok lisp I'm happy with what ive done far.
<hirez>
Happy enough to keep on pushing ;D
raeda_ has joined #commonlisp
ldb has joined #commonlisp
<GreaseMonkey>
what kinds of IRC bot libraries would you recommend on QuickLisp or via something i can check out into my local-projects directory? or would i be best to instead look for something that would let me parse lines fairly well... or should i just bite the bullet and use what's in cl + alexandria?
<GreaseMonkey>
...oh and usocket of course unless something tends to be a lot better than that
SAL9000_ has joined #commonlisp
<GreaseMonkey>
the other thing is it needs to be happy running in a SWANK server
<GreaseMonkey>
but i suspect it's really only stuff like SDL that needs special treatment of the main thread and whatnot
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
kevingal has joined #commonlisp
hendursa1 has joined #commonlisp
hendursaga has quit [Ping timeout: 252 seconds]
tyson2 has joined #commonlisp
yewscion has joined #commonlisp
knusbaum has joined #commonlisp
yitzi has joined #commonlisp
yewscion has quit [Ping timeout: 268 seconds]
knusbaum has quit [Remote host closed the connection]
kami_ has joined #commonlisp
<kami_>
Good afternoon, #commonlisp
<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 ?
<kami_>
and cffi/c2ffi::+c-builtin-types+ has the value
<kami_>
I inspected cffi/c2ffi::+c-builtin-types+ after falling into the debugger
<jackdaniel>
I think that this would be easier if you had constructed a minimal example with code
Duuqnd has quit [Ping timeout: 250 seconds]
Oladon has quit [Quit: Leaving.]
tyson2 has quit [Ping timeout: 252 seconds]
Bike has joined #commonlisp
v88m has quit [Ping timeout: 250 seconds]
akoana has quit [Quit: leaving]
<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.
<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.
<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)
<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
Kabriel is now known as skempf
<splittist>
aren't short things smaller than long things?
<ludston>
It depends how many of them you have in a row
<_death>
would there be a point in interning them?
Inline has joined #commonlisp
yitzi has quit [Remote host closed the connection]
<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)
<ludston>
As opposed to '("a" 1 "b" 2) which would be safe
<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?
<_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
<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.
seok has joined #commonlisp
<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.
<_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
<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.
<_death>
when you say "interning", do you mean "intern" or "find-symbol"
<ludston>
As above, specifically (intern "blah" :keyword)
<_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)
<SAL9000>
you could intern as a postprocessing step, I guess? json -> (list string) -> (list symbol)
<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.
<SAL9000>
:-)
<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.
<_death>
instead you can make it possible to provide your own function to the json parser
<_death>
many languages allow similar shenanigans
cranium has quit [Quit: Leaving]
<_death>
just think of the good ol' #define private public ;)
Lycurgus has joined #commonlisp
<ludston>
_death: But nowhere near as clean as (progn (in-package :jonathan.utils) (defun make-keyword (str) str)))
<_death>
"clean" is not the word I'd use :)
<ludston>
Don't judge me! This way I don't have to fork an entire repo to change one line
aeth_ has joined #commonlisp
<ludston>
Haha
aeth has quit [Killed (NickServ (GHOST command used by aeth_))]
aeth_ is now known as aeth
<ludston>
I guess you have to be careful though because it might be a breach of the software license
<_death>
there's always defadvice ;)
selwyn_ has joined #commonlisp
raeda_ has quit [Remote host closed the connection]
Colleen has quit [Read error: Connection reset by peer]
raeda__ has joined #commonlisp
Colleen has joined #commonlisp
aeth_ has joined #commonlisp
scymtym has joined #commonlisp
aeth has quit [Killed (NickServ (GHOST command used by aeth_))]
aeth_ is now known as aeth
slyrus__ has joined #commonlisp
mingus_ has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
gwefnn_ has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
Bike_ has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
srji_ has joined #commonlisp
pieguy128_ has joined #commonlisp
pve_ has joined #commonlisp
srhm has quit [*.net *.split]
gwefnn has quit [*.net *.split]
cage has quit [*.net *.split]
Bike has quit [*.net *.split]
mingus has quit [*.net *.split]
random-nick has quit [*.net *.split]
trokotech has quit [*.net *.split]
karlosz has quit [*.net *.split]
selwyn has quit [*.net *.split]
pve has quit [*.net *.split]
Lord_of_Life has quit [*.net *.split]
leo_song has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
mfiano has quit [*.net *.split]
srji has quit [*.net *.split]
slyrus_ has quit [*.net *.split]
Lord_of_Life_ is now known as Lord_of_Life
taiju has quit [Ping timeout: 245 seconds]
taiju has joined #commonlisp
random-nick has joined #commonlisp
mfiano has joined #commonlisp
<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?
waleee has quit [Quit: WeeChat 3.1]
tyson2 has joined #commonlisp
<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
Cymew has quit [Ping timeout: 252 seconds]
cage has joined #commonlisp
<etimmons>
slynk's *standard-output* is a gray stream. Not all implementations can use that type of stream for their external command functions
<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
<etimmons>
UIOP's {run,launch}-program says that allegro can handle handle streams that are of subtype FILE-STREAM
Bike_ is now known as Bike
<etimmons>
* type FILE-STREAM
<dieggsy>
etimmons: oh. hadn't even heard of gray streams
<dieggsy>
huh. maybe i can work around it by having it return the stream and use that to print myself....
<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.
<jackdaniel>
yeah, that was tricky :)
lucerne has joined #commonlisp
Josh_2 has joined #commonlisp
<Josh_2>
Afternoon
<dieggsy>
or actually, if i run uiop:run-program in a thread, will it only block that thread?
samebchase has joined #commonlisp
seok has quit [Quit: Client closed]
trokotech has joined #commonlisp
<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
aeth_ has joined #commonlisp
aeth has quit [Killed (NickServ (GHOST command used by aeth_))]
aeth_ is now known as aeth
tyson2 has quit [Ping timeout: 252 seconds]
<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?
<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?
<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