libera/#commonlisp - IRC Chatlog
Search
0:00:05
remexre
is there a reasonable party to ping about the see-also links on http://www.lispworks.com/documentation/HyperSpec/Body/v_pl_plp.htm#PLPL being wrong?
0:43:15
Josh_2
My irl buddy wants to try CL however he has cerebral palsy so he cannot type properly with one hand, so no emacs/vim for him
0:48:03
moon-child
I think emacs may be doable, if you set it up so that you tap modifiers instead of holding them?
0:52:27
cjb
if you do setup emacs, maybe don't hide the menubar. if they are able to use a mouse, the menubar is very handy if using the keyboard is a problem.
0:54:30
moon-child
I think vim is also probably feasible too, if you move keys around. I was able to use it reasonably well one-handed when I broke my arm
3:34:41
subst
I've looked at this channel's logs. Most of the activity happens overnight in my time zone.
3:35:50
subst
Seems to be true for Lisp in general. There's a European Lisp Symposium but not an American one.
3:37:04
beach
But there are people from all over, so if you have any questions, there is usually someone to ask.
3:38:52
beach
There used to be an International Lisp Conference (ILC) organized by the ALU (Association of Lisp Users), but I think the ALU has difficulties finding people who are interested.
3:39:21
beach
ELS is currently mainly driven by Didier Verna, but who knows what will happen when he gets tired of it.
3:40:03
subst
It seems like there might not be a next generation to maintain all the Lisp implementations out there.
3:41:14
beach
SBCL is well maintained. ECL is taken care of by jackdaniel. CCL is still worked on by rme, I think. And I have seen bhaible around here, so maybe CLISP is maintaned too.
3:42:05
beach
Don't despair! We are working on a new fresh implementation that will attract new people to work on. It already has in fact.
3:44:38
beach
Here I thought I was the first one to write a Common Lisp implementation using the full language. Oh well. Congratulations!
3:45:42
subst
It's extremely slow and the interpreter is a mess. I tried using C++ exceptions to implement nonlocal jumps, and C++ RAII to implement UNWIND-PROTECT. The two don't go together.
3:47:09
moon-child
beach: sacla is another such, albeit nascent and abandoned: https://minejima.jp/lisp/sacla/index-en.html
3:47:30
subst
It wouldn't be so much of a problem for my implementation if I didn't also use destructors. The problem is that C++ calls std::terminate if a nonlocal jump is performed from Lisp code called from a destructor.
3:47:48
beach
moon-child: Yes, I am aware of Sacla, But I don't think there was even an attempt to bootstrap it.
3:49:25
beach
subst: I am curious, in what way did you find your implementation similar to SICL, if yours is written in C++?
3:52:31
subst
My problem is, if you invoke a restart, and it causes an UNWIND-PROTECT to run, and the UNWIND-PROTECT invokes another restart, that causes C++ to call std::terminate().
3:54:12
beach
You may want to ask the Clasp people about things like that. They know everything about implementing Common Lisp in C++.
3:56:38
beach
moon-child: It is easy to use the full language to implement Common Lisp if you don't care about how to bootstrap it. :)
4:04:58
subst
I tried using it as a reference for the MOP, while I implemented a CLOS interface to Objective-C classes.
4:08:20
beach
I don't particularly like the way chapters 5 and 6 are ogranized, so I wrote this site: http://metamodular.com/CLOS-MOP/clos-mop.html
4:09:57
beach
There was an already existing HTML version of those chapters, but the authors didn't respect the desires of the authors of the AMOP book and make the HTML markup restricted by copyright and such. Plus, the HTML wasn't very good.
4:12:00
subst
I had to look up another source to figure out how to get STANDARD-DIRECT-SLOT-DEFINITIONS to work. AMOP forgot to mention that you need to implement DIRECT-SLOT-DEFINITION-CLASS and EFFECTIVE-SLOT-DEFINITION-CLASS for your metaclass.
4:15:38
subst
You can extend CLOS slots to have extra slot-options. The standard ones are things like :INITARG, :ACCESSOR, etc. I needed extra options that were specific to Objective-C. AMOP describes how to create your own slots, but doesn't say (as far as I recall, anyway) how to get your metaclass to use these new slots.
4:23:38
subst
Oh well. I was about to go to bed. No need to go into the weeds about a library I'll never have time to finish.
4:33:42
subst
I wonder what you'd think the best way to do this is: My Obj-C wrapper library implicitly creates an Objective-C class for every class defined with the OBJECTIVE-C-CLASS metaclass. Every slot in an OBJECTIVE-C-CLASS has both a CLOS slot and an Objective-C Ivar (which is in most cases a CFFI pointer).
4:33:51
subst
Sometimes you want to assign an OBJECTIVE-C-CLASS object to a slot in another OBJECTIVE-C-CLASS object. But you can't do this fully, because you can't assign a CLOS object to a foreign pointer.
4:33:54
subst
So my metaclass looks inside the object and pulls out the Objective-C foreign pointer that backs it, and assigns that to the Objective-C Ivar. Then it assigns the CLOS object to the CLOS slot.
4:36:03
subst
The problem comes when you want to look at the CLOS object after that. If you've passed the containing object to an Objective-C function, it might have replaced the object in the Ivar with a different one. So when you retrieve the slot, my metaclass has to create a new CLOS object, wrapping the same Objective-C object as what you originally put in.
4:36:19
beach
Wow, that sounds like a messy problem. I know very little about Objective C and I stay away from FFI to avoid messy problems.
4:37:21
subst
It is very messy, and probably the reason why I've let this project sit for years now.
4:38:44
beach
The Clasp people might have some clues. They made C++ classes managed by the Common Lisp GC. Maybe you could do something similar.
4:40:08
moon-child
it's reference-counted though. So I guess on the cl side you could increment the reference count once, and then when freeing the object decrement it again
4:40:25
moon-child
basically treating the whole cl heap as a single referent from objc's perspective
4:42:16
subst
The messiness comes from having this surrogate CLOS object that represents, but isn't identical to, an ObjC object. The CLOS objects end up being like ORM objects in that you can have two objects with distinct addresses (ie, not EQ) that represent the same object in the backing store (in this case ObjC).