Rmk64: mainly separate panels for GITFNS display, FILEPOS speed up #862
Conversation
Looks better in plaintext files
GIT-CDBROWSER-SEPARATE-DIRECTIONS defaults to T
To avoid contamination with values from other files (like LAFITE)
…DWIMIFYCOMPLFG Also seprate the caseinsensitive UPPERCASEARRAY from the SEPRCASE array
About a 30% speed up in the slow (casearray/skip) case. Eventually macros should be defined for the externalformat interface functions, for now it is nice to be able to trace/break them.
particularly around EOLC
masinter
left a comment
masinter
left a comment
There was a problem hiding this comment.
the filing.types are curious -- there seem to be several variables kind of like that. Where do the numbers come from?
But this is fine.
|
This all would be a lot simpler if EOLC = CRLF were baked into a (possibly not implemented yet) EXTERNAL-FORMAT (ascii-with-crlf). |
|
@masinter I believe the FILING.TYPES come from the XNS Filing Protocol and have been extended for TEDIT, FASL, and LAFITE. Can't find a copy of the standard that has the courier program definition which should include the Type field. |
|
@masinter -- here, http://www.bitsavers.org/pdf/xerox/xns_services/services_sparc/Xerox_Globalview_Document_Services_for_Sun_Technical_Reference_Manual_Jun92.pdf tells us that The File Service recognizes the following types: The default is the unknown type (type 0). |
|
For whatever reason, Lafite has a few more
… On Jul 25, 2022, at 7:05 PM, Larry Masinter ***@***.***> wrote:
@masinter approved this pull request.
the filing.types are curious -- there seem to be several variables kind of like that. Where do the numbers come from?
But this is fine.
—
Reply to this email directly, view it on GitHub <#862 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJP7DA5LHBA5ETMYR7TVV5BX5ANCNFSM54T4NMWQ>.
You are receiving this because you authored the thread.
|
|
What do they do?
… On Jul 25, 2022, at 7:22 PM, Nick Briggs ***@***.***> wrote:
@masinter <https://github.com/masinter> -- here, http://www.bitsavers.org/pdf/xerox/xns_services/services_sparc/Xerox_Globalview_Document_Services_for_Sun_Technical_Reference_Manual_Jun92.pdf <http://www.bitsavers.org/pdf/xerox/xns_services/services_sparc/Xerox_Globalview_Document_Services_for_Sun_Technical_Reference_Manual_Jun92.pdf> tells us that
The File Service recognizes the following types:
• 7-bit ASCII files (type 2).
• Interpress files (type 4361).
• GLOBALVIEW RES canvas (type 4428).
• GLOBALVIEW CALS group 4 raster files (type 6501).
• GLOBALVIEW folder for native UNIX directories (type 1).
• GLOBALVIEW file drawer for native directories located within the root of the corresponding XNS volume (type 4498).
The default is the unknown type (type 0).
—
Reply to this email directly, view it on GitHub <#862 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLDXRZZQXZSJQGM6RLVV5DVDANCNFSM54T4NMWQ>.
You are receiving this because you authored the thread.
|
|
They get stored and retrieved with the file when you store it on an XNS file server. That list was from GlobalView documentation so they don't know anything about Interlisp's usage. I don't know if the file server does anything special, or if it's purely a client thing (more likely). Not sure if those are "officially assigned" type numbers that we're using. I believe GlobalView used it to drive which application was invoked when you opened the file (and which icon it would use on the desktop). I think of them as equivalent to the extensions without messing up the name. MasterScope might tell you if it's used anywhere (assuming we still have NSFILING etc. in the sources). |
|
They aren’t really used in the code that is masterscoped. I think they are used in Lafite/UNIXMAIL (which is where others are defined). But the files iin the LAFITE subdirectory don’t (yet) corresponding to our new LAFITE-XXX naming convention, so probably aren’t analyzed.
… On Jul 25, 2022, at 8:49 PM, Nick Briggs ***@***.***> wrote:
They get stored and retrieved with the file when you store it on an XNS file server. That list was from GlobalView documentation so they don't know anything about Interlisp's usage. I don't know if the file server does anything special, or if it's purely a client thing (more likely). Not sure if those are "officially assigned" type numbers that we're using. I believe GlobalView used it to drive which application was invoked when you opened the file (and which icon it would use on the desktop). I think of them as equivalent to the extensions without messing up the name. MasterScope might tell you if it's used anywhere (assuming we still have NSFILING etc. in the sources).
—
Reply to this email directly, view it on GitHub <#862 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO5XBP76I3XEWAOIK3VV5N3PANCNFSM54T4NMWQ>.
You are receiving this because you authored the thread.
|
|
The CRLF is the hard case, at one point I had the EOL transformations completely in line, but I had to push the CRLF into a closed function because \SUBREAD or one of the other basic read functions had more variables than the compiled code could handle.
But the complexity is isolated in the closed function, and it never gets entered unless it really does come across a CRLF file.
… On Jul 25, 2022, at 7:12 PM, Larry Masinter ***@***.***> wrote:
This all would be a lot simpler if EOLC = CRLF were baked into a (possibly not implemented yet) EXTERNAL-FORMAT (ascii-with-crlf).
Are there any CRLF files anywhere?
—
Reply to this email directly, view it on GitHub <#862 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJPPSJVF4RU6536VDMDVV5CQRANCNFSM54T4NMWQ>.
You are receiving this because you authored the thread.
|
No description provided.