-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no longer commit loadups; start with starter.sysout #430
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that the script should have a built-in reference to the venuesysout. It should point to a makeinit-sysout, which may start out as the venuesysout.
But we may introduce makeinit dependencies on new features over time (after careful thought).
i started to add a 'starter.sysout' with a copy but I think it's a minor point to change the script, if we need to make dependencies on new stuff that isn't patchable in sources/LOADUP-INIT.LISP. |
This is odd -- it provoked a deadlock in the X code, let me look at this before we merge this.
|
As per earlier messages, I don’t favor depending on the venuesysout other than as an emergency back off.
That was a necessary starting point before we could do our own makeinits, but that sysout was constructed by loading lots of things on top of other things, to try to make it consistent with changes to the environment. We were lucky that it didn’t fall over itself while we needed it.
I would not want to have to debug anything in a system whose history is unknown, if it it is at all possible to avoid it.
… On Aug 24, 2021, at 6:30 PM, Nick Briggs ***@***.***> wrote:
This is odd -- it provoked a deadlock in the X code, let me look at this before we merge this.
* thread #1: tid = 0x1565d9, 0x97d0b422 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x97d0b422 libsystem_kernel.dylib`__psynch_mutexwait + 10
frame #1: 0x9a819c62 libsystem_pthread.dylib`_pthread_mutex_lock_wait + 99
frame #2: 0x9a81712b libsystem_pthread.dylib`pthread_mutex_lock + 120
frame #3: 0x002ea25a libxcb.1.dylib`xcb_writev + 35
frame #4: 0x001f0f88 libX11.6.dylib`_XSend + 321
frame #5: 0x001f0de9 libX11.6.dylib`_XEventsQueued + 59
frame #6: 0x001e5d1b libX11.6.dylib`XPending + 49
frame #7: 0x0016f34c ldex`getXsignaldata(dsp=0x001b0c68) + 44 at xwinman.c:186
frame #8: 0x0015b1e8 ldex`getsignaldata(sig=23) + 360 at keyevent.c:309
frame #9: 0x97be179b libsystem_platform.dylib`_sigtramp + 43
frame #10: 0x97d0d3e7 libsystem_kernel.dylib`__writev + 11
frame #11: 0x002e95b3 libxcb.1.dylib`_xcb_conn_wait + 681
frame #12: 0x002ea2d0 libxcb.1.dylib`_xcb_out_send + 61
frame #13: 0x002ea27f libxcb.1.dylib`xcb_writev + 72
frame #14: 0x001f0f88 libX11.6.dylib`_XSend + 321
frame #15: 0x001f18eb libX11.6.dylib`_XReply + 85
frame #16: 0x001ee406 libX11.6.dylib`XSync + 82
frame #17: 0x001d527c libX11.6.dylib`XCloseDisplay + 216
frame #18: 0x0016a742 ldex`lisp_Xexit(dsp=0x001b0c68) + 178 at xinit.c:120
frame #19: 0x0013c299 ldex`display_before_exit + 41 at initdsp.c:234
frame #20: 0x00163a7b ldex`device_before_exit + 11 at initkbd.c:234
frame #21: 0x0013a5c3 ldex`lisp_finish + 51 at vmemsave.c:536
frame #22: 0x0011f2b5 ldex`OP_subrcall(subr_no=13, argnum=1) + 8069 at subr.c:429
frame #23: 0x0010bf39 ldex`dispatch + 20457 at xc.c:653
frame #24: 0x00136d76 ldex`start_lisp + 422 at main.c:592
frame #25: 0x00136556 ldex`main(argc=2, argv=0xbff167c4) + 1942 at main.c:539
frame #26: 0x913876ad libdyld.dylib`start + 1
(lldb)
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMHLFDQLPSGUXEOGC3T6RBUBANCNFSM5CXRTVKA>.
|
I updated the PR to use 'starter.sysout' as the name in loadups of what to start with. Taken from the master's lisp.sysout as of 19 aug 2021 12:07 |
GREET was being called before (MEDLEY-INIT-VARS) because MEDLEYDIR file was loaded in loadup before HIST now. |
The greet/directory-setting problem has been fixed, loadup now goes through. |
I don't see the review button, but the issues that I commented on earlier have been fixed. Loadups go through, final sysout is good. Running the copy-all scripts doesn't produce changes, so the build artifacts are ignored. The only thing I noticed, and maybe it has already been that way, is that my init file is loaded at the start of the exports.all and where-is phases. So there is a risk that things in my init could (or have been) contaminating those data sets. I would push the approve button, but it isn't showing up on my screen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found the review button. This looks good to me, Nick may still have concerns.
I've created a PR for maiko to incorporate some trivial changes to fix the X deadlock. Once that's merged I have a plan for reworking a bunch of the code. |
merge with previous changes was problematic so this is third try