-
-
Notifications
You must be signed in to change notification settings - Fork 27
Rmk103 font and related code updates #2216
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
base: master
Are you sure you want to change the base?
Conversation
Convention that files in full should be in library not lispusers
to control font coercion heuristics.
I checked out this PR on Linux Mint 22.1 Cinnamon and the apps sysout fails with the error
![]() I'm attaching the The Medley head:
The Maiko head on master:
|
Did you try loadup-full.sh ?
… On Jul 17, 2025, at 1:27 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
I checked out this PR on Linux Mint 22.1 Cinnamon and the apps sysout fails with the error File not found: MCCS error during GREET...:
***@***.***:~/medley/medley$ ./scripts/loadup-all.sh -apps
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
apps-sysout-error.png (view on web) <https://github.com/user-attachments/assets/81ce6676-b899-4083-b91b-3106571aadcf>
I'm attaching the loadups directory: loadups.zip <https://github.com/user-attachments/files/21288219/loadups.zip>
The Medley head:
commit b8b2108 (HEAD -> rmk103--Font-and-related-code-updates, origin/rmk103--Font-and-related-code-updates)
The Maiko head on master:
commit fc90838ad84a152bfc70ce1d091b13166d0bf0d5
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNF2KYC5TTDB6LJORT3I5M7PAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBTGEZDOMZXGU>.
You are receiving this because you authored the thread.
|
With
![]() The |
(These were for the next phase)
I fetch and try it now.
MCCS is for the next phase, not for this PR. git wasn't removing it from my directory when I switched branches, so my loadups were OK.
… On Jul 17, 2025, at 9:28 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
With loadup-full.sh I get the same error File not found: MCCS error during GREET...:
***@***.***:~/medley/medley$ ./scripts/loadup-full.sh
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
loadup-full-error.png (view on web) <https://github.com/user-attachments/assets/63cbb89e-7f5d-4c20-916b-0a3aef3629b6>
The loadups directory: loadups.zip <https://github.com/user-attachments/files/21301093/loadups.zip>
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOH5FBHKDGVPPMBD3T3I7FJHAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBUGY4DQNRUGQ>.
You are receiving this because you authored the thread.
|
I updated to commit f93cc9e and the apps sysout failed with the error
![]() The |
Thanks for pushing on this.
I just made a separate commit for MEDLEYFONTFORMAT, although according to GITFNS it was already there (locally).
I think there is a glitch in the way GITFNS and git interact when branches are changed. Old Medley version may be left around in the git directory, and GITFNS doesn't understand that they are not part of the new branch.
Would we get better behavior if GITFNS treated the git directory as {UNIX} instead of {DSK}, when it compares files with the working directory, or moves files around?
… On Jul 17, 2025, at 10:31 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
I updated to commit f93cc9e <f93cc9e> and the apps sysout failed with the error File not found: MEDLEYFONTFORMATerror during GREET...
***@***.***:~/medley/medley$ ./scripts/loadup-all.sh -apps
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
loadup-all-error.png (view on web) <https://github.com/user-attachments/assets/092b6c95-f4f8-4d0f-aa52-1d09f4d7ebe9>
The loadups directory: loadups.zip <https://github.com/user-attachments/files/21301852/loadups.zip>
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPLJBAUST5CQ6QCAI33I7MVVAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBUHA3TSOJZGE>.
You are receiving this because you authored the thread.
|
OK, loadups work with the MEDLEYFONTFORMAT now present. Untracked files don't get deleted by git when you switch between branches, so if there's a new file that you forgot to commit then changing branches will leave it there and presumably GITFNS will think it's also in the branch it switched to. If a file was committed in one branch and then you switch to a branch where it doesn't exist then it will get deleted. I don't know that treating things as |
I updated to commit 51d2cc6 and the apps loadup failed with the error (the Medley window was closed):
The dribble files: loadups-dribble.zip |
Hmm, I see the same failure. It appears that it builds all the sysouts OK, including apps, but then fails when it is trying to do the aux.
And that phase fails even with loadup-all.sh, which only does the full before it does the aux.
It typescript shows a reference to loadups/build/logindir/vmem/lisp_loadup-aux_1.virtualmem, which doesn't exist. Could that be because the error happens before that should have been created, or is the error that it should have been created and it isn't there?
… On Jul 17, 2025, at 11:08 AM, Paolo Amoroso ***@***.***> wrote:
pamoroso
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
I updated to commit 51d2cc6 <51d2cc6> and the apps loadup failed with the error (the Medley window was closed):
***@***.***:~/medley/medley$ ./scripts/loadup-all.sh -apps
>>>>> START loadup-init
"/home/paolo/bin/lde" "/home/paolo/medley/medley/internal/loadups/starter.sysout" -id "loadup_init_1" -title "Medley::loadup_init_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/loadups/build/loadup-init.init"
REM.CM FILE: ""
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_init_1.virtualmem"
+++++ SUCCESS +++++
[...]
>>>>> START loadup-apps-from-full
"/home/paolo/bin/lde" "/home/paolo/medley/medley/loadups/build/full.sysout" -id "loadup_apps_from_full_1" -title "Medley::loadup_apps_from_full_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/home/paolo/medley/medley/loadups/build/loadup-apps-from-full.cm"
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_apps_from_full_1.virtualmem"
+++++ SUCCESS +++++
..... files created .....
-rw-rw-r-- 1 paolo paolo 12692 Jul 17 19:59 /home/paolo/medley/medley/loadups/build/apps.dribble
-rw-rw-r-- 1 paolo paolo 13494272 Jul 17 19:59 /home/paolo/medley/medley/loadups/build/apps.sysout
<<<<< END loadup-apps-from-full
Added RDSYS.~40~ to library
Linked RDSYS to RDSYS.~40~ in library
Added RDSYS.LCOM.~40~ to library
Linked RDSYS.LCOM to RDSYS.LCOM.~40~ in library
Added lisp.sysout to loadups
Added lisp.dribble to loadups
Added full.sysout to loadups
Added full.dribble to loadups
Added apps.sysout to loadups
Added apps.dribble to loadups
>>>>> START loadup-aux
"/home/paolo/bin/lde" "/home/paolo/medley/medley/loadups/full.sysout" -id "loadup_aux_1" -title "Medley::loadup_aux_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/home/paolo/medley/medley/loadups/build/logindir"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/home/paolo/medley/medley/loadups/build/loadup-aux.cm"
VMEM FILE: "/home/paolo/medley/medley/loadups/build/logindir/vmem/lisp_loadup_aux_1.virtualmem"
----- FAILURE loadup-aux-----
..... files created .....
<<<<< END loadup-aux
----- loadup-all: FAILURE -----
The dribble files: loadups-dribble.zip <https://github.com/user-attachments/files/21302489/loadups-dribble.zip>
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO2PSC3XRYV5FQI3DL3I7RABAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBUHE3TMNRYGA>.
You are receiving this because you authored the thread.
|
It's failing the
|
Except for the relatively small additional code, the difference related to fonts is that it instantiates the medleyfontformats gacha 10 (after the makeinit) and helvetica 10 (in the lisp phase).
But those shouldn't really take any more time and shouldn't be noticeably bigger. Although those files now include all known glyphs in all character sets, only charset 0 is instantiated and it only has the additional bitmaps for characters that were not in the original displayfont/c0/ files and were therefore filled in from terminal/modern/classic (probably in the 8-bit part of the charset). But spacewise, that should be in the noise.
And there shouldn't be a noticeable difference in time, since getting charset 0 basically just validates the file headers, jumps to the charset dispatch vector, jumps to the charset, and reads the charset (mostly using BINS). It has to search for the file, but that should be a little bit faster, since DISPLAYFONTDIRECTORIES is smaller, and it should hit the medleyfont file on the first probe.
In the full-from-lisp phase, there is currently a little more going on, since there is old code there to precache a bunch of fonts and character sets. And it seems to hang up for a second or two a little later (maybe when it gets to grapher) where it may be trying to precalculate a bunch of font sizes.
The fonts in the full phase should take a bit longer now, because it is still going to the displayfont files from which it now does online the glyph-completion coercions that it never did before. Those will be precomputed when all the fonts are switched over.
But 1.5% bigger and 10% longer, I wouldn't have expected anything even close to that.
… On Jul 17, 2025, at 11:03 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
OK, loadups work with the MEDLEYFONTFORMAT now present.
lisp.sysout is now about 1.5% bigger and a full loadup takes about 10% longer than it used to. Not sure why.
Untracked files don't get deleted by git when you switch between branches, so if there's a new file that you forgot to commit then changing branches will leave it there and presumably GITFNS will think it's also in the branch it switched to. If a file was committed in one branch and then you switch to a branch where it doesn't exist then it will get deleted. I don't know that treating things as {unix} would help -- at least not that problem.
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO3IW4UPYH2FSIXS4D3I7QQRAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBUHE3DENZTGU>.
You are receiving this because you authored the thread.
|
The space increase is reproducible, the time for a |
I pushed FILESETS again, give it another try.
I had to back out another reference to MCCS in EXPORTFILES, which is part of aux but not part of the loadup.
… On Jul 17, 2025, at 11:58 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
It's failing the -aux part because:
{DSK}<Users>briggs>Projects>medley>sources>FILESETS.;1
File created 17-Jul-2025 09:32:58
FILESETSCOMS
File not found: MCCS
4>
(IL:LOGOUT T 1)
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL3OJ7RV4NSAYDJUBD3I7W5ZAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBVGEYDSMRYG4>.
You are receiving this because you authored the thread.
|
Oops, committed but forgot to push. Try now.
… On Jul 17, 2025, at 12:09 PM, Ron Kaplan ***@***.***> wrote:
I pushed FILESETS again, give it another try.
I had to back out another reference to MCCS in EXPORTFILES, which is part of aux but not part of the loadup.
> On Jul 17, 2025, at 11:58 AM, Nick Briggs ***@***.***> wrote:
>
>
> nbriggs
> left a comment
> (Interlisp/medley#2216)
> <#2216 (comment)>
> It's failing the -aux part because:
>
> {DSK}<Users>briggs>Projects>medley>sources>FILESETS.;1
> File created 17-Jul-2025 09:32:58
> FILESETSCOMS
> File not found: MCCS
>
> 4>
> (IL:LOGOUT T 1)
> —
> Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJL3OJ7RV4NSAYDJUBD3I7W5ZAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBVGEYDSMRYG4>.
> You are receiving this because you authored the thread.
>
|
I see a 1% difference in space against the current master, not 1.5%, the lisp at 1.04, the full at 1.01. The lisp is about 94K bytes bigger than the master, the full is about 458K. That might not be outrageous at this point, if it's rummaging around through all the coercions.
… On Jul 17, 2025, at 12:09 PM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2216)
<#2216 (comment)>
The space increase is reproducible, the time for a ./loadup -f isn't consistent - there may be something else going on with the timing.
—
Reply to this email directly, view it on GitHub <#2216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJUS4Z3BWKMS4UMYET3I7YEZAVCNFSM6AAAAACBT3AQUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBVGE2TIMBQGM>.
You are receiving this because you authored the thread.
|
Works for me now. |
This includes changes to cleanup and simplify (somewhat) the interface and some of the internals of the FONT architecture. It also includes MEDLEYFONTFORMAT, the implementation of the new read/writable format for display and other device fonts. The changes to FONT are documented in docs/internal/FONTCODECHANGES.TEDIT, the document for MEDLEYFONTFORMAT is in docs/internal/MEDLEYFONTFORMAT.TEDIT.
Around this central core there are a bunch of files with small changes for compatibility with some of the font changes. E.g. the recursion surrounding the validation of font attributes has been flattened out, and almost all calls to \COERCEFONTDESC have been eliminated (addressing #2100).
And the loadup sequences and have been adjusted and a few functions have been moved so that medley-format fonts can be included in the MAKEINIT.
This PR includes only 2 medley-format fonts, for GACHA10 and HELVETICA10. GACHA10 is created in the MAKEINIT. HEVETICA10 a little later, when MENU is loaded. I've included them here to test that everything hangs together.
(Separately, I have created medley-format fonts for all the display fonts, but I want to release those in a separate PR after this code has settled down. The new NS fonts will be MCCS-encoded, and that will require some other adjustments.)