libera/#commonlisp - IRC Chatlog
Search
3:54:41
beach
People need to know how good McCLIM has become, and that it is going to get even better.
3:55:48
hirez
if they could reskin this to use a native-looking skin (or an approximation) I could probably sell this easily
3:57:15
hirez
because they feel very similar in terms of programming (though lispworks IDE makes life marginally easier...)
3:58:39
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.
4:00:49
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.
4:01:39
beach
So, I think in 2000, gilberth merged his and Mike's work, encouraged by me, and that was the start of McCLIM.
4:03:47
hirez
hah, now that I think about it bordeaux has come up a few conversations about computational geometry
4:04:57
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.
4:07:29
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.
4:07:54
hirez
Conses are natural representations of points. Functional composition is extremely useful.
4:07:57
beach
Good. Python would be horrible for that kind of computation. You would have to write your code in C.
4:08:27
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
4:08:34
beach
It is usually estimated that Python has a factor 50 or so performance penalty compared to a good Common Lisp implementation like SBCL.
4:09:10
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
4:09:34
hirez
moon-child, not in python. At least not easily. Cython let me "get around" the GC by redefining structures as C structures.
4:10:46
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
4:10:48
hirez
Thankfully I am focused on robotic path planning. A nice fit for lisp and symbolic computation imo :D
4:12:00
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.
4:12:47
moon-child
ah, yeah, python's objects are quite heavy, and it can't really leave them unboxed
4:14:06
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.
4:15:03
hirez
Anyway, this all to say with McCLIM working and finally starting to really grok lisp I'm happy with what ive done far.
4:29:32
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?
4:29:54
GreaseMonkey
...oh and usocket of course unless something tends to be a lot better than that
4:30:32
GreaseMonkey
but i suspect it's really only stuff like SDL that needs special treatment of the main thread and whatnot
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