[java] streams replace => buffer

[heymeemij]

Streams streamreplace & buffering

Dit is de functie die ik maak
public void findAndReplace(InputStream input,Map<Finder,Converter>map,OutputStreamWriter Doutstream) throws IOException{


dit was de tijdelijke testbuffer.
buffer= new char[20];

Nu mijn vraag is wat jullie denken dat de beste buffer zou zijn. gelet op multifunctioneel te zijn (opensource).

Meer achtergrondinfo

Bedoeling is elke stream te kunnen manipuleren bijvoegen veranderen comprimeren coderen maakt niet uit videostream audiostream charstream:
iets vinden, iets veranderen.

het zijn twee interfaces die gebruikt worden om iedereen toe te laten een finder te maken en of een replacer. De replacer krijgt dan de buffer mee die de finder gevonden heeft.

Let op: er komen nieuwe interfaces aan.
dit is de repos svn checkout :"http://javamylibs.googlecode.com/svn/trunk/" javamylibs-read-only

[NetForce1]

Probeer eens om duidelijk en gestructureerd je probleem neer te zetten, want dit is niet echt te snappen zo.
Code zet je hier tussen code-tags:
[code=java]
//hier je code
[/]

Overigens werken streams in java met bytes, niet met chars, als je met chars wilt werken heb je een Reader/Writer nodig.

[Voor 25% gewijzigd door NetForce1 op 09-10-2010 10:37]

[Remus]

Ik vraag me af of het niet handiger is om een FilterInputStream en/of FilterOutputStream subclass te maken, net zoals bijvoorbeeld een aantal compressie en decompressie streams in Java dat doen. Dat is veel generieker toepasbaar dan een een class die vanuit een inputstream naar een outputstream schrijft, en is ook geschreven met toepassingen vergelijkbaar met wat jij in je hoofd hebt.

[heymeemij]

U begrijpt wellicht dat dit te complex is om hier volledig te plaatsen
Ik zal het trachten op de repos een werkende editie te zetten.

Onderstaande code werkt niet alleen ik tracht alle de code onder presrc te plaatsen(zie repos).
FAQ=>http://subversion.apache.org/faq.html#co-svn

Java:

package multimanipulators;

import java.io.DataOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStreamWriter;
import java.io.PrintStream;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
/**
 * @author Lieven Roegiers
 * @copyright 2009
 * @CMS autosite
 * @from http://javamylibs.googlecode.com/svn/trunk/
**/
public class StreamMultiManipulator{
    private int maxbuffer=0;//wil zeggen wat de grootste lock is van alle finders
    private static final boolean DEBUG = true;
    public Map<Finder,Converter>transformerslist;
    public List<Finder>finders;
    private Finder finder;
    private int charint;//actieve char 
    private boolean ismatch;//wil zeggen wanneer er een posietieve match is gevonden
    private int bufferclock;
    private char buffer[];
    private void init(){
        buffer= new char[20];
        finders = new ArrayList<Finder>();
        ismatch = false;
        System.out.println("<INIT>");
        for (Finder finder : transformerslist.keySet()) {
            finder.init();
            System.out.print("<INIT:"+finder+">");
        }
    }
    public void findAndReplace(InputStream input,Map<Finder,Converter>map,OutputStreamWriter Doutstream) throws IOException{
        transformerslist = map;
        init();
        for (Finder finder : transformerslist.keySet()) {
            finders.add(finder);
            System.out.println("add to finders "+finder.toString());
        }
        if (DEBUG){System.out.print("<<<DEBUG=>start I>>>");}
        try{
        while ((charint = input.read()) != -1 ){
            if (DEBUG){
                System.out.print("\n <<"+(char)charint+">><MAX:"+maxbuffer+",I:"+bufferclock+">");
                System.out.print("<<BUFFER?:");
                System.out.print(buffer);
                System.out.print(">");
            }
            if (finderobjects(charint)){//search for match is found
                if (DEBUG){System.out.print("<FOUNDMATCH>");}
                Converter x =map.get(finder);
                x.manipulate(buffer,Doutstream);
                bufferclock =0;
                //buffer = null;
                init();
            }else if(maxbuffer<bufferclock ){//match not found buffer bigger than must to used finder
                if (DEBUG){System.out.print("<RESIZE BUFFER MAX:"+maxbuffer+"KLOK:"+bufferclock+">");}
                /**  wil write chars to Doutstream when it is nog used  */
                char tmp[]=trimarray(buffer, bufferclock - maxbuffer);
                if (DEBUG){System.out.print("<append '"+new String(tmp)+"'>");}
                Doutstream.append(new String(tmp));
                //Arrays.fill(, arrayLeft(buffer,bufferclock - maxbuffer));
                System.arraycopy(buffer, 1, buffer, 0, buffer.length-bufferclock - maxbuffer);
                bufferclock =maxbuffer;
            }else if(maxbuffer==bufferclock ){//loss buffer
                if (DEBUG){System.out.print("<NEXT>");}
                Doutstream.append(new String(buffer));
            }else{
                if (DEBUG){System.out.print("<else>");}
            }
        }
        }catch(StringIndexOutOfBoundsException e){
            System.out.println("ERROR OUT OF BOUND");           
        }
        if (DEBUG){System.out.print("<<<<<<<<<<<<<<<<<DEBUG=>stop>>>>>>>>>>>");}
    }
    private boolean finderobjects(int achar){
        //wil zeggen wat de grootste lock is van alle finders
        boolean ischarfound = false;
        for (Iterator<Finder> iter = finders.iterator(); iter.hasNext();) {//Generics No casting =>faster
            finder = iter.next();
            if (DEBUG){finder.toString();}
            if(finder.isnext(achar)){//equals char
                ischarfound =true;
            }
            if(finder.ismatchfound()){
                ismatch = finder.ismatchfound();
                buffer[bufferclock]=(char)achar;
                maxbuffer =0;
                return true;
            }
        }
        if (ischarfound){
            buffer[bufferclock]=(char)achar;
            bufferclock++;
            if (maxbuffer<bufferclock){
                maxbuffer = bufferclock;
                finders.size();
            }
        }else{
            maxbuffer =0;
        }
        if (finders.size()>0){
            if (DEBUG){System.out.print("<FINDERSIZE:"+finders.size()+">");}
        }
        return false;
    }
    private char[]trimarray(char[]array,int length){
        char buffer[] = new char[length];
        if (DEBUG){System.out.print(length);}
        System.arraycopy(array, 0, buffer, 0, length);//arraycopy(Object srcarray, int srcPos,Object destarray,int destPos,int length)
        return buffer;
    }

[NetForce1]

Maar wat is nu precies je probleem?

[ReenL]

Als het universeel moet zijn praat je sowieso over bytes.

Als de lengte van hetgeen dat je wilt vinden niet van te voren gedefinieerd is, dan zul je dat in je Finder moeten definieren. Wat je ook kan doen is het de Finder zelf uit laten zoeken.

Dus:
- 1 byte lezen
- Byte in alle finders wegschrijven
- Finder bepaald of er iets gereplaced zou kunnen worden
- Als er niets gereplaced moet worden wegschrijven in out
- Als er wel wat gereplaced zou kunnen worden, bufferen totdat je een resultaat hebt.

Een ArrayList groeit automatisch en zou je als buffer kunnen gebruiken omdat je de lengte dan niet van te voren weet, anders met arraycopy werken.

[Herko_ter_Horst]

@TS Je praat nu vanuit een oplossing die je al gedeeltelijk hebt uitgedacht, maar je geeft niet aan waar dit een oplossing voor is. We kunnen je beter helpen, als we het probleem (en niet de oplossing) kennen.

Kun je in elk geval aangeven waarom de suggestie van Remus m.b.t. FilterIn/OutputStream niet geschikt is? Want dat was ook het eerste waar ik aan dacht toen ik de titel van dit topic las...

[RobIII]

Herko_ter_Horst schreef op zaterdag 09 oktober 2010 @ 14:58:
@TS Je praat nu vanuit een oplossing die je al gedeeltelijk hebt uitgedacht, maar je geeft niet aan waar dit een oplossing voor is. We kunnen je beter helpen, als we het probleem (en niet de oplossing) kennen.

Precies.

Het lijkt me sowieso niet handig om meerdere finders/converters te kunnen specificeren in 1 method; hoe weet je dat ze elkaar niet in de weg gaan zitten? Wat als ik 2 finders opgeef die afvuren bij "foo" en dan allebei hun "converters" los laten? Slecht plan imho. Dan is het beter je zaken "in serie" te zetten en ze dus chainable te maken. Aan 1 kant gaat er iets in, aan de andere kant komt 't er uit en die output stop je dan (eventueel) weer in de volgende.

Als het je puur om de buffergrootte te doen is; waarom geef je die dan niet gewoon mee aan de constructor?

[Voor 32% gewijzigd door RobIII op 09-10-2010 15:07]

[heymeemij]

Zou ik zonder een datatype te bepalen kunnen werken nu gebruik ik de input.read() dus int
maar wat bij utf8 en hoe moet die dan juist werken.

Constructor lijkt mij al iets maar je kan geen lengte bepalen zonder het te weten wat het zou worden

Zou ik het moeten verplichten het in de Finder te defineren en wat als het boven 4 gig(denkend aan mem) is wat je op voorhand niet kan weten.
Want je moet weten er is een imgincluder die mogelijks ook online imgs moet bufferen op de betreffende client. (denkend aan fo to pdf).

[RobIII]

heymeemij schreef op zaterdag 09 oktober 2010 @ 17:43:
Zou ik zonder een datatype te bepalen kunnen werken nu gebruik ik de input.read() dus int
maar wat bij utf8 en hoe moet die dan juist werken.

Ik de zin begrijp helemaal niet moeite snijden hout van. Maar misschien ligt dat aan mij. Overigens geldt datzelfde ook voor je topicstart. 't Is net of we halverwege een film zijn binnengevallen; je doet nogal wat aannames over zaken die wij volgens jou klaarblijkelijk al weten over je probleem terwijl in werkelijkheid je hele probleem niet bekend is. En onze glazen bol is al een tijdje stuk.

Het is me dus niet helemaal duidelijk wat je probleem is, wat je oplossing nou precies moet oplossen en wat überhaupt het doel is. Misschien dat je daar wat over kunt uitweiden?

Een int is natuurlijk iets anders dan een karakter, maar beide bestaan ze uit bytes; als je ze op dat niveau behandelt blijven 't natuurlijk alleen maar bytes maar heb je dus minder kennis in je stream van het type data waar je mee werkt dan je misschien zou willen. Je zou zo'n object dus kunnen inlichten hoe de data behandeld moet worden en welke encoding er gebruikt wordt. Ik weet niet of 't zinnig is in dit topic maar ik gooi 'm toch even: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

heymeemij schreef op zaterdag 09 oktober 2010 @ 17:43:
Constructor lijkt mij al iets maar je kan geen lengte bepalen zonder het te weten wat het zou worden

Eh? Weten wat wat zou worden?

heymeemij schreef op zaterdag 09 oktober 2010 @ 17:43:
Zou ik het moeten verplichten het in de Finder te defineren en wat als het boven 4 gig(denkend aan mem) is wat je op voorhand niet kan weten.

Nogmaals: het is me niet duidelijk wat je ding nou precies moet doen of probeert op te lossen maar waarom zou er noodzaak zijn om die 4gig in-mem te houden? Als voorbeeld: je kunt toch ook prima 50Gb bestanden downloaden (duurt dan wel effe...) zonder 5Gb geheugen te hebben?
Je kunt toch gewoon door je data heen fietsen met een buffer van x bytes? Of dat dan 1 byte of 1 megabyte is is natuurlijk afhankelijk van hoeveel data je nodig hebt om iets zinnigs mee te kunnen doen (en ook nog eens deels afhankelijk natuurlijk van je I/O zodat je een beetje efficiënt kunt lezen en schrijven maar dat is bijzaak).

heymeemij schreef op zaterdag 09 oktober 2010 @ 17:43:
Want je moet weten er is een imgincluder die mogelijks ook online imgs moet bufferen op de betreffende client. (denkend aan fo to pdf).

Doe ons een lol en probeer even coherente zinnen te maken en even uit de doeken te doen wat je nou eigenlijk aan 't doen bent...

[Voor 45% gewijzigd door RobIII op 09-10-2010 17:58]

[Remus]

heymeemij schreef op zaterdag 09 oktober 2010 @ 17:43:
Zou ik zonder een datatype te bepalen kunnen werken nu gebruik ik de input.read() dus int
maar wat bij utf8 en hoe moet die dan juist werken.

Constructor lijkt mij al iets maar je kan geen lengte bepalen zonder het te weten wat het zou worden

Zou ik het moeten verplichten het in de Finder te defineren en wat als het boven 4 gig(denkend aan mem) is wat je op voorhand niet kan weten.
Want je moet weten er is een imgincluder die mogelijks ook online imgs moet bufferen op de betreffende client. (denkend aan fo to pdf).

Gebruik reader als je met karakterdata werkt. InputStream is byte georienteerd. En ja InputStream#read() retourneert misschien een int, maar het is een representatie van byte (0 tot 255 of -1 bij end of stream):

uit de API doc van InputStream
Reads the next byte of data from the input stream. The value byte is returned as an int in the range 0 to 255. If no byte is available because the end of the stream has been reached, the value -1 is returned. This method blocks until input data is available, the end of the stream is detected, or an exception is thrown.

Van je TS en je reacties krijg ik een beetje gevoel dat je niet weet waar je mee bezig bent, en dat je dus maar een beetje aan loopt te klooien.

Ik kan je aanraden om je te voegen naar het standaard idioom in java, en dat is het decoreren van een inputstream of outputstream (wrappen dus). En ik zou daarbij zoals Rob al suggereert een inputstream per filteroptie gebruiken.

[heymeemij]

Sorry van mijn slecht taal gebruik.(rob3)bekijk eens de repos de enkele Streammanipulator en zie de bedoeling.

Mijn probleem was data type te kiezen omdat het niet eenvoudig is aanpassingen nadien te doen. Ik vraag gewoon sugesti om nadien geen @Deprecated te moeten gebruiken omdat ik een foute keuze maakte(Omdat als er een interface in gebruik is. Je niet meer terug kan, en daarom Ik de nieuwe versie nog bekend maak).Er is een werkende versie die één kan wijzigen.Waarom Niet aaneenschakelen (geheugen)

FilterInputStream en/of FilterOutputStream Is geen optie. Ik maak nieuwe tool StreamMultiManipulator enkel omdat er geen replace bestaat.=>Stringreplace werkt ook niet omdat een stream een nagenoeg oneindig iets kan zijn. Het is zeker dat de eerste gevonden de andere uitschakeld. Wat een mogelijk upgrade voor volgende versie zou zijn.

Waarom geen byte maar (int) omdat ik geen convertie van datatypes te laten gebeuren op achtergrond(zie java core).Wat ik ooit zag in een curssus dus daarom ook geen Integer.Indien er mensen kunnen aantonen dat er een beter mannier is zou ik die graag weten.

Die 4 gig verduidelijken: Stel dat de buffer groeit boven 4gig en server heeft geen geheugen. Verlies je veel tijd (wegschrijven naar hd )die de server in het slechte geval een crach veroorzaakt wat dus niet de bedoeling is.

Verder staat volledige code op repos(zie bovenaan): presrc/multimanipulators/

[Janoz]

heymeemij schreef op zondag 10 oktober 2010 @ 13:31:
Sorry van mijn slecht taal gebruik.(rob3)bekijk eens de repos de enkele Streammanipulator en zie de bedoeling.

Probeer jij eerst maar eens in je eigen woorden uit te leggen wat de bedoeling is. Wij gaan niet in een repos(??) naar code zitten kijken. Code is namelijk een implementatie van een oplossing. Wij vragen om het probleem. Daarnaast kun je je wel excuseren vanwege je taalgebruik, maar wanneer je op dezelfde voet door blijft gaan begrijpt helemaal niemand wat je eigenlijk probeert duidelijk te maken.

[Herko_ter_Horst]

heymeemij schreef op zondag 10 oktober 2010 @ 13:31:
Sorry van mijn slecht taal gebruik.(rob3)bekijk eens de repos de enkele Streammanipulator en zie de bedoeling.

Mijn probleem was data type te kiezen omdat het niet eenvoudig is aanpassingen nadien te doen. Ik vraag gewoon sugesti om nadien geen @Deprecated te moeten gebruiken omdat ik een foute keuze maakte(Omdat als er een interface in gebruik is. Je niet meer terug kan, en daarom Ik de nieuwe versie nog bekend maak).Er is een werkende versie die één kan wijzigen.Waarom Niet aaneenschakelen (geheugen)

FilterInputStream en/of FilterOutputStream Is geen optie. Ik maak nieuwe tool StreamMultiManipulator enkel omdat er geen replace bestaat.=>Stringreplace werkt ook niet omdat een stream een nagenoeg oneindig iets kan zijn. Het is zeker dat de eerste gevonden de andere uitschakeld. Wat een mogelijk upgrade voor volgende versie zou zijn.

Waarom geen byte maar (int) omdat ik geen convertie van datatypes te laten gebeuren op achtergrond(zie java core).Wat ik ooit zag in een curssus dus daarom ook geen Integer.Indien er mensen kunnen aantonen dat er een beter mannier is zou ik die graag weten.

Die 4 gig verduidelijken: Stel dat de buffer groeit boven 4gig en server heeft geen geheugen. Verlies je veel tijd (wegschrijven naar hd )die de server in het slechte geval een crach veroorzaakt wat dus niet de bedoeling is.

Verder staat volledige code op repos(zie bovenaan): presrc/multimanipulators/

Er is echt geen touw vast te knopen aan wat je zegt. Probeer eerst eens normale, enkelvoudige zinnen te schrijven. Begin met een hoofdletter, eindig met een punt. Laat uitbreidingen tussen haakjes weg. Let ook even op de spelling van woorden.

Je hebt nog steeds niet verteld waarom je dit aan het maken bent. Wat wil je uiteindelijk met deze code kunnen? Geef eens een voorbeeld van waar jij of iemand anders deze code voor gaat gebruiken. En zeg niet "zoeken en vervangen van dingen in streams". Geef een concreet voorbeeld van wat je wilt doen en liefst meer dan 1 als het allemaal echt zo generiek moet.

Ik zoek naar een beschrijving als: "als ik een webpagina download, dan kan ik met mijn findAndReplace methode overal waar FOO staat, er BAR van maken". Of: "als ik een MP3 file open, dan kan ik via findAndReplace alle hoge tonen er uit halen". Of: "als ik een willekeurige sequence van bytes tegenkom, kan ik die met findAndReplace vervangen door een andere sequence van bytes".

PS: Wat je allemaal ooit eens gehoord of gelezen hebt, is niet interessant, tenzij je een link naar een gezaghebbende bron kunt toevoegen. "zie java core" en "Wat ik ooit zag in een curssus" zegt helemaal niets.

[Voor 6% gewijzigd door Herko_ter_Horst op 10-10-2010 14:23]

[Remus]

heymeemij schreef op zondag 10 oktober 2010 @ 13:31:
FilterInputStream en/of FilterOutputStream Is geen optie. Ik maak nieuwe tool StreamMultiManipulator enkel omdat er geen replace bestaat.=>Stringreplace werkt ook niet omdat een stream een nagenoeg oneindig iets kan zijn. Het is zeker dat de eerste gevonden de andere uitschakeld. Wat een mogelijk upgrade voor volgende versie zou zijn.

En waarom zijn FilterInputStream en/of FilterOutputStream niet geschikt voor je toepassing; ik zie niet in waarom niet? Voor zover ik je probleem begrijp, is het namelijk exact waarvoor ze gemaakt zijn: binnenkomende of uitgaande bytes manipuleren of transformeren (bijvoorbeeld encrypte, compressie, modificatie van bepaalde byte sequence etc). Met buffering, lookahead of een PushbackInputStream is veel mogelijk. Een stream kan misschien oneindig zijn, maar als je een sliding window van voldoende grootte gebruikt, dan is veel mogelijk.

Waarom geen byte maar (int) omdat ik geen convertie van datatypes te laten gebeuren op achtergrond(zie java core).Wat ik ooit zag in een curssus dus daarom ook geen Integer.Indien er mensen kunnen aantonen dat er een beter mannier is zou ik die graag weten.

Je gaat voorbij aan het feit dat die integer geen integer data bevat, maar byte-data of een indicatie dat de stream afgelopen is. Daarnaast doe je wel aan conversie: namelijk van int naar char, wat in deze context absurd is: die geretourneerde int behoort op geen enkele manier als een char geïnterpreteerd te worden. Ik herhaal het nog maar eens: als je met character data werkt, moet je een Reader gebruiken! en als je niet met character-data werkt: doe dan niet alsof je dat wel doet

Die 4 gig verduidelijken: Stel dat de buffer groeit boven 4gig en server heeft geen geheugen. Verlies je veel tijd (wegschrijven naar hd )die de server in het slechte geval een crach veroorzaakt wat dus niet de bedoeling is.

En waarom zou die buffer 4 gigabyte groot worden? Dat heb je nog altijd zelf in de hand.

[heymeemij]

Ik bedank iedereen voor hulp/reacties.Ik hoop snel met een release te kunnen komen.Ik denk dat het meer moeite zal kosten jullie alles volledig uit te leggen dan het zelf uit te zoeken. Al was het enkel wat denkfouten er uit te halen, Om zo weinig mogelijk geheugen te gebruiken en De functie Parameters zo te Kiezen dat Het nut zou verhogen.

< Bij deze geloten --> reacties worden niet verder opgevolgd >
PS :modjes Ik merk dat er hogere pretentie dan vroeger(10 jaar geleden).
In mijn ogen is elke goed programmeur ook codereader en dus weinig uitleg nodig.
Bijgevolg gaat veel inhoud verloren Door rond te pot te draaien over de vorm. Maar dat is dan mijn probleem dat ik met enkele kernwoorden voldoende inhoud heb en meestal van anderen dit eigenlijk niet mag verwachten.

[Herko_ter_Horst]

Pretenties dus. Ik heb je code (en ook je zogenaamde licentie, ik hoop niet dat ik nu 3 maanden 2000 euro moet betalen voor deze opmerking) bekeken, en er is op geen enkele manier uit te halen wat nou de bedoeling is, d.w.z. wat is de usecase. Kun je wel net doen of jij beter bent dan de rest, maar jij bent degene die om hulp vraagt, dus ligt bij jou de verantwoordelijkheid je probleem fatsoenlijk te beschrijven.

Een programmeur is wel wat meer dan een codeklopper (danwel lezer). Een programmeur moet ook op fatsoenlijk niveau kunnen communiceren over het probleem, de gekozen oplossing en de uitwerking daarvan in code. Code staat niet op zichzelf, het is een representatie van de oplossing van een probleem. De context, de usecase, het waarom van de code, blijkt niet uit de code zelf, maar uit de documentatie en het verhaal eromheen.

[Voor 36% gewijzigd door Herko_ter_Horst op 10-10-2010 22:26]

[RobIII]

heymeemij schreef op zondag 10 oktober 2010 @ 22:00:
< Bij deze geloten --> reacties worden niet verder opgevolgd >

Sluiten doen wij wel

heymeemij schreef op zondag 10 oktober 2010 @ 22:00:
In mijn ogen is elke goed programmeur ook codereader en dus weinig uitleg nodig.

In mijn ogen kan een goed programmeur een probleem in klare taal duidelijk samenvatten en overbrengen naar zijn collega's en daar vervolgens een geschikte oplossing voor vinden, die uitwerken, coden en daarna documenteren. Als ik in m'n werk met jouw werk te schaften had gehad had ik je de code retour gegeven met een Jij bent er 1 van het slag "Real programmers don't document. Documentation is for wimps who can't read the code"; IMHO de ergste eruit. En de "documentatie" die er is slaat als een tang op een varken.

heymeemij schreef op zondag 10 oktober 2010 @ 22:00:
Maar dat is dan mijn probleem dat ik met enkele kernwoorden voldoende inhoud heb en meestal van anderen dit eigenlijk niet mag verwachten.

Je topic bevat, inderdaad, alleen maar kernwoorden. Je neemt niet eens de moeite er leesbare zinnen van te maken of een coherent samenhangend verhaal. Ik verzoek je dan ook vriendelijk om daar voortaan rekening mee te houden en dat wij plebs dus moeite hebben iemand van uw caliber te kunnen volgen.

[Voor 19% gewijzigd door RobIII op 10-10-2010 22:32]

[Killemov]

heymeemij schreef op zaterdag 09 oktober 2010 @ 09:58:
dit was de tijdelijke testbuffer.
buffer= new char\[20];

Nu mijn vraag is wat jullie denken dat de beste buffer zou zijn. gelet op multifunctioneel te zijn (opensource).

De buffersize configureerbaar maken met een default van 1024. Dan bepaalt de buffer het maximale zoekwindow van een Finder.

Als je dan toch de Finder het maximale zoekwindow wil laten bepalen, dan zul je daarvoor een method in de Finder-interface moeten opnemen die de benodigde buffersize teruggeeft. Itereer over al je finders, pak de grootste benodigde buffersize ... voila.

[Hydra]

RobIII schreef op zondag 10 oktober 2010 @ 22:23:
En de "documentatie" die er is slaat als een tang op een varken.

Wow. lowercasing, UpperCasing en camelCasing allemaal in een class. Chapeau!

Edit: oh woops, geen camelcasing. De java standaard is de enige die niet gebruikt wordt

[Voor 9% gewijzigd door Hydra op 11-10-2010 17:29]

[RobIII]

Killemov schreef op maandag 11 oktober 2010 @ 15:39:
[...]

De buffersize configureerbaar maken met een default van 1024. Dan bepaalt de buffer het maximale zoekwindow van een Finder.

Met een beetje slim algoritme kun je met een buffer van (zeg) 1024 maar net zo goed met een buffer van 16 of 32768 bytes zoeken op een vele grotere match hoor My point being: een zoekwindow hoeft niet bepalend te zijn (maar maakt het wel een tikkie ingewikkelder).

[writser]

offtopic:
Ik hoop dat niemand hier bodson heet ..

This code is copyright and can only used by opensource for free.
This code used the fop lib
<dutch>
elke overtreding maakt u bindend aan een contract van 3 maand aan 2000 euro(uit te betalen).
al dan niet in overleg uitgevoerd.
</dutch>
every company with name bodson, or person in a company can not/never use this functions.

link

[Killemov]

RobIII schreef op maandag 11 oktober 2010 @ 20:34:
[...]

My point being: een zoekwindow hoeft niet bepalend te zijn (maar maakt het wel een tikkie ingewikkelder).

Interessant, verklaar u nader.

Ik heb natuurlijk ook niet voor niets "configureerbaar" geroepen. IMNSHO is (de grootte van) het zoekwindow uiteindelijk WEL bepalend. Het KAN wel dynamisch worden vergroot, echter met een behoorlijk risico op out-of-memory exceptions.

[Hielko]

Killemov schreef op dinsdag 12 oktober 2010 @ 00:04:
[...]

Interessant, verklaar u nader.

Ik heb natuurlijk ook niet voor niets "configureerbaar" geroepen. IMNSHO is (de grootte van) het zoekwindow uiteindelijk WEL bepalend. Het KAN wel dynamisch worden vergroot, echter met een behoorlijk risico op out-of-memory exceptions.

Je kan als je op iets wilt zoeken dat groter is dan de buffer gewoon bijhouden of je tot nu toe een match hebt, volgende stuk van de stream in de buffer gooien en dit herhalen net zo lang totdat je geen match meer hebt, of juist een complete match hebt.

(Wat je volgens mij sowieso deels al moet doen aangezien je vast geen garanties hebt dat wat je zoekt keurig in de buffer zit)

[Voor 9% gewijzigd door Hielko op 12-10-2010 00:26]

[RobIII]

Hielko schreef op dinsdag 12 oktober 2010 @ 00:25:
Je kan als je op iets wilt zoeken dat groter is dan de buffer gewoon bijhouden of je tot nu toe een match hebt, volgende stuk van de stream in de buffer gooien en dit herhalen net zo lang totdat je geen match meer hebt, of juist een complete match hebt.

Precies.

Hielko schreef op dinsdag 12 oktober 2010 @ 00:25:
(Wat je volgens mij sowieso deels al moet doen aangezien je vast geen garanties hebt dat wat je zoekt keurig in de buffer zit)

Precies; je heb worst case net 1 byte van de match aan het eind je readbuffer zitten en de volgende read de rest van de match (of omgekeerd, in de readbuffer zit alles op 1 byte na en de rest in de tweede read). En bij een match die groter is (1 of meerdere malen zelfs) dan een hele buffer wordt dat alleen nog maar lastiger. Maar het blijft een kwestie van zoeken naar partial matches en zodra je een hit hebt gewoon proberen door te matchen. Lukt dat->match, lukt dat niet->geen match.