freenode/#sicl - IRC Chatlog
Search
4:49:47
beach
And I tried the compile-time options suggested by Douglas Katzman in this message from 2 years ago: https://sourceforge.net/p/sbcl/mailman/message/35497099/
4:51:22
beach
I also tried changing to CCL. I get a mysterious error early on in the bootstrapping procedure that a slot reader is called with 1 argument but requires at least 2. I think I would need some help from rme to figure that one out.
4:54:48
beach
Instead, he changed something in the SBCL code, asked me to download a fresh version, compile it, and install it.
4:58:40
shka_
ok, i bet that this is the commit https://github.com/sbcl/sbcl/commit/e7cd2bd40f5b998821874b1720d61735f2cf292e
5:06:31
shka_
this makes me to think so #define WORDS_PER_PAGE ((int)IMMOBILE_CARD_BYTES/N_WORD_BYTES)
5:17:36
shka_
well, don't bother in that case but git checkout e7cd2bd40f5b998821874b1720d61735f2cf292e
5:19:44
shka_
maybe this has to do something with github mirror or something that delayed code distribution just enough for you to pull older version
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.