🚀 go-pugleaf

Bastiaan wrote:
> Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik
> een viewer maken in BASIC, die een grote (20 MB) tekstfile met
> alleen carriage return, line feed en tab, moet weergeven. Hij
> moet de stuurtoetsen gebruiken, en kunnen kiezen uit linewrap,
> of juist uit het veld lopen.

BASIC lijkt me niet de meest geschikte keuze voor het efficient beheren 
van zo'n grote tekstfile.

> 
> Ik heb al wat onderzoek gedaan, en loop tegen het volgende aan:
> Als ik met 'End' naar het einde van de file ga, heb ik toch de
> informatie nodig waar de regels beginnen. Om die pointers van
> het begin der regels allemaal in te lezen, duurt veel te lang.

In principe hoef je niet te weten waar *alle* regels beginnen; je hoeft 
alleen te weten waar de *zichtbare* regels zich bevinden.


> Gewoon het begin opzoeken, dus gewoon het aantal regels terug
> tellen vanaf het eind, vergt wel een hoop rekenwerk, zeker
> omdat er ook nog tabs tussen (kunnen) zitten.

Dit snap ik niet. Tenzij je regels heel erg lang zijn (en als word wrap 
aanstaat zou dat al niet eens meer belangrijk moeten zijn), moet je als 
je vanaf het einde van het bestand gewoon terugtelt snel de beginpositie 
van de zichtbare regels kunnen bepalen.

> 
> Ik denk dat het ideaal is om alle regelbeginpointers in te lezen
> in b.v. machinetaal, maar is dat ook zo? Hoe kan ik 't het beste
> doen? Iemand vaker met dit bijltje gehakt?

Gebruik *zo min mogelijk* machinetaal. Het zorgt er alleen maar voor dat 
je programma verschrikkelijk moeilijk wordt om naar andere platforms te 
porten. Gebruik liever een higher-level taal die je wat meer low-level 
mogelijkheden biedt, zoals C(++) of Pascal.

groente
-- Sander
groente
-- Sander

H. J. Sander Bruggink <sanderbruggink@hotmail.com> schreef in bericht <cs8nq1$g19$1@husserl.admin.phil.uu.nl>...

> Bastiaan wrote:
> > Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik
> > een viewer maken in BASIC, die een grote (20 MB) tekstfile met
> > alleen carriage return, line feed en tab, moet weergeven. Hij
> > moet de stuurtoetsen gebruiken, en kunnen kiezen uit linewrap,
> > of juist uit het veld lopen.
> 
> BASIC lijkt me niet de meest geschikte keuze voor het efficient beheren 
> van zo'n grote tekstfile.

Maar ja, het moet toch maar.

> 
> > Ik heb al wat onderzoek gedaan, en loop tegen het volgende aan:
> > Als ik met 'End' naar het einde van de file ga, heb ik toch de
> > informatie nodig waar de regels beginnen. Om die pointers van
> > het begin der regels allemaal in te lezen, duurt veel te lang.
> 
> In principe hoef je niet te weten waar *alle* regels beginnen; je hoeft 
> alleen te weten waar de *zichtbare* regels zich bevinden.

Dan moet ik dat begin van die laatste 'page' toch berekenen, en dat
is best gecompliceerd als er tabs en langere regels tussen zitten.
Temeer nog als die laatste page begint bij een afgebrokenn regel.
Maar het is niet ondoenlijk.

> 
> > Gewoon het begin opzoeken, dus gewoon het aantal regels terug
> > tellen vanaf het eind, vergt wel een hoop rekenwerk, zeker
> > omdat er ook nog tabs tussen (kunnen) zitten.
> 
> Dit snap ik niet. Tenzij je regels heel erg lang zijn (en als word wrap 
> aanstaat zou dat al niet eens meer belangrijk moeten zijn), moet je als 
> je vanaf het einde van het bestand gewoon terugtelt snel de beginpositie 
> van de zichtbare regels kunnen bepalen.

Ja, maar toch is dit best gecompliceerd met tabs en langere regels.

> 
> > Ik denk dat het ideaal is om alle regelbeginpointers in te lezen
> > in b.v. machinetaal, maar is dat ook zo? Hoe kan ik 't het beste
> > doen? Iemand vaker met dit bijltje gehakt?
> 
> Gebruik *zo min mogelijk* machinetaal. Het zorgt er alleen maar voor dat 
> je programma verschrikkelijk moeilijk wordt om naar andere platforms te 
> porten. Gebruik liever een higher-level taal die je wat meer low-level 
> mogelijkheden biedt, zoals C(++) of Pascal.

Het hoeft niet geport te worden, maar C(++) en Pascal of Delphi ken ik
niet. Dus dat wordt rekenen. Naar het begin van de laatste regel, dan
weer terug om de tabs te bepalen, dan kijken hoeveel afbrekingen er zijn,
enz. Maar het zal wel lukken denk ik. Al blijven Page Up en Pijl Up knap
ingewikkeld.


Hartelijk dank, Bastiaan.

Bastiaan wrote:

> Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik
> een viewer maken in BASIC, die een grote (20 MB) tekstfile met
> alleen carriage return, line feed en tab, moet weergeven. Hij
> moet de stuurtoetsen gebruiken, en kunnen kiezen uit linewrap,
> of juist uit het veld lopen.
> 
> Ik heb al wat onderzoek gedaan, en loop tegen het volgende aan:
> Als ik met 'End' naar het einde van de file ga, heb ik toch de
> informatie nodig waar de regels beginnen. Om die pointers van
> het begin der regels allemaal in te lezen, duurt veel te lang.

Je kunt naar het eind van de file gaan en dan 4 Kb terug.
Dat dan lees je die 4 Kb in een buffer.  Binnen die buffer kun je alle
crlf paren opzoeken en in een tabelletje zetten. Als wordwrap aanstaat
kun je ook de gewrapte beginen opnemen.
Daarna kun een precies aantal regels displayen en simpel up en down
scrollen.

Of dit allemaal wel zo handig gaat in basic weet ik niet.

Wil je het echt goed doen dan moet je met twee buffers werken.

-- 
Wil je ook niet voor muisklikken gaan betalen?
Stem dan tegen de Europesegrondwet.

pim. ReplyTo: nospam4me [at] schaeffer.tk


In be.comp.programming Bastiaan <bastiaan@niet.net> wrote:
> Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik een viewer
> maken in BASIC, die een grote (20 MB) tekstfile met alleen carriage return,
> line feed en tab, moet weergeven. Hij moet de stuurtoetsen gebruiken, en
> kunnen kiezen uit linewrap, of juist uit het veld lopen.

You must be mad...

Ik weet niet op welke architectuur dit moet draaien, maar ik ben er bijna
zeker van dat je less <http://www.greenwoodsoftware.com/less/> erop aan de
praat kunt krijgen zonder al te veel zwarte magie.

> Ik denk dat het ideaal is om alle regelbeginpointers in te lezen in b.v.
> machinetaal, maar is dat ook zo? Hoe kan ik 't het beste doen? Iemand vaker
> met dit bijltje gehakt?

Over welke architectuur gaat het?  Sommige architecturen hebben daar redelijk
prettige instructions voor...

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  In a hierarchical system, the rate of pay varies
  inversely with the unpleasantness and difficulty
  of the task.

H. J. Sander Bruggink wrote:

