libera/#sicl - IRC Chatlog
Search
3:21:09
beach
hayley: When you are less busy, could you have a look at the infinite computation in register allocation? What you need to do is to run the bootstrapping script, and then do (let ((*features* '(:sicl))) (load-asdf-system '#:ctype *e5*)).
3:23:00
beach
Now that I think about it, pairwise.lisp took a while to load even without register allocation, so maybe it's just that it's taking a very long time.
3:26:33
hayley
Well, I closed the debugger and it didn't get stuck, nor did it feel like it took a while to load.
3:33:44
hayley
There were 93 elements in the stack of the work list, and 121 elements in the to-process table. Then I let register allocation continue for a few seconds. Then there were still that many elements in the stack and table.
3:48:56
hayley
I modified the register allocation code to print out which instructions it was allocating for (after having processed a million instructions), and it appears to loop between an ENTER-INSTRUCTION and MEMREF2-INSTRUCTION.
3:50:48
hayley
Also, I think my initial success with loading ctype was a mistake, as aborting and then attempting to load ctype again succeeds without having loaded pairwise.lisp
4:12:39
hayley
I don't know how that happens, but I suppose an instruction can be its own predecessor in valid IR, and it would be wise to not go into an infinite loop.
4:20:44
hayley
Hm, that case should be handled because the new pool will be pool<= to the old eventually, no? So that would not be the problem.
4:22:01
beach
I take your word for it. It is not fresh in my head, and I just barely finished my morning coffee.
4:22:59
beach
I am not sure it's correct that this situation happens here, but that's a different story.
4:28:49
hayley
Something is wrong with the output pools computed. A lexical location called function546831 has two entries in the pools that EDU computation gets stuck on.
4:33:24
beach
It is entirely possible that there is a problem in the EDU computation that causes this duplication.
4:47:05
hayley
I wrote a function that checks if a pool contains duplicate items, and it found some other occurrence of a duplicate item during bootstrapping.
4:48:08
hayley
In this case, the values are the same, so POOL<= would work correctly, but in the problematic case, the values were different and so POOL<= would presumably always return NIL.
4:48:19
beach
I see. Well, if you like, I can investigate that during the day, since I wrote that code.
4:51:54
hayley
Of course the function I am looking for tail-called CHECK-POOL-VALIDITY (which I just wrote), but I am suspecting POOL-MEET somehow.
5:33:36
hayley
The problem is actually in the default method for COMPUTE-NEW-INPUT-POOL. If one location is used as multiple inputs, multiple items are added for the location.
5:43:04
hayley
Should I keep calls to CHECK-POOL-VALIDITY in the finished code? My quickly written implementation calls REMOVE-DUPLICATES and it doesn't seem to be awfully slow. Bootstrapping still takes 43 seconds or so here.
5:49:02
beach
I'm at 51 seconds, but my new computer is a bit slower than the previous one. It is also dirt cheap compared to the previous one of course. And it doesn't crash. :)
5:54:36
beach
And MAP is one of the sequence functions, which suggests that I should load the sequence functions first. But then I have a host of other prerequisites to consider. Plus, I kind of decided not to use the version of the sequence functions that requires the FAST-GENERIC-FUNCTIONS library. Oh, well.
5:58:12
beach
I could break this dependency cycle as Bike suggested, by handling common special cases in SUBTYPEP before calling the ctype function.
5:58:45
beach
Like most code calling MAP or creating an array would probably mention the upgraded type directly.
6:03:25
beach
So now I wonder whether it is possible to avoid the use of SUBTYPEP in order to determine whether we have a "recognizable subtype of list/vector" without calling it.
6:08:34
hayley
Is there a definition for "recognizable subtype of list/vector"? SUBTYPEP is allowed to not determine a relationship for any types involving AND.
6:08:36
beach
So I guess it's OK for REIFY-SEQUENCE-TYPE-SPECIFIER to handle some special cases, but maybe it's best to have those special cases handled in one place.
6:09:30
beach
Ah, yes, I see. But something more specific than what REIFY-SEQUENCE-TYPE-SPECIFIER is doing is needed.
6:10:12
hayley
The HyperSpec glossary says to see SUBTYPEP, but it might look odd if SUBTYPEP recognizes subtype relations that MAP does not.
6:10:44
beach
So either the implementation has a version of SUBTYPEP that can handle all those cases, or else it must use another technique that works.
6:12:11
beach
Does that mean that portable programs can not use any other types in MAP than lists or portable vector types?
6:14:43
beach
Or does "can be reliably detected to be such by the implementation" mean if that the version of SUBTYPEP provided by the implementation can detect it, then so must MAP?
6:17:54
beach
Well, I am not going to worry about it right now. No sane code would use the type specifier I just suggested, and which is happily accepted by SBCL MAP.
6:20:03
beach
This is another example of the huge number of "corner cases" we discussed before (yesterday in my time zone). And it should be a hint for the work on WSCL and for pjb's work on BOCL.
6:21:13
beach
It would be interesting to see, for instance, what restrictions apply to code that can run in BOCL if it takes the freedom allowed for SUBTYPEP to its extreme.
9:03:55
tich
beach: I just started a new job and family life has been keeping me away from private projects
10:09:02
beach
I have received the request several times. It is not something that I am thrilled to do, because it takes time. But I guess that's part of the job.
12:07:25
beach
In the past, I often resolved to do one small item per day of boring tasks that could be done incrementally like this, and I think I even have a TODO list for it. But it seems to never work out the way I want.
12:33:37
beach
pjb: Another similar task is to replace all files tex-dependencies in every directory where I have a paper or some other documentation written in the past 10 years.
12:34:57
beach
jackdaniel: Speaking of boring tasks, I strongly encourage you to keep the chapter on "development history" in the McCLIM manual alive.
12:39:49
pjb
beach: about that, perhaps it would be nice to have a utility project with a single copy of those tools?
12:44:29
beach
Hmm. MAP has a single occurrence in CTYPE, but it is in a macro that is used three times which explains the tree warnings about MAP when trivalent.lisp is compiled. But where does the use of MAP come from when the files conjunction.lisp and disjunction.lisp are compiled?
12:59:30
beach
So I think the use of MAP in ctype is harmless in that I could use the host version in the worst case.
13:01:12
tich
beach: I tried to compile LisOS/Documentation and it is missing chap-address-space.tex
13:03:43
beach
That chapter was removed because it is obsolete. Let me verify that I pushed the updates...
13:16:03
Bike
beach: i think ctype only uses map nil, which is a special case anyway? i guess i could also rewrite it as a loop
13:21:59
beach
Bike: Yes, only NIL. But don't rewrite. I should be able to handle dependencies like that.
13:24:36
tich
Not a big issue I saw that this tex file was included but did not exist. I just wanted to make sure I was not missing out on a chapter
13:27:50
beach
OK, so let's see where we are. I need to have the class READTABLE before I can load CTYPE, but I was counting on READTABLE being supplied by Eclector. However Eclector calls MAKE-ARRAY at compile time, so I need it. But MAKE-ARRAY needs SUBTYPEP which is why I started working on loading CTYPE.
13:28:25
beach
So what I need to do is to define a temporary class named READTABLE early, and then redefine it later when Eclector is loaded.