freenode/#sicl - IRC Chatlog
Search
5:53:25
shka_
it probably is, but as with everything with so many moving parts it sometimes exceeds human capability ;-)
6:04:17
beach
I wonder what the use of immobile space might be, especially since it seems to be optional. Does it have to do with performance?
6:44:13
beach
Latest news, removing all my FASLs and starting the bootstrapping procedure over fixes the problem.
6:45:11
no-defun-allowed
speaking of which, fasls decided to get on my nerves again today, so i can't wait for them to go, haha
6:46:59
no-defun-allowed
after you talked about avoiding structs, i decided to replace one with a standard-class since it wasn't hard to replace and subclassing it made sense
6:47:40
no-defun-allowed
can't do that in one lisp instance apparently, even after attempts to unintern and delete-package so i restarted and reloaded
6:48:05
no-defun-allowed
well, it's probably going to be alright, network speed will be the bottleneck
6:48:45
no-defun-allowed
sbcl cheerily errors about different shapes or forms or something in the FASL since i used the same accessor names and i had to remove the fasls
6:57:27
no-defun-allowed
there's only one program i can think of where a struct would have been better, due to memory pressure since i would be handling lots of objects over many threads
6:58:20
beach
Now, of course, in SICL, that would make no difference, since structs have the exact same layout as standard objects.
7:01:56
no-defun-allowed
so, i suppose the size of an object would not be much smaller if it were a struct then
7:02:51
beach
Not in SICL. In most Common Lisp implementation there would be no indirection for structs. Such an indirection is necessary for standard objects, because they can be dynamically redefined.
7:23:08
shka__
so function that stays in one place all the time can be also passed as callback, safely
7:23:35
beach
Well, in SICL, all functions will be allocated in immobile space, but there won't be any restriction on the size of that space. The OS will be asked to increase it as necessary.
7:26:45
shka__
well, it pains me to see you troubled, but I am afraid that i already reached limits of my capabilities
9:07:08
beach
OK, I decided to add another phase to the bootstrapping procedure. It is a new phase 5 that is pretty much identical to phase 4. The purpose is to make the blue objects be the preferred ones for obtaining circularity.
9:07:14
beach
As heisig suggested, I should then be able to mostly keep track of allocations of blue objects and change the class of each one at the end.
9:07:20
beach
There is more to it though. I need to choose candidate generic functions to manage the cyclic graph. Different candidates might exist in different environments.
9:08:32
beach
By the way, the new phase was quite painless to do. It kind of just worked to copy phase 4 and change to a new set of environments. I should take advantage of this situation to factor the code.
9:18:08
beach
I want generic functions to access classes and other function in the same environment.
9:19:56
beach
Additional generic functions such as compute-discriminating-function exist in different environments and they call different sets of accessors.
9:20:29
beach
So I need to choose precisely the set of generic functions that will work for a single environment.
9:21:30
beach
The more phases I have, the more likely it is that generic functions in different environments are interchangeable.
9:22:36
beach
In order to invoke a generic function, its discriminating function might have to be computed. And that process goes to the preceding environment with its accessors.
9:23:16
beach
But there is a limit. I only need to back up by so many environments. I don't know exactly how many, but my guess is that 2 is max.
9:24:31
beach
So the more phases I have, the more likely it is that generic functions in the last few environments behave the same on ersatz objects.
9:25:18
beach
I know, this is not a very precise description, but at the moment, it is just intuition in my head.
9:29:50
heisig
Your bootstrapping technique is starting to look like a fixed point iteration for MOP behavior. I love it.
9:33:53
beach
It all works because an accessor that has had its discriminating function computed goes directly to the rack with the right index.
9:36:55
beach
So green, red, and blue accessor behave the same, provided they have had their discriminating functions computed.
9:39:01
beach
And yellow ones as well, of course, but they definitely have not had their discriminating functions computed.
16:50:22
beach
As a result of the work from this morning, I now have this situation: http://metamodular.com/fig-environments.pdf
17:08:19
beach
Working hypothesis for phase 6 (where I turn the acyclic graph into a cyclic graph): 1. Change the class slot of every blue object so that it points to a blue class instead of a red class. 2. Copy the blue classes over to E5. 3. (this is the tough one) redefine functions in E5 that look for classes en E4 so that they look for classes in E5 instead. 4. Maybe something else that I am unaware of.
17:10:51
beach
What I think I need to do is to start with all operations I need to do in E5 (call a function, define a generic function, define a method, define a class), then trace every function call made as a result of that, figure out where the functions are located that get called in the process, and check what needs to be modified in order for things to continue to work.