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.
16:23:13
drmeister
Bike: (bclasp-compile nil (generate-dispatcher-from-dtree ... )) returns a #<The BUILT-IN-CLASS CORE:CLOSURE-WITH-SLOTS>
16:26:20
drmeister
(core:closure-length (third (multiple-value-list (clos:get-funcallable-instance-function #'foo)))) -> 0
16:27:42
drmeister
These are just for debugging - I shouldn't use get-funcallable-instance-function anywere that matters.
16:29:56
Bike
oh, but if i remove a slot from funcallable instance, do i have to do anything weird? it's one after the rack
16:30:17
drmeister
If we check if it's a closure with no slots then in that case we can just copy the code.
16:43:08
Bike
removing not_funcallable_entry_point might be weird because of how initialization works in C++. i need food for this
16:43:20
drmeister
The thread safety issues come in if another thread is executing and there is an inconsistency between the entry and the GFUN_DISPATCHER.
16:43:56
Bike
why would there be a thread safety issue? the call goes to the entry_point, which works regardless of the GFUN_DISPATCHER
16:45:56
Bike
ah, wait. if a thread changes it from a non-closure to a closure it has to change both the entry point and the gfun_dispatcher
16:45:56
drmeister
I was thinking if a compiled dispatcher is over written with an interpreted one - then there could be a problem if GFUN_DISPATCHER was out of sync with entry - but DtreeInterpreter_O keeps track of its generic function as does every compiled dispatcher.
16:47:04
drmeister
DtreeInterpreter and generic function dispatchers are ok - it's closures that are the problem.
16:50:03
drmeister
What if I put a spin lock around writing and reading entry/GF_DISCRIMINATOR? That will slow down closures but not generic function calls.
16:50:25
drmeister
That will slow down the case of funcallable-instance calls that contain closures.
16:50:31
karlosz
okay, also managed to get rid of set predecessors now. will get a build timing sometime later
16:54:08
drmeister
How often do people (set-funcallable-instance-function funcinst (let ((x ...)) (lambda ...)))
17:02:00
scymtym
i would expect the instance function to access the instance in many non-generic function cases
17:16:48
Bike
kpoeck_: i haven't updated our use of sicl yet. if you want to force it, just check out sicl master in the contrib/sicl
17:18:39
Bike
if you do check out sicl master, use the cst build - it won't work with the generate-ast build
17:20:34
scymtym
Bike: apart from generic functions, i would expect uses of funcallable instances to revolve around accessing the instance slots from the instance function. otherwise, what's the point compared to an ordinary function?
17:21:13
Bike
when drmeister said "how often" he actually meant like, is it going to be done in a loop, that kind of thing
17:21:30
kpoeck_
So perhaps i just change wscript so point to sicl master and start with distclean configure
17:21:39
scymtym
oh, dispatching on the class could also be a reason, but i can't think of a use-case
17:21:55
karlosz
kpoeck_: what i do is just set a remote and cherry pick my commits onto the existing git repo in clasp
17:23:03
scymtym
but yeah, updating the instance function is probably a rare operation in most scenarios
17:23:34
Bike
yeah. with fastgf it's actually a little bit not, since it can happen from any call to the function, but i think that's our worst case
17:24:35
scymtym
in that case the cost of compiling the new instance function should dwarf the cost of installing it