pcref decode_clock_value_$date_time
peruse_crossref: Not found: decode_clock_value_$date_time
crossref generates the data that is used by pcref; it formats the data to be both human-readable and pcref readable. The human-readable code is doing a line break for lone entry point names, and pcref does not know how to parse that line break.
Rather then fixing the pcref parser, adjusting the margins in the human-reading code in crossref is much easier.
qedx
r cref_filegen_.pl1
/syn_ma/
syn_margin initial (30),
s/30/50/
p
syn_margin initial (50),
.+1
title_margin initial (20),
s/20/40/
w
q
This prevents the line break for long entry point names, and code inspection of crossreference and pcref leads me to beleive that this change is benign.
I just generated a new crossref on GHM. Below you can see the output of pcref when accessing, first, the original total.crossref from MR12.6e, and second, the new total.crossref created with the a crossref that includes the above fix (MCR10022):
pcref decode_clock_value_$date_time
peruse_crossref: Not found: decode_clock_value_$date_time
r 16:43 0.196 62
pcref [hd]>total.crossref decode_clock_value_$date_time
References to decode_clock_value_$date_time: (bound_date_time_ in HARDCORE)
amu_print_.pl1, as_meters.pl1, azm_display_fdump_events.pl1,
gen_pl1_version_.pl1, gtss_abs_login_banner_.pl1,
gtss_abs_logout_banner_.pl1, imft_mail_interface_.pl1,
mail_table_mgr_.pl1, meter_fnp_idle.pl1, mlsys_format_.pl1,
mlsys_misc_utils_.pl1, mtape_control_.pl1,
pascal_area_management_.pl1, rdm_msg_requests_.pl1,
tape_ansi_control_.pl1, trace_time_.pl1, vrm_meter.pl1
r 16:43 0.417 2
On Fri, Jan 13, 2017 at 4:46 PM, Eric Swenson eswenson1@users.sf.net
wrote:
The bug manifested it self as:
The 'SEE' being on it's own line is what breaks pcref.
Grepping the new total.crossref for '^[ ]*SEE"' (or something like that)
would help verify that all cases were caught by the fix.
-- Charles
Closing as ticket moved here: http://multics-trac.swenson.org/ticket/37