HCFILES added filtering and logging details

[MattHeffron]

Add reporting of filtering "Why?"
Add reporting of the actual error Condition on files that FAIL.
Change extraction of the "hcfiles-fails.txt" to a perl program since the Condition reporting sometimes is multiple lines.

(Does the doHCFILES.yml environment include perl??)

[MattHeffron]

Here is the hcfiles-fails.txt this generated.

[rmkaplan]

I took a quick look at the failure file, particularly at the 3 that had DATEFORMAT failures. It seems that those are coming from the time-stamp object of DOC-OBJECTS, but I was unable to reproduce the failure in my system. Display and hardcopy/pdf of those files did not show an error. (The BITMAP-GALLERY had a warning that page 9 was filled with headings, but it look OK in the pdf).

DOC-OBJECTS has been on my list for a long time, but that is for a different problem (file inclusion) and doesn't relate to the timestamp object.

But as I poked around, I noticed something else that is odd about the timestamp in the DOC-OBJECTS tedit file: the text inside the timestamp object itself seems to scroll within its allotted space. That's something else to look at, but again, no failure in hardcopy.

Another side note: I think the call to TEDIT.FORMAT.HARDCOPY in HCFILES can now be replaced by the simpler
(TEDIT.TO.IMAGEFILE S DEST 'PDF)

[rmkaplan]

Is it possible to make the failure file easier for Lisp to parse? Wrap each item in parens, for starters. Maybe some keywords on the elements, to make it easier to pull them out? I'd like to be able READ the file, then map through the items to pick out various issues.

[MattHeffron]

Is it possible to make the failure file easier for Lisp to parse?

Probably... Since it is being extracted by a perl program, rather than grep.
However, what ends up in that file would need to be handled carefully, because it is possible that some error content wouldn't READ back correctly.
Embedding it in a string would need to quote any string delimiters; but for which READTABLE?
Maybe also add the line number of the hcfiles.dribble so other context could be located, e.g. TEDIT initially reports more info about Cannot read image object with GETFN HRULE.GETFN errors that isn't contained in the Condition struct that's reported here.

What would you propose?

Another possibility would be for HCFILES to report failure information directly to a FAILURES file, instead of extracting it from the dribble. The ADVICE to capture extra information could be extended to put it into this file.

[rmkaplan]

We could make a readtable that has only whitespace as seprs, colon, parens, and an escape to be used only for those. Another note: the file {MEDLEY}<internal>envos>unixmail.tedit is completely smashed--filled with zeros after the first 800 or so bytes. If we can't find a better version somewhere, it should be deleted.

…

On Apr 18, 2026, at 11:07 AM, Matt Heffron ***@***.***> wrote: MattHeffron left a comment (Interlisp/medley#2567) <#2567?email_source=notifications&email_token=AQSTUJPGYSQIWCTFCZIJXX34WO77PA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQZDQMRYGY32M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274282867> Is it possible to make the failure file easier for Lisp to parse? Probably... Since it is being extracted by a perl program, rather than grep. However, what ends up in that file would need to be handled carefully, because it is possible that some error content wouldn't READ back correctly. Embedding it in a string would need to quote any string delimiters; but for which READTABLE? Maybe also add the line number of the hcfiles.dribble so other context could be located, e.g. TEDIT initially reports more info about Cannot read image object with GETFN HRULE.GETFN errors that isn't contained in the Condition struct that's reported here. What would you propose? — Reply to this email directly, view it on GitHub <#2567?email_source=notifications&email_token=AQSTUJPGYSQIWCTFCZIJXX34WO77PA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQZDQMRYGY32M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274282867>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJPP6VVCEX443YO4RD4WO77PAVCNFSM6AAAAACX5JI74WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGI4DEOBWG4>. You are receiving this because your review was requested.

[MattHeffron]

the file {MEDLEY}envos>unixmail.tedit is completely smashed

There's a copy in the envos repo that is readable by TEDIT:
envos repo -- xd0e/lde/lafite/unixmail.tedit
I don't know if it is accurate...

[rmkaplan]

That one looks good, I'll copy it over

…

On Apr 18, 2026, at 1:52 PM, Matt Heffron ***@***.***> wrote: MattHeffron left a comment (Interlisp/medley#2567) <#2567?email_source=notifications&email_token=AQSTUJJLVSFN26ZRRXR2EXD4WPTJNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ2TINBQGI4KM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274544028> the file {MEDLEY}envos>unixmail.tedit is completely smashed There's a copy in the envos repo that is readable by TEDIT: envos repo -- xd0e/lde/lafite/unixmail.tedit <https://github.com/Interlisp/envos/blob/main/xd0e/lde/lafite/unixmail.tedit> I don't know if it is accurate... — Reply to this email directly, view it on GitHub <#2567?email_source=notifications&email_token=AQSTUJJLVSFN26ZRRXR2EXD4WPTJNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ2TINBQGI4KM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274544028>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNAQCJPFKLX2B76YZ34WPTJNAVCNFSM6AAAAACX5JI74WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGU2DIMBSHA>. You are receiving this because your review was requested.

[rmkaplan]

I wrote a little parser for that file that's good enough, not worth doing anymore

[nbriggs]

The real copy is at library/lafite/docs/release-notes/unixmail.tedit the one in internal should just be deleted.

[rmkaplan]

They're not the same. The one on internal has more stuff.

…

On Apr 18, 2026, at 4:33 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2567) <#2567?email_source=notifications&email_token=AQSTUJOYEZJ5FCWQJVZCYGL4WQGFXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ3TONBWGUZ2M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274774653> The real copy is at library/lafite/docs/release-notes/unixmail.tedit the one in internal should just be deleted. — Reply to this email directly, view it on GitHub <#2567?email_source=notifications&email_token=AQSTUJOYEZJ5FCWQJVZCYGL4WQGFXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ3TONBWGUZ2M4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274774653>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMZHZAUP54ASTNY4ND4WQGFXAVCNFSM6AAAAACX5JI74WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUG43TINRVGM>. You are receiving this because your review was requested.

[nbriggs]

The longest one I've found, which has the documentation for wrapping lines, and screen shots in it, is indeed the one that Matt found. There is also library/lafite/lafite-unixmail.tedit (from renaming the lafite modules into lafite-module)

[rmkaplan]

Looks like the one in library/lafite/ is the same as the one that Matt found and that I moved to lafite/docs--byte identical. I think the ones in internal/envos/ and llibrary/lafite/docs/ should both be deleted.

…

On Apr 18, 2026, at 5:26 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2567) <#2567?email_source=notifications&email_token=AQSTUJNZMVHIYRG35GCURID4WQMLFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ4DINZRGYYKM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274847160> The longest one I've found, which has the documentation for wrapping lines, and screen shots in it, is indeed the one that Matt found. There is also library/lafite/lafite-unixmail.tedit (from renaming the lafite modules into lafite-module) — Reply to this email directly, view it on GitHub <#2567?email_source=notifications&email_token=AQSTUJNZMVHIYRG35GCURID4WQMLFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ4DINZRGYYKM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4274847160>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLXJWEOAI3NHK5XWP34WQMLFAVCNFSM6AAAAACX5JI74WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUHA2DOMJWGA>. You are receiving this because your review was requested.

[rmkaplan]

All of the files that fail because they can't read image an object with GETFN HRULE.GETFN are from docs/dinfo/.

Those files say that they are Tedit files, but I don't think they really are. Rather, as I recall, they are a combination, maybe a concatenation, of Tedit files whose start-end byte positions are indexed from somewhere else. The last one has the Tedit magic bytes, but its byte positions aren't relative to this particular file. It's probably an accident that the first image object in all of these DINFO files is a horizontal rule, so that the error shows up in this way.

I suggest that HCFILES be fixed so that it skips the dinfo/ directory. Or else HCFILES should be made aware of the DINFO indexing.

[MattHeffron]

I suggest that HCFILES be fixed so that it skips the dinfo/ directory.

Just put a .skip file in that folder. It can be empty.

[pamoroso]

On Linux Mint 22.1 Cinnamon I ran HCFILES at commit 6a9733a and it completed with a permission denied error:

paolo@lispmachine:~/medley/medley/scripts$ ./do_hcfiles.sh 
"/home/paolo/bin/lde" "/home/paolo/medley/medley/loadups/apps.sysout" -id "hcfiles_1" -title "Medley::hcfiles_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/tmp/hcfiles-26701"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/tmp/hcfiles-26701/hcfiles.cm"
VMEM FILE: "/tmp/hcfiles-26701/vmem/lisp_hcfiles_1.virtualmem"
Added hcfiles.dribble to /home/paolo/medley/medley/loadups
./do_hcfiles.sh: 61: /home/paolo/medley/medley/scripts/getFails.pl: Permission denied
Added hcfiles-fails.txt to /home/paolo/medley/medley/loadups
paolo@lispmachine:~/medley/medley/scripts$ ls -l getFails.pl 
-rw-rw-r-- 1 paolo paolo 887 Apr 23 10:51 getFails.pl

This is the (empty) log file: hcfiles-fails.txt

Other than that the generated PDF and HTML files look fine.

[pamoroso]

At commit 921955e the HCFILES process completes with no apparent issues and the generated files look fine:

paolo@lispmachine:~/medley/medley/scripts$ ./do_hcfiles.sh 
"/home/paolo/bin/lde" "/home/paolo/medley/medley/loadups/apps.sysout" -id "hcfiles_1" -title "Medley::hcfiles_1" -g 1024x768 -sc 1024x768 -noscroll
MEDLEYDIR: "/home/paolo/medley/medley"
LOGINDIR: "/tmp/hcfiles-4182"
GREET FILE: "/home/paolo/medley/medley/greetfiles/NOGREET"
REM.CM FILE: "/tmp/hcfiles-4182/hcfiles.cm"
VMEM FILE: "/tmp/hcfiles-4182/vmem/lisp_hcfiles_1.virtualmem"
Added hcfiles.dribble to /home/paolo/medley/medley/loadups
Added hcfiles-fails.txt to /home/paolo/medley/medley/loadups