freenode/#clasp - IRC Chatlog
Search
11:50:46
selwyn
i threw in some #if defined( _TARGET_OS_DARWIN ) ... #endif around the problematic code and it built fine on linux. upon startup, it complains about ASDF, tries to reload it and drops into the debugger
11:51:58
selwyn
i think that last issue is related to something other than these type changes - i remember hearing about it on here a while back
12:51:18
drmeister
I pushed a few changes that may conflict with your #if defined( _TARGET_OS_DARWIN ) - I attempted to fix the same problem. I'll try building on Linux today.
12:52:50
drmeister
Actually, our buildbot got past that stage - so soon I'll see how the ASDF thing goes.
15:32:53
Bike
i guess if you allocate a funcallable instance and then immediately call it you get undefined effects. but setting it to some basic closure would be nicer
15:38:45
beach
Speaking of which, when I studied the MOP, I came to the conclusion that this aspect of it was designed so that you can avoid an extra indirection.
15:39:27
beach
Like if your functions have some "code" and "environment" slots, then you can copy those to the funcallable-standard-object.
15:42:12
Bike
https://github.com/clasp-developers/clasp/issues/739 we only copied the "code" slot, so if you gave it a closure there was a problem
15:42:29
Bike
drmeister switched it to use the indirection, which is more correct but has a bit of overhead
15:42:40
Bike
the problem with copying both the code and the environment is how to do it thread safety
15:43:28
Bike
and i just had the idea that if the funcallable instance function happens to not use its environment, i.e. is not a closure, we can get away with just copying the "code"
15:43:55
beach
I can do it in SICL, because both the environment and the code are in the rack, so I just allocate a new rack.
15:45:07
Bike
i think we would have trouble with that since other kinds of functions don't have that indirection.
15:47:08
Bike
but yeah, you're definitely right that the mop was written with this in mind... as i recall, in the original actually-portable PCL code one of the implementation hooks was a low level jump, so as to avoid an actual function call, or something like that
15:48:10
beach
I see. I haven't studied PCL very much. As usual, I try to think it through myself first, and it often results in better solutions.
15:50:51
Bike
might be nice if they'd said so more explicitly, though... as-is, it's not immediately obvious why the funcallable instance function isn't just a slot
15:54:54
beach
It is not the only such situation. I guess it must be a tradition with people writing language specifications.
16:02:28
jackdaniel
on the other hand trying to record the intention makes a short description much longer (and not quite understandable). I've tried to write a serie of blog posts about adding new numbers in ECL and things I've learned (and which had to be put in the document) grew a lot and it was too detailed for a tutorial
16:02:48
jackdaniel
putting only code with short explanation wouldn't cut it either (because it wouldn't be worth much)
16:03:31
beach
The Common Lisp HyperSpec is a lot like that as well. I mean, take the entire distinction between the startup environment, the compilation environment, and the evaluation environment. They could have written that it was meant to allow for first-class global environments.