🚀 go-pugleaf

Dr.Ruud <rvtol+news@isolution.nl> schreef in bericht <ct8ugk.4n8.1@news.isolution.nl>...

> Toen ik Bastiaan kietelde, kwam er dit uit:
> > Dr.Ruud:
> >> Bastiaan:
> 
> >>> Een expanded tab heeft een lengte die van zijn positie in de regel
> >>> afhangt.
> >>> Dat is nou juist de niet te berekenen factor. Tenminste, is alleen
> >>> te berekenen als je van het begin af de tabs expandeert. Daarom is
> >>> het zo onbegrijpelijk dat LIST dat zo snel doet. Hij lijkt dus 16
> >>> MB te kunnen
> >>> behandelen in minder dan 1 sec. Of... er moet een andere manier
> >>> zijn.
> 
> >> Zoiets kun je best vanaf het einde doen?
> >>
> >> Je gaat er initieel van uit dat het laatste teken van de file op de
> >> laatste schermpositie komt. Je loopt vervolgens terug in de buffer
> >> tot je het scherm af hebt. Als je een tab tegenkomt, dan bekijk je
> >> of je het deel wat je al gedaan hebt, kunt laten staan of dat je
> >> moet corrigeren. (dit alles alleen als je geen newlines hebt)
> 
> > Nee, dat gaat niet.
> 
> Ja, dat gaat wel.
> 
> 
> > De positie van zeg maar het laatste teken is
> > afhankelijk van de filegrootte �n �lle tabs (�n hun positie) in
> > de hele file.
> 
> Zoek even in wat ik schreef naar het woord "corrigeren". Geef anders
> eens precies de structuur aan van een file waarmee het volgens jou
> niet kan.
> 
> Eigenlijk heb je maar twee soorten: om de 1-7 tekens een tab, en om
> de 8+ tekens een tab. Alle andere bestanden zijn daar variaties op.
> Het maakt niet uit of er al dan niet CR-LFs in staan.
> 
> Het ligt er wel nog aan of je een tab minimaal 1 spatie wil laten
> opleveren: 1234567<tab>ABC, staat de A dan op positie 8 (ofwel tab
> compression) of liever op 16?
> 
> 
> > Ik weet nog wel een manier: zelf een filebuffer beheren.
> 
> Dat is onderdeel van elke oplossing die al aan je is voorgesteld.
> En die buffer hoeft maar een paar kB groot te zijn. Je leest
> alleen het laatste deel van de file (in e1n keer) van schijf.

Als ik het nog eens uitleg val ik ernstig in herhaling. In elk
geval is een blok inlezen van het laatste deel niet de manier. Je
weet dan de beginpositie niet. Dat is toch niet zo moeilijk? Als
de file 16.000.010 bytes is, zou je laatste page 10 bytes groot
kunnen zijn. Is er echter ergens op (MOD 80) pos 1 een tab, dan
is de laatste page 17 bytes. Zo kan elke tab, waar ook in de file,
de positie van die laatste page be�nvloeden. Om te weten waar die
begint, moet je de gehele file lezen.

Het staat voor mij nu vast dat Vernon de gehele file leest als je
naar End gaat, maar hoe, dat is de vraag. Ik weet niet eens een
manier in BASIC om een sector te lezen. Ik kan het wel, maar dat
is geen basic, maar ik geloof machinetaal. Maar dat maakt de zaak
er niet eenvoudiger op.


Hartelijk dank, Bastiaan.