Search
Wednesday, 17th of October 2018, 23:54:48 UTC
3:14:05
beach
Good morning everyone!
3:32:31
no-defun-allowed
morning beach
3:35:02
no-defun-allowed
beach (IRC): i've been having similar problems on my machine too, my machine randomly freezes and i suspect it's a GPU/GPU driver problem
3:35:24
no-defun-allowed
i can't ssh in when that happens either
3:36:24
no-defun-allowed
i'll be getting a new GPU soonish since i suspect it's getting flaky and it wasn't very good anyway
3:36:56
no-defun-allowed
back in the ubuntu 14.04 days it'd go out with passion when playing games and the screen would become rgb noise
3:40:26
no-defun-allowed
pretty sure that was with amd's fglrx proprietary driver but i don't remember well
3:41:14
no-defun-allowed
(it's a r7 250, which is a sea islands/gcn 1.0 AMD chip)
3:41:32
beach
I don't know what mine is.
3:42:03
no-defun-allowed
i think `clinfo` and/or `lspci | grep VGA` will show you but i can't check right now
3:42:06
beach
I try to outsource my hardware so as not to be burdened by that part as well.
3:43:26
no-defun-allowed
fair enough, it took a while to build mine
3:44:10
beach
Here is my reasoning...
3:44:24
beach
Tons of people in the world are capable of building a custom desktop PC.
3:44:30
no-defun-allowed
that's true
3:44:40
beach
Very few people have the knowledge to write a modern Common Lisp system.
3:44:58
beach
So my time is better spent doing things I am uniquely well prepared for.
3:45:13
|3b|
might also look at /var/log/Xorg.0.log.old if it exists
3:45:27
beach
Thanks. I'll do that.
3:45:29
|3b|
look for lines with EE towards end
3:46:07
no-defun-allowed
ooh that's a good idea
3:47:29
beach
Just keymap problems. I think those are known. Nothing serious.
3:48:24
beach
no-defun-allowed: It's an age thing. With age, one tends to get very busy. So one has to make priorities. You'll find out eventually.
3:48:36
no-defun-allowed
i suppose i will
3:49:50
|3b|
beach: date of that file is today?
3:50:13
no-defun-allowed
(ironically my genetic evolution program is evolving towards doing nothing, so i don't have to worry about that now :)
3:50:28
beach
|3b|: No, from before the latest crash.
3:50:36
|3b|
ACTION thought that was today
3:50:48
beach
Depends on your time zone I suppose.
3:50:57
|3b|
ah, right it is at least recent though?
3:50:58
beach
But no, I have only been up for an hour.
3:51:03
|3b|
between last few crashes or so
3:51:30
beach
There are two files Xorg.0.log{,.old}
3:51:40
beach
None of them has anything interesting in it.
3:52:11
beach
But thanks for the tip.
3:52:34
|3b|
might also check /var/log/kern.log
3:53:04
|3b|
that might be same thing as journalctl output though
3:53:17
|3b|
(and assuming it still exists, people keep changing where they log things :p )
3:54:42
beach
kern.log often has [drm] entries before the crash.
3:55:10
beach
They seem to have something to do with my monitors.
3:55:34
beach
[98406.758868] [drm] {1600x1200, 2160x1250@162000Khz}
3:55:40
no-defun-allowed
drm would refer to something about rendering
3:55:55
beach
1600x1200 is the resolution of my monitors.
3:57:53
beach
No, forget that. Those entries precede the crash by a lot.
3:58:04
no-defun-allowed
it's the Direct Rendering Manager, which handles GPU interfacing
3:59:25
beach
There is nothing close to the time of the crash in that log.
3:59:45
beach
|3b|: Thanks for all the hints, though.
4:00:17
|3b|
ACTION can't think of anything else aside from trying to get to a console after crash (either switching VT or with SSH, maybe also try alt-sysrq-k if ctrl-alt-f1 (or other with other f-keys) doesn't do anything)
4:00:44
no-defun-allowed
tried that when it happened, nothing happened
4:00:46
|3b|
ACTION would also check for dust accumulation, but i assume hardware guy would have checked that
4:01:22
beach
|3b|: This computer is brand new.
4:01:56
|3b|
sysrq is a key, not sure what the other name for it is, scroll lock or break
4:02:59
|3b|
and i guess out of 3 choices, i picked the 2 wrong ones: / other name is print screen
4:03:13
|3b|
(assuming those are same on your key layout)
4:04:02
|3b|
ah, looks like the k might vary with key layout too
4:04:52
|3b|
https://en.wikipedia.org/wiki/Magic_SysRq_key
4:11:47
beach
Time for a break. I'll be back in 30 minutes or so.
5:32:30
shka_
beach: nothing new regarding your machine?
5:33:14
beach
shka_: Unfortunately not.
5:33:23
beach
shka_: Thanks for you help, though.
6:50:48
beach
I WIN! http://metamodular.com/bootstrapping-progress.png
6:51:16
beach
I think I have the full generic-function invocation protocol working in environment E2, without needing any satiation.
6:51:37
beach
In the process, I eliminated much bootstrapping-specific code.
6:52:15
beach
I also broke Phase 3, but that's probably just an unfortunate side effect that has to be dealt with next.
6:53:06
beach
Anyway, I am very pleased with this progress.
6:53:15
beach
It doesn't look like much, but it's a great step.
6:53:34
beach
Before, in E2, things just sort of worked.
6:59:50
beach
This bootstrapping thing has got to be one of the hardest things I have ever attempted.
7:00:01
no-defun-allowed
good job, that's some wizard stuff right there
7:00:12
beach
My PhD dissertation was a breeze compared to this. :)
7:00:52
beach
In theory, it is not hard, and the principles are clear in my head.
7:01:08
beach
It's the number of details that have to work that make it hard.
7:01:45
beach
On a daily basis, I get confused about the capabilities of each of the many environments.
7:02:54
beach
But the technique obviously works, and it has already proven that it fulfills its promise.
7:03:14
beach
Not long ago, I had to add a slot to a MOP class.
7:03:36
beach
It was just a matter of adding it, defining the accessor generic function, and re-build.
7:03:59
beach
That's the very purpose of this technique.
7:04:33
beach
Another purpose, of course, is to cut down on the amount of specific code that needs to be maintained.
7:04:39
shka_
so, obvious question, perhaps
7:04:47
shka_
how many envs do you actually have?
7:04:58
beach
During bootstrapping, currently 5.
7:05:17
beach
There might be a 6th one, but that should be enough.
7:06:13
shka_
anyway, regarding bootstrapping
7:06:19
no-defun-allowed
if you have three stages of bootstraping, that's two per stage
7:06:55
beach
no-defun-allowed: Currently, I have phases 0, 1, 2, and 3.
7:07:05
shka_
so your goal right now is to build lisp image of sicl?
7:07:06
beach
At least one more will be added.
7:07:26
beach
shka_: Yes, a Linux executable.
7:07:45
beach
Maybe a shared object and an executable. But that can wait.
7:08:25
beach
Actually, an intermediate step is to have a fully-functional SICL system in E4 or E5, so that I can debug code inside SBCL.
7:09:26
beach
I keep citing this example, but I really like it: (defclass symbol (t) ((%name ...) (%package ...)) (:metaclass built-in-class)) not to mention (defclass t () (:metaclass built-in-class))
7:09:55
beach
Stuff like that will cut down on any use of a special mechanism for managing those classes.
7:10:00
shka_
how built-in-class actually work?
7:10:11
beach
It's a normal MOP class.
7:10:12
shka_
in terms of slot storage
7:10:27
shka_
yeah, i figure this much ;-)
7:10:46
shka_
but it's have reason to exist
7:11:30
beach
shka_: Yes, the system might not allow the definition of subclasses of built-in classes.
7:11:46
beach
shka_: I will probably disallow some of those.
7:12:10
beach
Certainly, things like NUMBER and LIST will not be possible to subclass.
7:12:58
shka_
i will take a look at this metaclass
7:13:24
beach
shka_: So there is still a use for built-in classes. The point here is that I can use the MOP machinery for definitions that most implementations must have long before CLOS is available.
7:13:46
shka_
i simply wonder how customized mop magic is in there
7:14:03
beach
So those implementation need specific code (which in addition is implementation specific) in order to define those classes.
7:14:25
beach
shka_: I use absolutely no customized magic.
7:14:46
beach
It is all pure use of the SICL MOP implementation.
7:14:55
beach
Modulo some bootstrapping-specific code.
7:15:02
beach
Currently 1075 lines.
7:17:44
beach
And most of the bootstrapping-specific code is for the early phases. From now on (phase 3, etc.) the entire machinery should work, so I can just load files containing DEFCLASS, DEFGENERIC, and DEFMETHOD forms.
7:18:05
beach
That was part of the purpose of the clean-up of the past few days.
7:19:38
beach
Oh, here is another important aspect: The fact that I can write (defclass symbol (t) ((%name ...) (%package ...)) (:metaclass built-in-class)) means that I have a perfectly good description of the SYMBOL class that does not depend on any particular system-specific machinery.
7:19:47
shka_
well there is allocate-instance
7:19:59
shka_
but yeah, nothing magical in here
7:20:08
beach
Very simple stuff, yes.
7:20:32
beach
Therefore, any implementation who wishes to use the definition of the SYMBOL class can just copy it, and perhaps add some slots.
7:20:34
shka_
i was just checking built-in-class
7:20:59
shka_
it is amusingly basic
7:21:01
beach
That implementation has to come up with some bootstrapping technique similar to that of SICL, of course.
7:21:07
beach
Yeah, there is nothing in there.
7:22:09
beach
In fact, the SICL definition of it probably has some code duplication at the moment.
7:24:32
beach
Again, the point is that I can easily fix such problems and then just re-build. No other dependencies exist.
7:50:02
no-defun-allowed
ACTION uploaded an image: Screenshot_2018-10-18_18-01-16.png (296KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/cpCwtWaKbIxnawGnejHvJCvE >
7:54:38
shka_
no-defun-allowed: 10/10 would read
7:55:30
scymtym
what kind of first name is "not", though
7:56:00
no-defun-allowed
Not Harold Ableson was involved in paren matching.
7:57:23
no-defun-allowed
Dedication: This book is dedicated to everyone who says "Good morning" even though it's the afternoon where they live.
10:19:56
beach
Hmm. I shouldn't need to explicitly finalize the classes either. That should be taken care of by MAKE-INSTANCE.
10:20:12
beach
So there is more code to be removed at some later point in time.
Thursday, 18th of October 2018, 11:54:48 UTC