>> Ik heb al wat onderzoek gedaan, en loop tegen het volgende aan:
>> Als ik met 'End' naar het einde van de file ga, heb ik toch de
>> informatie nodig waar de regels beginnen. Om die pointers van
>> het begin der regels allemaal in te lezen, duurt veel te lang.
> 
> In principe hoef je niet te weten waar *alle* regels beginnen; je
> hoeft alleen te weten waar de *zichtbare* regels zich bevinden.

Ik zit boven aan mijn document, en druk nu op "End". De zichtbare regels
bevinden zich aan het einde van het document. En dus moet je wel weten
waar die zich bevinden. 

Of: ik druk snel 20x page down. In de editor die ik gebruik werkt dat
snel, ook met 50 MB :-D (Sterker, ik kan "Goto regel 76612 doen). 

>> Gewoon het begin opzoeken, dus gewoon het aantal regels terug
>> tellen vanaf het eind, vergt wel een hoop rekenwerk, zeker
>> omdat er ook nog tabs tussen (kunnen) zitten.
> 
> Dit snap ik niet. Tenzij je regels heel erg lang zijn (en als word
> wrap aanstaat zou dat al niet eens meer belangrijk moeten zijn),

Dat is zeker belangrijk als 1 lange regels gebroken wordt over zeg 20
visuele regels. B.v. voor het updaten van de scrollbar. 

> moet je als 
> je vanaf het einde van het bestand gewoon terugtelt snel de
> beginpositie van de zichtbare regels kunnen bepalen.

Ja, ff terugtellen van 20 MB.

>> Ik denk dat het ideaal is om alle regelbeginpointers in te lezen
>> in b.v. machinetaal, maar is dat ook zo? Hoe kan ik 't het beste
>> doen? Iemand vaker met dit bijltje gehakt?
> 
> Gebruik *zo min mogelijk* machinetaal. Het zorgt er alleen maar voor
> dat je programma verschrikkelijk moeilijk wordt om naar andere
> platforms te porten.

Ik kan mij niet voorstellen dat dat hier een issue is.

> Gebruik liever een higher-level taal die je wat meer low-level 
> mogelijkheden biedt, zoals C(++) of Pascal.

Een goede BASIC doet dat ook. (BBC Basic V b.v.)

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

> Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik
> een viewer maken in BASIC, die een grote (20 MB) tekstfile met
> alleen carriage return, line feed en tab, moet weergeven. Hij
> moet de stuurtoetsen gebruiken, en kunnen kiezen uit linewrap,
> of juist uit het veld lopen.
Het kan eigenlijk v��l eenvoudiger; alleen het openen duurt iets langer;
maar: Win gebruikt swap file... dus... gaat nu v��l sneller dan 20 jaar 
geleden!
Ik lees dat je nogal bezig bent met pointers & co te onthouden...
Echt niet nodig! Hoe dan wel?
Lees eerst het bestand sekwentieel, met als enig doel de langste string te
onthouden.
Maak een nieuw bestand; het eigenlijke "leesbestand".
Dit bestand is niet sekwentieel doch random access... met de inhoud
van je "bronbestand". (breedt = lengte langste string "moederbestand"
Als je weet hoeveel lijnen je binnen je "werkvenster" staan, wordt
het een fluitje van een cent om de gegevens op je scherm te toveren,
en scrollen, page up... home, end, etc etc... ook line wrap toepassen!!
Voor echt grote bestanden moet je ook een extra page up & down
voorzien; zo eentje die een % functie aantal lijnen scrolt... leuk extraatje
(ja kan zelfs een lijntellertje etc onderaan op je scherm toveren...)
Zelfd editeren wordt dan ook heel ��nvoudig...
Extra voordeel: h��l weinig werkgeheugen
(zoals in de oude tijd: 80 karakters, 25 lijnen; =  2000 bytes geheugen..
probeer dat maar eens met Notepad! (20 MB kan ie toch niet..)

Ik weet zeker dat je het kan doen in minder dan 50 lijnen... QB4.5
All�z, succes & prettig weekend!
Hubert

H,Schampheleer <hubert@haps.be> schreef in bericht <GnZFd.31178$I24.2672738@phobos.telenet-ops.be>...

> > Ik besef dat ik het wiel opnieuw ga uitvinden, maar toch wil ik
> > een viewer maken in BASIC, die een grote (20 MB) tekstfile met
> > alleen carriage return, line feed en tab, moet weergeven. Hij
> > moet de stuurtoetsen gebruiken, en kunnen kiezen uit linewrap,
> > of juist uit het veld lopen.

> Het kan eigenlijk v��l eenvoudiger; alleen het openen duurt iets langer;
> maar: Win gebruikt swap file... dus... gaat nu v��l sneller dan 20 jaar 
> geleden!
> Ik lees dat je nogal bezig bent met pointers & co te onthouden...
> Echt niet nodig! Hoe dan wel?
> Lees eerst het bestand sekwentieel, met als enig doel de langste string te
> onthouden.
> Maak een nieuw bestand; het eigenlijke "leesbestand".
> Dit bestand is niet sekwentieel doch random access... met de inhoud
> van je "bronbestand". (breedt = lengte langste string "moederbestand"
> Als je weet hoeveel lijnen je binnen je "werkvenster" staan, wordt
> het een fluitje van een cent om de gegevens op je scherm te toveren,
> en scrollen, page up... home, end, etc etc... ook line wrap toepassen!!
> Voor echt grote bestanden moet je ook een extra page up & down
> voorzien; zo eentje die een % functie aantal lijnen scrolt... leuk extraatje
> (ja kan zelfs een lijntellertje etc onderaan op je scherm toveren...)
> Zelfd editeren wordt dan ook heel ��nvoudig...
> Extra voordeel: h��l weinig werkgeheugen
> (zoals in de oude tijd: 80 karakters, 25 lijnen; =  2000 bytes geheugen..
> probeer dat maar eens met Notepad! (20 MB kan ie toch niet..)
> 
> Ik weet zeker dat je het kan doen in minder dan 50 lijnen... QB4.5
> All�z, succes & prettig weekend!
> Hubert

Dank voor je uiteenzetting. Ja, is ook een aardige manier, vermits de
langste string niet te lang is, en dat kan natuurlijk best in een
"allerlei"-file. Ken je LIST.COM van Vernon D. Buerg? Die leest een
file van zo'n 16 MB in in een fractie van een seconde. Ga je dan
met "End" naar het einde, dan geef-ie keurig de laatste pagina,
ongeacht of hij met een halve lange (>80) string begint. En dat duurt
minder dan een seconde op een moderne PC. En als het allemaal heel
lange strings zijn, gaat-ie toch op de juiste beginpagina staan.
Kijk, zo zou ik het ook willen. De reden waaom ik het opnieuw wil
doen, is dat ik grotere files wil kunnen inlezen. Het lukt me ook
wel, maar het wordt al gauw traag (PageUp) of de weergave klopt niet,
Ook sequentieel inlezen gaat niet bij extreem lange strings. Toch
benieuwd hoe die Buerg dat geflikt heeft. Ook binaries geeft hij
behoorlijk weer, hoewel dat natuurlijk niet erg mooi is. Hexadecimaal
kan ook, maar dat is het punt natuurlijk niet.

Hartelijk dank, Bastiaan.

"Bastiaan" <bastiaan@niet.net> wrote in message
news:41f50ed3$0$281$4d4ebb8e@news.nl.uu.net...
> H,Schampheleer <hubert@haps.be> schreef in bericht
<GnZFd.31178$I24.2672738@phobos.telenet-ops.be>...
> Dank voor je uiteenzetting. Ja, is ook een aardige manier, vermits de
> langste string niet te lang is, en dat kan natuurlijk best in een
> "allerlei"-file. Ken je LIST.COM van Vernon D. Buerg? Die leest een
> file van zo'n 16 MB in in een fractie van een seconde.

Die leest echt die hele file niet in. Die leest maximaal 64kb van de file
(COM programma, datasegment + stack maximaal 64 kb.

> Ga je dan
> met "End" naar het einde, dan geef-ie keurig de laatste pagina,
> ongeacht of hij met een halve lange (>80) string begint. En dat duurt
> minder dan een seconde op een moderne PC. En als het allemaal heel
> lange strings zijn, gaat-ie toch op de juiste beginpagina staan.
> Kijk, zo zou ik het ook willen.

Pak een linux distro en bekijk de source van 'tail'.

> De reden waaom ik het opnieuw wil
> doen, is dat ik grotere files wil kunnen inlezen. Het lukt me ook
> wel, maar het wordt al gauw traag (PageUp) of de weergave klopt niet,
> Ook sequentieel inlezen gaat niet bij extreem lange strings. Toch
> benieuwd hoe die Buerg dat geflikt heeft.

Door de file als untyped file in te lezen, oftewel rauwe data in grote
blokken van bijvoorbeeld 32kb. En daarbinnen ga je naar strings zoeken.

Meindert

Toen ik Meindert Sprang kietelde, kwam er dit uit:

> [LIST.COM van Vernon D. Buerg]
> Die leest echt die hele file niet in. Die leest maximaal 64kb
> van de file (COM programma, datasegment + stack maximaal 64 kb.

Dat 'COM kan maximaal 64 kB' is niet zo:
http://www.faqs.org/faqs/assembly-language/x86/general/part3/section-2.html


> Door de file als untyped file in te lezen, oftewel rauwe data in grote
> blokken van bijvoorbeeld 32kb. En daarbinnen ga je naar strings
> zoeken.

Dat is meestal wel voldoende. Het is natuurlijk afhankelijk van je
'window'. Als je 25 regels van 80 lang hebt, en je geen ANSI-codes
o.i.d. ondersteunt, dan heb je al genoeg aan 2 kB. Mijn terminal-
windows zijn vaak 132x100, dus dat is minder dan 16 kB.

Zou je de file in een proportioneel font tonen, dan passen er
misschien wel 400 tekens zichtbaar op een regel (denk aan puntjes
of uitroeptekens) dus dan zit je tegen de 40 kB.

Probeer bijvoorbeeld eens met Wordpad hoe die zich houdt met dat soort
bestanden. Een 10 MB file (1024 regels van 1024 puntjes) duurt hier op
een PIII/900 zo'n zes seconden om te laden (de eerste keer, daarna
binnen twee seconden).

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

"Dr.Ruud" <rvtol+news@isolution.nl> wrote in message
news:ct3j0f.1d0.1@news.isolution.nl...
> Toen ik Meindert Sprang kietelde, kwam er dit uit:
>
> > [LIST.COM van Vernon D. Buerg]
> > Die leest echt die hele file niet in. Die leest maximaal 64kb
> > van de file (COM programma, datasegment + stack maximaal 64 kb.
>
> Dat 'COM kan maximaal 64 kB' is niet zo:
>
http://www.faqs.org/faqs/assembly-language/x86/general/part3/section-2.html

Klopt, maar dan moet je meer moeite doen en met segmenten gaan rommelen.
Waar ik op doelde is dat default en COM programma 64 kb code en 64kb
dataspace krijgt toegewezen.
Meindert

Meindert Sprang <mhsprang@NOcustomSPAMware.nl> schreef in bericht <10valcrcncfhm8a@corp.supernews.com>...

> "Dr.Ruud" <rvtol+news@isolution.nl> wrote in message
> news:ct3j0f.1d0.1@news.isolution.nl...
> > Toen ik Meindert Sprang kietelde, kwam er dit uit:
> >
> > > [LIST.COM van Vernon D. Buerg]
> > > Die leest echt die hele file niet in. Die leest maximaal 64kb
> > > van de file (COM programma, datasegment + stack maximaal 64 kb.
> >
> > Dat 'COM kan maximaal 64 kB' is niet zo:
> >
> http://www.faqs.org/faqs/assembly-language/x86/general/part3/section-2.html
> 
> Klopt, maar dan moet je meer moeite doen en met segmenten gaan rommelen.
> Waar ik op doelde is dat default en COM programma 64 kb code en 64kb
> dataspace krijgt toegewezen.

Ik geloof zelfs dat codesegment en datasegment dezelfde zijn.

Nog eens over LIST.COM: Ik heb een file gemaakt met willekeurige data
maar zonder stuurtekens. 16 MB groot. Wrap aan. Als ik nu op End druk
is hij daar binnen de seconde. De plaats waar de regels beginnen,
staat dan al vast, en bij het terugscrollen naar het begin blijkt dat
ook te kloppen. Extra onberijpelijk is dat er wel tabs in zitten, die
expanded worden weergegeven. Dat hij die hele file leest in < 1 sec.
kan er bij mij niet in, maar toch weet hij waar de regels beginnen en
klopt dat t.o.v. het begin. M�t tabs. Rara.

Hartelijk dank, Bastiaan.

Toen ik Bastiaan kietelde, kwam er dit uit:
> Meindert Sprang:
>> Dr.Ruud:
>>> Meindert Sprang:

>>>> [LIST.COM van Vernon D. Buerg]
>>>> Die leest echt die hele file niet in. Die leest maximaal 64kb
>>>> van de file (COM programma, datasegment + stack maximaal 64 kb.

>>> Dat 'COM kan maximaal 64 kB' is niet zo:
>>>
http://www.faqs.org/faqs/assembly-language/x86/general/part3/section-2.html

>> Klopt, maar dan moet je meer moeite doen en met segmenten gaan
>> rommelen. Waar ik op doelde is dat default en COM programma 64 kb
>> code en 64kb dataspace krijgt toegewezen.

> Ik geloof zelfs dat codesegment en datasegment dezelfde zijn.

Ahum, sinds wanneer zijn DS (en ES en etc.) Read-Only?


> Nog eens over LIST.COM: Ik heb een file gemaakt met willekeurige data
> maar zonder stuurtekens. 16 MB groot. Wrap aan. Als ik nu op End druk
> is hij daar binnen de seconde. De plaats waar de regels beginnen,
> staat dan al vast, en bij het terugscrollen naar het begin blijkt dat
> ook te kloppen. Extra onberijpelijk is dat er wel tabs in zitten, die
> expanded worden weergegeven. Dat hij die hele file leest in < 1 sec.
> kan er bij mij niet in, maar toch weet hij waar de regels beginnen en
> klopt dat t.o.v. het begin. M�t tabs. Rara.

A. Je weet hoe groot de file is.
B. Je weet hoeveel tekens je maximaal tegelijk op het scherm gaat
zetten.

1. Lees uit het einde van de file een blok in met minimaal die grootte.
2. Loop door dat blok en verzamel de offsets van de tekstregels (en als
dat een rol speelt: het aantal schermregels dat die tekstregel nodig
heeft)
3. etc.

Je schrijft: "Dat hij die hele file leest in < 1 sec. kan er bij mij
niet
in" maar dat gebeurt dan ook helemaal niet, want waarom zou hij?

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

"Bastiaan" <bastiaan@niet.net> wrote in message
news:41f57c8b$0$14124$4d4ebb8e@news.nl.uu.net...
> Meindert Sprang <mhsprang@NOcustomSPAMware.nl> schreef in bericht > >
Klopt, maar dan moet je meer moeite doen en met segmenten gaan rommelen.
> > Waar ik op doelde is dat default en COM programma 64 kb code en 64kb
> > dataspace krijgt toegewezen.
>
> Ik geloof zelfs dat codesegment en datasegment dezelfde zijn.

Inderdaad, dat schiet me nu ook weer te binnen.

> Nog eens over LIST.COM: Ik heb een file gemaakt met willekeurige data
> maar zonder stuurtekens. 16 MB groot. Wrap aan. Als ik nu op End druk
> is hij daar binnen de seconde. De plaats waar de regels beginnen,
> staat dan al vast, en bij het terugscrollen naar het begin blijkt dat
> ook te kloppen. Extra onberijpelijk is dat er wel tabs in zitten, die
> expanded worden weergegeven. Dat hij die hele file leest in < 1 sec.
> kan er bij mij niet in

Dat doet 'ie ook niet, zoals ik al eerder uitlegde.  De filepointer wordt
met een DOS call verplaatst naar Filesize - [blokgrootte], dat blok wordt
ingelezen en daarbinnen worden de CR/LF's gezocht en de regels bepaald.

Meindert

"Dr.Ruud" <rvtol+news@isolution.nl> wrote in message
news:ct53al.1b8.1@news.isolution.nl...
> Toen ik Bastiaan kietelde, kwam er dit uit:
> > Ik geloof zelfs dat codesegment en datasegment dezelfde zijn.
>
> Ahum, sinds wanneer zijn DS (en ES en etc.) Read-Only?

??? Dat heeft niemand beweerd. Maar wanneer een .COM programma wordt
gestart, is CS=DS=ES=SS en allemaal R/W. Het concept van een CS met RO
attribuut bestaat niet onder DOS.

Meindert

Dr.Ruud <rvtol+news@isolution.nl> schreef in bericht <ct53al.1b8.1@news.isolution.nl>...

> Toen ik Bastiaan kietelde, kwam er dit uit:
> > Meindert Sprang:
> >> Dr.Ruud:
> >>> Meindert Sprang:
> 
> >>>> [LIST.COM van Vernon D. Buerg]
> >>>> Die leest echt die hele file niet in. Die leest maximaal 64kb
> >>>> van de file (COM programma, datasegment + stack maximaal 64 kb.
> 
> >>> Dat 'COM kan maximaal 64 kB' is niet zo:
> >>>
> http://www.faqs.org/faqs/assembly-language/x86/general/part3/section-2.html
> 
> >> Klopt, maar dan moet je meer moeite doen en met segmenten gaan
> >> rommelen. Waar ik op doelde is dat default en COM programma 64 kb
> >> code en 64kb dataspace krijgt toegewezen.
> 
> > Ik geloof zelfs dat codesegment en datasegment dezelfde zijn.
> 
> Ahum, sinds wanneer zijn DS (en ES en etc.) Read-Only?

Wie heeft het daar over?

> 
> > Nog eens over LIST.COM: Ik heb een file gemaakt met willekeurige data
> > maar zonder stuurtekens. 16 MB groot. Wrap aan. Als ik nu op End druk
> > is hij daar binnen de seconde. De plaats waar de regels beginnen,
> > staat dan al vast, en bij het terugscrollen naar het begin blijkt dat
> > ook te kloppen. Extra onberijpelijk is dat er wel tabs in zitten, die
> > expanded worden weergegeven. Dat hij die hele file leest in < 1 sec.
> > kan er bij mij niet in, maar toch weet hij waar de regels beginnen en
> > klopt dat t.o.v. het begin. M�t tabs. Rara.
> 
> A. Je weet hoe groot de file is.
> B. Je weet hoeveel tekens je maximaal tegelijk op het scherm gaat
> zetten.
> 
> 1. Lees uit het einde van de file een blok in met minimaal die grootte.
> 2. Loop door dat blok en verzamel de offsets van de tekstregels (en als
> dat een rol speelt: het aantal schermregels dat die tekstregel nodig
> heeft)
> 3. etc.
> 
> Je schrijft: "Dat hij die hele file leest in < 1 sec. kan er bij mij
> niet
> in" maar dat gebeurt dan ook helemaal niet, want waarom zou hij?

Wat je precies bedoelt met 'verzamel de offsets'. Maar ik zal mijn
voorbeeld verfijnen: Je hebt een file met tekst van zeg 16MB groot,
waar geen stuurtekens zoals CR LF enzo in zitten, maar w�l tabs. Dan is
het begin van de laatste regel puur afhankelijk van het aantal tabs wat
er in de file zitten, en die moeten ook gelezen worden om de positie
van die laatste regel te bepalen. Nou, LIST doet dat zonder mankeren,
ook al is die file 16 MB. D�t is nou juist zo frappant.

Dit antwoord is ook aan Meindert. Als er nou ergens in het begin van
de file ergens een letter in een tab verandert, verandert meestal de
positie van het begin de regels na die tab ook. En als je na het
openen van de 16 MB file (kost geen tijd) op End drukt, duurt het nog
geen seconde en de laatste pagina (waarvan de positie bepaald wordt
door de tabs overal in de file) staat op de juiste positie in beeld.
Ga je dan met PijlOmhoog terug naar het begin, dan zie je dat het
precies uitkomt. Rara....

Oh ja, ik heb het over de gewrapte weergave. Dus zeg maar 80 breed.


Hartelijk dank, Bastiaan.

"Bastiaan" <bastiaan@niet.net> wrote in message
news:41f68928$0$14113$4d4ebb8e@news.nl.uu.net...
> Wat je precies bedoelt met 'verzamel de offsets'. Maar ik zal mijn
> voorbeeld verfijnen: Je hebt een file met tekst van zeg 16MB groot,
> waar geen stuurtekens zoals CR LF enzo in zitten, maar w�l tabs. Dan is
> het begin van de laatste regel puur afhankelijk van het aantal tabs wat
> er in de file zitten, en die moeten ook gelezen worden om de positie
> van die laatste regel te bepalen. Nou, LIST doet dat zonder mankeren,
> ook al is die file 16 MB. D�t is nou juist zo frappant.

Ehh, als er geen CR/LF's in de file zitten, wat bepaalt dan een regel?

> Dit antwoord is ook aan Meindert. Als er nou ergens in het begin van
> de file ergens een letter in een tab verandert, verandert meestal de
> positie van het begin de regels na die tab ook. En als je na het
> openen van de 16 MB file (kost geen tijd) op End drukt, duurt het nog
> geen seconde en de laatste pagina (waarvan de positie bepaald wordt
> door de tabs overal in de file) staat op de juiste positie in beeld.
> Ga je dan met PijlOmhoog terug naar het begin, dan zie je dat het
> precies uitkomt. Rara....

Eigenlijk wordt het daar alleen maar gemakkelijker van. Iedere tab om de 8
positities dus voor 25 regels hoef je alleen maar 250 tabs terug te tellen
en van daar af naar het scherm schrijven.

Meindert

Meindert Sprang <mhsprang@NOcustomSPAMware.nl> schreef in bericht <10vd3kfqrk9jv43@corp.supernews.com>...

> "Bastiaan" <bastiaan@niet.net> wrote in message
> news:41f68928$0$14113$4d4ebb8e@news.nl.uu.net...
> > Wat je precies bedoelt met 'verzamel de offsets'. Maar ik zal mijn
> > voorbeeld verfijnen: Je hebt een file met tekst van zeg 16MB groot,
> > waar geen stuurtekens zoals CR LF enzo in zitten, maar w�l tabs. Dan is
> > het begin van de laatste regel puur afhankelijk van het aantal tabs wat
> > er in de file zitten, en die moeten ook gelezen worden om de positie
> > van die laatste regel te bepalen. Nou, LIST doet dat zonder mankeren,
> > ook al is die file 16 MB. D�t is nou juist zo frappant.
> 
> Ehh, als er geen CR/LF's in de file zitten, wat bepaalt dan een regel?

Omdat wrap aanstaat de zichtbare breedte, dus 80 tekens. Als wrap uit staat
hanteert-ie een maximale breedte van 2048. Net jes toch?

> 
> > Dit antwoord is ook aan Meindert. Als er nou ergens in het begin van
> > de file ergens een letter in een tab verandert, verandert meestal de
> > positie van het begin de regels na die tab ook. En als je na het
> > openen van de 16 MB file (kost geen tijd) op End drukt, duurt het nog
> > geen seconde en de laatste pagina (waarvan de positie bepaald wordt
> > door de tabs overal in de file) staat op de juiste positie in beeld.
> > Ga je dan met PijlOmhoog terug naar het begin, dan zie je dat het
> > precies uitkomt. Rara....
> 
> Eigenlijk wordt het daar alleen maar gemakkelijker van. Iedere tab om de 8
> positities dus voor 25 regels hoef je alleen maar 250 tabs terug te tellen
> en van daar af naar het scherm schrijven.

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.


Hartelijk dank, Bastiaan.

Toen ik Bastiaan kietelde, kwam er dit uit:

> 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)

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

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

> Toen ik Bastiaan kietelde, kwam er dit uit:
> 
> > 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. De positie van zeg maar het laatste teken is
afhankelijk van de filegrootte �n �lle tabs (�n hun positie) in
de hele file. Als er nog meer stuurtekens bijkomen, be�nvloeden
die het ook weer. CR/LF's zijn makkelijk, de positie hierna begint
altijd op de 1e plaats. Maar het gaat mij erom hoe het mogelijk
is. Vernon kan het, maar hoe? Ook als wrap uit staat (de weergave
heeft dan een breedte van 2048) is hij razendsnel. Ik weet nog wel
een manier: zelf een filebuffer beheren. Maar dan nog, 16 MB in
minder dan 1 seconde...


Hartelijk dank, Bastiaan.

"Bastiaan" <bastiaan@niet.net> wrote in message
news:41f7d857$0$274$4d4ebb8e@news.nl.uu.net...
> altijd op de 1e plaats. Maar het gaat mij erom hoe het mogelijk
> is. Vernon kan het, maar hoe? Ook als wrap uit staat (de weergave
> heeft dan een breedte van 2048) is hij razendsnel. Ik weet nog wel
> een manier: zelf een filebuffer beheren. Maar dan nog, 16 MB in
> minder dan 1 seconde...
>

Volgens mij heb je nu tig suggesties gehad hoe het kan en nog steeds begrijp
je het niet. Of wij begrijpen het niet. Hoe ziet in godsnaam die tekstfile
van jou eruit? Je praat over tabs maar zegt dat er geen CR/LF's in zitten.
Hoe weet je dan waar een regel begint en of Vernon die file wel goed
weergeeft? Toeval? Zijn de items die gescheiden zijn door de tabs korter dan
een tabstop? Van mij mag je die file eens mailen; m'n email adres staat in
de header en m'n mailserver kan het aan.

Meindet

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.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Meindert Sprang <mhsprang@NOcustomSPAMware.nl> schreef in bericht <10vfpp37s1nr9a0@corp.supernews.com>...

> "Bastiaan" <bastiaan@niet.net> wrote in message
> news:41f7d857$0$274$4d4ebb8e@news.nl.uu.net...
> > altijd op de 1e plaats. Maar het gaat mij erom hoe het mogelijk
> > is. Vernon kan het, maar hoe? Ook als wrap uit staat (de weergave
> > heeft dan een breedte van 2048) is hij razendsnel. Ik weet nog wel
> > een manier: zelf een filebuffer beheren. Maar dan nog, 16 MB in
> > minder dan 1 seconde...
> >
> 
> Volgens mij heb je nu tig suggesties gehad hoe het kan en nog steeds begrijp
> je het niet. Of wij begrijpen het niet. Hoe ziet in godsnaam die tekstfile
> van jou eruit? Je praat over tabs maar zegt dat er geen CR/LF's in zitten.
> Hoe weet je dan waar een regel begint en of Vernon die file wel goed
> weergeeft? Toeval? Zijn de items die gescheiden zijn door de tabs korter dan
> een tabstop? Van mij mag je die file eens mailen; m'n email adres staat in
> de header en m'n mailserver kan het aan.
> 
> Meindet

De suggesties klopten niet, helaas. Ik begrijp het prima, het enige
wat ik niet begrijp is hoe Vernon 16 MB in kan lezen in < 1 sec. Of
er moet een andere manier zijn om het begin van de laatste page uit
te rekenen als er geen CR/LF zijn, maar wel tabs. Die is er niet,
dus zou ik met een *eigen* filebuffer (dus niet via BASIC) moeten
gaan werken om snelheid te halen. Want 16 MB lezen van disk k�n wel
snel. Ik weet nog niet hoe ik het moet versieren, maar daar kom ik
wel uit.
Die testfile zonder CR/LF en m�t tabs is een zelfgemaakte file, om
te kijken hoe LIST.COM daarmee omging. Als ik die dus open, en ik
druk op End, istie binnen 1 sec op het eind, en begint met het
juiste karakter. Blader ik n.l. terug naar 1, dan blijkt dat begin
precies uit te komen. Daardoor weet ik zo zeker dat het klopt, en
dat hij dus de hele file leest wanneer ik End doe.

Hartelijk dank, Bastiaan.

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.

Toen ik Bastiaan kietelde, kwam er dit uit:

> [End]
> Als
> de file 16.000.010 bytes is, zou je laatste page 10 bytes groot
> kunnen zijn.

Aha, bedoel je het zo. Als *ik* op End druk, dan verwacht ik een
zo vol mogelijk scherm, en de cursor onderaan. (Behalve als de
Scroll-Lock aan staat, dan wil ik dat de cursor op dezelfde
schermpositie blijft, en pas met de volgende End naar onderaan
gaat.)

Ik zal zo eens testen met LIST of hij het werkelijk zo doet als jij
je voorstelt. Misschien is je testbestand gewoon te voorspelbaar. <g>

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

"Bastiaan" <bastiaan@niet.net> wrote in message
news:41f92f63$0$14119$4d4ebb8e@news.nl.uu.net...
> Meindert Sprang <mhsprang@NOcustomSPAMware.nl> schreef in bericht
<10vfpp37s1nr9a0@corp.supernews.com>...
> De suggesties klopten niet, helaas. Ik begrijp het prima, het enige
> wat ik niet begrijp is hoe Vernon 16 MB in kan lezen in < 1 sec.

Nou nog ��n keer dan: HIJ LEEST DIE HELE FILE NIET IN!!!!!!!
Hij verplaatst de filepointer naar (filelength - blocksize) en leest dat
blok in. En dat blok is maar een paar Kb.

Meindert

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

> Toen ik Bastiaan kietelde, kwam er dit uit:
> 
> > [End]
> > Als
> > de file 16.000.010 bytes is, zou je laatste page 10 bytes groot
> > kunnen zijn.
> 
> Aha, bedoel je het zo. Als *ik* op End druk, dan verwacht ik een
> zo vol mogelijk scherm, en de cursor onderaan. (Behalve als de
> Scroll-Lock aan staat, dan wil ik dat de cursor op dezelfde
> schermpositie blijft, en pas met de volgende End naar onderaan
> gaat.)

Natuurlijk staat er meer op je scherm, maar het gaat om de positie
van die laatste regel. Die is als er tenminste geen tabs e.d. zijn,
10 tekens lang. Het gaat om de positie van elke regel natuurlijk,
maar de rest is natuurlijk 80 karakters lang. Steeds weer, tot aan
de eerste regel aan toe. Klopt precies, inclusief expanded tabs. D�t
is nou juist het knappe!

> 
> Ik zal zo eens testen met LIST of hij het werkelijk zo doet als jij
> je voorstelt. Misschien is je testbestand gewoon te voorspelbaar. <g>

LIST doet werkelijk zoals ik voorstel, en ik heb geen voorspelbare
testfile. Ik heb al veel soorten testfiles geprobeerd, en weet echt
wel wat ik doe. Maak maar een file van 16 MB met random waarden,
echter zonder 13, 10, 8, 7 maar dus wel met 9. Je zult zien dat
LIST razendsnel de file leest en op de laatste page de juiste
positie neemt t.o.v. het begin der file. Hij heeft dan alle tabs
voor de weergave expanded.


Hartelijk dank, Bastiaan.

Toen ik Bastiaan kietelde, kwam er dit uit:

> Natuurlijk staat er meer op je scherm, maar het gaat om de positie
> van die laatste regel. Die is als er tenminste geen tabs e.d. zijn,
> 10 tekens lang. Het gaat om de positie van elke regel natuurlijk,
> maar de rest is natuurlijk 80 karakters lang. Steeds weer, tot aan
> de eerste regel aan toe. Klopt precies, inclusief expanded tabs. D�t
> is nou juist het knappe!

Als je het nu weer zo opschrijft, begin ik opnieuw te twijfelen aan wat
je je voorstelt.

1. Om (de laatste regel(s) op) het laatste scherm correct weer te geven,
hoef je *niet* de hele file in te lezen.

2. Behalve als je als extra eis stelt, dat alle informatie boven het
laatste scherm precies op een geheel aantal (dat flink groter dan 0 is)
schermen past.

Maar eis 2 is er eentje die je in de praktijk nooit voor zo'n
file-lister
zult hanteren.

Denk aan de herpaginering van een tekstverwerker, die doet er altijd een
tijdje over, en dat is logisch.

Heb je in die random-waarden toevallig ook FFs (ASCII-12) staan? Want
die kan LIST gebruiken als pagina-grenzen. Als je 7 en 8 overslaat,
waarom dan 11 (Vertical Tab) niet? Alles van 7-13 kan de cursor-positie
be�nvloeden. Of doet LIST daar niets mee?

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

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

> Als je het nu weer zo opschrijft, begin ik opnieuw te twijfelen aan wat
> je je voorstelt.
> 
> 1. Om (de laatste regel(s) op) het laatste scherm correct weer te geven,
> hoef je *niet* de hele file in te lezen.

Ja, dat moet wel in geval van de testfile, omdat je anders niet weet op
welke positie je moet beginnen. Dat komt door die tabs, want anders was
het gewoon te berekenen. Dus als je de laatste 1930 tekens laat zien,
verandert dat weer als er ergens ervoor een tab staat, b.v. in de laatste
1937. Het gaat dus om de breedtepositie, met welk teken begin je, om te
zorgen dat als je teruggaat met PijlUp, je precies uitkomt. Ik heb dat
getest en het klopt precies.

> 
> 2. Behalve als je als extra eis stelt, dat alle informatie boven het
> laatste scherm precies op een geheel aantal (dat flink groter dan 0 is)
> schermen past.

De hoogtepostie is niet van belang en is eenvoudig in te stellen.

> 
> Maar eis 2 is er eentje die je in de praktijk nooit voor zo'n
> file-lister
> zult hanteren.
> 
> Denk aan de herpaginering van een tekstverwerker, die doet er altijd een
> tijdje over, en dat is logisch.

Natuurlijk. Het enige wat je nodig hebt is een snelle filebuffer.

> 
> Heb je in die random-waarden toevallig ook FFs (ASCII-12) staan? Want
> die kan LIST gebruiken als pagina-grenzen. Als je 7 en 8 overslaat,
> waarom dan 11 (Vertical Tab) niet? Alles van 7-13 kan de cursor-positie
> be�nvloeden. Of doet LIST daar niets mee?

Nee, daar doet-ie niks mee. Het gaat erom dat er karakters zijn die
iets met de indeling doen, en die worden in de berekening naar 'End'
meegenomen. Bij tab is dit duidelijk, vandaar dat ik die als voorbeeld
nam.

Nu ik toch weer aan 't schrijven ben, nog maar eens het voorbeeld.
Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010
bytes groot. Open hem met LIST en druk op End. Nu laat-ie 22 hele regels
zien, en 1 regel van 10. Stel nu dat het 1e teken in die file een tab
is, en je doet hetzelfde. Dan laat list weer 22 hele regels zien, maar
nu 1 regel van 17. Hiervoor moet hij dan wel weten dat er een tab is,
en ook op welke positie die staat in de modulus van 8. Dus moet hij
wel de hele file lezen, anders kan hij die positie van de laatste
regels(s) niet berekenen. (Wis het zweet van mijn voorhoofd :-))

En zeg nu alsjeblieft niet: Die 1e byte kun je toch even checken, want
ik bedoel natuurlijk dat er overal door heel de file heen tabs kunnen
staan. Daarom weet ik zeker dat LIST de hele file leest. En dat in
minder dan 1 seconde, dat vind ik mooi en zou ik ook wel willen. Maar
in BASIC kan ik dat wel vergeten, daarom ga ik speuren naar een andere
methode. Ik weet al geen snelle manier om een sector in te lezen in
BASIC.


Hartelijk dank, Bastiaan.

Bastiaan wrote:

> 
>>Heb je in die random-waarden toevallig ook FFs (ASCII-12) staan? Want
>>die kan LIST gebruiken als pagina-grenzen. Als je 7 en 8 overslaat,
>>waarom dan 11 (Vertical Tab) niet? Alles van 7-13 kan de cursor-positie
>>be�nvloeden. Of doet LIST daar niets mee?
> 
> 
> Nee, daar doet-ie niks mee. Het gaat erom dat er karakters zijn die
> iets met de indeling doen, en die worden in de berekening naar 'End'
> meegenomen. Bij tab is dit duidelijk, vandaar dat ik die als voorbeeld
> nam.
> 
> Nu ik toch weer aan 't schrijven ben, nog maar eens het voorbeeld.
> Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010

31 decimaal ? Spatie en daarboven, dus.
Maar TAB is ^I is 9, dus waar haal je dan die tabs vandaan ?
[ ik vraag me zowiezo af waarom je betekenis hecht aan TAB, als CR/LF 
geen betekenis schijnen te hebben. ]

vwb die 16 miljoen bytes: daar kan je in principe wel doorheen fietsen,
in 1 sec : dan mag je pak em beet 100 clocks / char besteden.
Voor een suf loopje wat alleen maar CR/LF's regelnummers bijhoudt is dat 
te doen, lijkt mij. Alleen maar TABS nalopen ook wel, dus.

Dat werkt alleen als alles al klaar staat in buffers, anders moet je
bij iedere blockgrens wachten op een diskread. [ Dat is het verschil 
tussen de 1e keer en de 2e keer uitvoeren evt kan je die in een aparte 
thread oid doen]

Maar dit is allemaal al gezegd.

AvK

Toen ik Bastiaan kietelde, kwam er dit uit:

> Daarom weet ik zeker dat LIST de hele file leest. En dat in
> minder dan 1 seconde, dat vind ik mooi en zou ik ook wel willen.

De tweede keer dat je dezelfde file benadert, staat hij waarschijnlijk
nog geheel in de cache. Probeer maar eens met een file die net
gegenereerd is, of je verschil opmerkt tussen de eerste LIST en de
tweede.


> Maar
> in BASIC kan ik dat wel vergeten, daarom ga ik speuren naar een andere
> methode. Ik weet al geen snelle manier om een sector in te lezen in
> BASIC.

Je kunt in VB gebruik maken van de WinAPI.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

"Dr.Ruud" <rvtol+news@isolution.nl> wrote in message
news:ctdn3a.4ls.1@news.isolution.nl...
> Toen ik Bastiaan kietelde, kwam er dit uit:
>
> > Daarom weet ik zeker dat LIST de hele file leest. En dat in
> > minder dan 1 seconde, dat vind ik mooi en zou ik ook wel willen.
>
> De tweede keer dat je dezelfde file benadert, staat hij waarschijnlijk
> nog geheel in de cache. Probeer maar eens met een file die net
> gegenereerd is,

En die dus ook in de cache staat. Oftewel: file genereren, reboot, file
lezen.

Meindert

Toen ik Bastiaan kietelde, kwam er dit uit:

> Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010
> bytes groot. Open hem met LIST en druk op End. Nu laat-ie 22 hele
> regels zien, en 1 regel van 10.

Ik neem dus aan dat je dan (maximaal) 23 dataregels van 80 tekens op je
scherm hebt. (Je kunt LIST ook anders instellen.)
En waarschijnlijk zijn regel 1 en 25 bezet met meta- en hulp-informatie.


> Stel nu dat het 1e teken in die file een tab
> is, en je doet hetzelfde. Dan laat list weer 22 hele regels zien, maar
> nu 1 regel van 17. Hiervoor moet hij dan wel weten dat er een tab is,
> en ook op welke positie die staat in de modulus van 8. Dus moet hij
> wel de hele file lezen

Ben ik (eindelijk) met je eens. Dit hoeft overigens ook puur in VB niet
lang te duren, gebruik bijvoorbeeld zoiets:

Function do_File(fName As String)

  Const C_LINESIZE = 80
  Const C_TABSIZE = 8
  Const C_BUFFERSIZE = 131072    ' if < 32768, append an & (like 16384&)

  Dim fInput As Integer
  Dim fLen As Long

  Dim fBuffer(1 To C_BUFFERSIZE) As Byte

  Dim fRec As Long
  Dim fRecs As Long
  Dim fOffset As Long

  Dim timer0 As Double

  Dim i As Long
  Dim iMax As Long
  Dim iPos As Integer

  Debug.Print "----------------------"

  timer0 = Timer
  Debug.Print "Start:", Time()

  fInput = FreeFile(0)
  Open fName For Binary Access Read As fInput
  fLen = LOF(fInput)
  Debug.Print "Size of file:", fLen

  fRecs = (fLen + C_BUFFERSIZE - 1) \ C_BUFFERSIZE
  Debug.Print "Nr. of records:", fRecs
  Debug.Print "Nr. of full records:", (fLen \ C_BUFFERSIZE), _
              "( * "; C_BUFFERSIZE; " = "; _
              (fLen \ C_BUFFERSIZE) * C_BUFFERSIZE; ")"

  fOffset = 1
  iPos = 1

  For fRec = 1 To fRecs
    Get #1, fOffset, fBuffer

    iMax = fLen - fOffset + 1
    If iMax > C_BUFFERSIZE Then
      iMax = C_BUFFERSIZE
    End If

    For i = 1 To iMax

      Select Case fBuffer(i)
        Case 9   ' HT
          iPos = iPos + 8 - (iPos Mod C_TABSIZE)
        Case 10  ' LF
          'no horizontal move
        Case 11  ' VT
          'no horizontal move
        Case 12  ' FF
           iPos = 1
        Case 13  ' CR
           iPos = 1
        Case Else
          iPos = iPos + 1
      End Select

      If iPos > C_LINESIZE Then
        iPos = 1
      End If

    Next i

#If 0 Then
    Debug.Print iPos,
    If 0 = (fRec Mod 8) Then Debug.Print
#End If

    fOffset = fOffset + iMax
  Next fRec

  Debug.Print
  Debug.Print "Last position:", iPos
  Debug.Print "End:", Time(), "= "; Round(Timer - timer0, 2); " seconds"
  Debug.Print

  Close fInput

End Function


Die doet er in mijn VBA minder dan een seconde per MB over, dus dat zal
in (gecompileerde) VB wel wat sneller gaan.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Bastiaan wrote:

> 
> Nu ik toch weer aan 't schrijven ben, nog maar eens het voorbeeld.
> Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010

Nou, bastiaan, ik heb het even geprobeerd (het is toch weekeind)
En mn schatting was veel te voorzichtig. 16 MB scannen in 1sec kan 
*zat*! (als je niet te veel doet) Ik wist niet eens dat die HD I/O van 
mij meer dan 10 MB/sec aankon. kennelijk wel dus.

Ik had wat moeite om een geschikte file van geschikte grootte te vinden,
en uiteindelijk is het een fontfile geworden. Het is onwaarschijnlijk
dat de file in memory gebufferd zat. Hij is 14M groot, dus gooi er nog 
15% bovenop) er zitten ca 250K regels in / 14 M, dat is dus ca 55 
tekens/regel. Ik weet niet hoeveel tabs er in die niet-text file van jou 
zitten.

Ik was te lui om tabs te tellen, dus ik heb alleen LF geteld, en offsets 
in een array bewaard.
Kwa komplexiteit maakt dat niet uit. (gooi er een factor 2 tegenaan, dan 
zit ik nog onder de seconde)
Ik heb hem twee keer gedaan; je kan zien dat ie de tweede keer voordeel 
heeft van disk-buffering, en dat de rest vd tijden nauwelijks verschillen.

Methode is mmap() + met for-loopje door char[] array fietsen.
Dat kan uiteraard alleen op unix, maar het geeft wel aan wat haalbaar 
is. Je zult met VB waarschijnlijk wel onder de 3 sec kunnen komen.

Komtie:

[lutser@klutser dirretje]$ ls -l /usr/share/fonts/ko/TrueType/batang.ttf
-rw-r--r--  1 root root 13939436 Feb 15  2004 
/usr/share/fonts/ko/TrueType/batang.ttf
 

[lutser@klutser dirretje]$ time ./a.out 
/usr/share/fonts/ko/TrueType/batang.ttf
Ptr = 0xf0593000, Sz = 13939436
Lines = 237160 / 262144
 

real    0m0.533s
user    0m0.209s
sys     0m0.023s
 

[lutser@klutser dirretje]$ ls -l /usr/share/fonts/ko/TrueType/batang.ttf
-rw-r--r--  1 root root 13939436 Feb 15  2004 
/usr/share/fonts/ko/TrueType/batang.ttf
 

[lutser@klutser dirretje]$ time ./a.out 
/usr/share/fonts/ko/TrueType/batang.ttf
Ptr = 0xf061f000, Sz = 13939436
Lines = 237160 / 262144
 

real    0m0.217s
user    0m0.205s
sys     0m0.012s


Nou jongen, laat je dus niet ontmoedigen.
Doe je best, het kan!
nou jij!

Succes,
AvK

Toen ik Meindert Sprang kietelde, kwam er dit uit:
> Dr.Ruud:
>> Bastiaan:

>>> Daarom weet ik zeker dat LIST de hele file leest. En dat in
>>> minder dan 1 seconde, dat vind ik mooi en zou ik ook wel willen.

>> De tweede keer dat je dezelfde file benadert, staat hij
>> waarschijnlijk nog geheel in de cache. Probeer maar eens met een
>> file die net gegenereerd is,

> En die dus ook in de cache staat. Oftewel: file genereren, reboot,
> file lezen.

Rebooten gaat wel erg ver. Als de gegenereerde file een write-only
file is, hoeft hij niet in de cache te staan. Lees anders even een
paar andere grote files in, of zoek een mooiere manier om de file uit
de cache te krijgen.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

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

> Toen ik Bastiaan kietelde, kwam er dit uit:
> 
> > Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010
> > bytes groot. Open hem met LIST en druk op End. Nu laat-ie 22 hele
> > regels zien, en 1 regel van 10.
> 
> Ik neem dus aan dat je dan (maximaal) 23 dataregels van 80 tekens op je
> scherm hebt. (Je kunt LIST ook anders instellen.)
> En waarschijnlijk zijn regel 1 en 25 bezet met meta- en hulp-informatie.
> 
> 
> > Stel nu dat het 1e teken in die file een tab
> > is, en je doet hetzelfde. Dan laat list weer 22 hele regels zien, maar
> > nu 1 regel van 17. Hiervoor moet hij dan wel weten dat er een tab is,
> > en ook op welke positie die staat in de modulus van 8. Dus moet hij
> > wel de hele file lezen
> 
> Ben ik (eindelijk) met je eens. Dit hoeft overigens ook puur in VB niet
> lang te duren, gebruik bijvoorbeeld zoiets:

<code geknipt>

Snik, het is gelukt. :-). Al schrijvende hier ben ik er ook van overtuigd
geraakt dat hij alles inleest en checkt. Het gebeurt in machinetaal en dat
is natuurlijk erg snel. Ik bewaar de code, ziet er goed uit, dank je.

> Die doet er in mijn VBA minder dan een seconde per MB over, dus dat zal
> in (gecompileerde) VB wel wat sneller gaan.

Nu ben ik alweer een heel stuk verder, maar natuurlijk moet het programma
het ook goed doen met CR/LF en andere stuurtekens. Ik houd LIST wel als
voorbeeld aan, die bevalt me wel.


Hartelijk dank, Bastiaan.

moi <avk@localhost> schreef in bericht <eqadnVqdj4H9GmfcRVnyug@casema.nl>...

> Bastiaan wrote:
> 
> > 
> > Nu ik toch weer aan 't schrijven ben, nog maar eens het voorbeeld.
> > Je hebt een file met louter ASCII tekens boven de 31, van 16.000.010
> 
> Nou, bastiaan, ik heb het even geprobeerd (het is toch weekeind)
> En mn schatting was veel te voorzichtig. 16 MB scannen in 1sec kan 
> *zat*! (als je niet te veel doet) Ik wist niet eens dat die HD I/O van 
> mij meer dan 10 MB/sec aankon. kennelijk wel dus.
> 
> Ik had wat moeite om een geschikte file van geschikte grootte te vinden,
> en uiteindelijk is het een fontfile geworden. Het is onwaarschijnlijk
> dat de file in memory gebufferd zat. Hij is 14M groot, dus gooi er nog 
> 15% bovenop) er zitten ca 250K regels in / 14 M, dat is dus ca 55 
> tekens/regel. Ik weet niet hoeveel tabs er in die niet-text file van jou 
> zitten.
> 
> Ik was te lui om tabs te tellen, dus ik heb alleen LF geteld, en offsets 
> in een array bewaard.
> Kwa komplexiteit maakt dat niet uit. (gooi er een factor 2 tegenaan, dan 
> zit ik nog onder de seconde)
> Ik heb hem twee keer gedaan; je kan zien dat ie de tweede keer voordeel 
> heeft van disk-buffering, en dat de rest vd tijden nauwelijks verschillen.
> 
> Methode is mmap() + met for-loopje door char[] array fietsen.
> Dat kan uiteraard alleen op unix, maar het geeft wel aan wat haalbaar 
> is. Je zult met VB waarschijnlijk wel onder de 3 sec kunnen komen.
> 
> Komtie:
> 
> [lutser@klutser dirretje]$ ls -l /usr/share/fonts/ko/TrueType/batang.ttf
> -rw-r--r--  1 root root 13939436 Feb 15  2004 
> /usr/share/fonts/ko/TrueType/batang.ttf
>  
> 
> [lutser@klutser dirretje]$ time ./a.out 
> /usr/share/fonts/ko/TrueType/batang.ttf
> Ptr = 0xf0593000, Sz = 13939436
> Lines = 237160 / 262144
>  
> 
> real    0m0.533s
> user    0m0.209s
> sys     0m0.023s
>  
> 
> [lutser@klutser dirretje]$ ls -l /usr/share/fonts/ko/TrueType/batang.ttf
> -rw-r--r--  1 root root 13939436 Feb 15  2004 
> /usr/share/fonts/ko/TrueType/batang.ttf
>  
> 
> [lutser@klutser dirretje]$ time ./a.out 
> /usr/share/fonts/ko/TrueType/batang.ttf
> Ptr = 0xf061f000, Sz = 13939436
> Lines = 237160 / 262144
>  
> 
> real    0m0.217s
> user    0m0.205s
> sys     0m0.012s
> 
> 
> Nou jongen, laat je dus niet ontmoedigen.
> Doe je best, het kan!
> nou jij!

Ja, het kan. Het lukt me wel denk ik. Ik besef goed dat BASIC niet de
ideale taal is hiervoor, maar goed. Ik ben bezig de code van Ruud te
implementeren. Dat zal me wel lukken.


Hartelijk dank, Bastiaan.

Toen ik Dr.Ruud kietelde, kwam er dit uit:

>   Dim fInput As Integer

Dat is de file-handle, en die had moeten worden
gebruikt, dus niet #1 maar:

    Get fInput, fOffset, fBuffer


Overigens: de iPos die wordt bepaald, is de
positie in de regel, maar dan 1 voorbij het
laatst verwerkte teken; want iPos bevat steeds
de regelpositie waar het volgende teken komt.
Dit is vooral apart als het laatste teken een
stuurteken (zoals tab) is natuurlijk...

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.