Ígéretes patch a BSD grep-hez

 ( trey | 2010. augusztus 17., kedd - 8:59 )

Ahogy arról korábban már szó esett, nem mindenki volt megelégedve a BSD grep sebességével. Voltak akik a GNU grep HEAD-ben való ismételt alapértelmezetté tételét kérték, míg mások inkább a probléma megoldásával voltak elfoglalva. Az utóbbiak közé tartozik Dimitry Andric is, aki készített egy patch-et (aztán hozzáigazította a legfrissebb változtatásokhoz) a BSD grep-hez, majd futtatta Doug Barton tesztszkriptjét és figyelemreméltó javulásról számolt be. Doug Barton megerősítette, hogy Dimitry javításával nagyot léptek előre. Jelenleg a patch tesztelése folyik.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Hát ez elég amatőr hiba volt, de legalább gyors a fix...

csak az nem hibazik, aki nem dolgozik

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

+1

+1 ;)

Ha esetleg bántónak tűnik az első megjegyzésem, triviális kiegészítés:

Pont a jó programozókra jellemző, hogy ha véletlenül hiba marad a kódjukban az nagy valószínűséggel valami amatőr hiba (könnyen és gyorsan javítható, nem kell kukába dobni a kód felét...)

copypaste+valtozoatnemiras powah.
amikor ugyanaz kuldom ki ketszer az usb endpointra oszt nemertem wtf, akkor tok jol esik, amikor rajovok, hogy nem frissitettem a buffert a ket iras kozott...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Hát ja, nem vagyok rá büszke. :) De mentségemre szolgáljon, hogy az előző még szarabb volt, mert a bináris fájl detekciót úgy oldotta meg, hogy minden fájlnak beolvasta az első n bájtját egyszer, utána az el lett dobva, aztán meg újra olvasta a fájlt. Ezért kellett újraírni puffereléssel, hogy az első beolvasás után végezze el a bináris tesztet, és ne dobja el az adatot, hanem olvasson tovább. Az stdio erre kézenfekvőnek tűnt, mert hát gondoltam minek használjak syscallokat... Viszont a gzip meg bzip esetén nincs sor beolvasására alkalmas függvény, és ahelyett hogy csináltam volna ilyet, inkább karakterenként olvastam, ami így mint látszik nem volt elég hatékony, még ha a lockolást csak egyszer végeztük is el.

Ez szép, de ahogy nézem, kirakták belőle a gzip és bzip olvasási lehetőséget. Kiváncsi leszek, hogy mit fog jelenteni, ha visszarakják valamilyen módon.

szerintem akkor nezz erosebben. :)

Igaz, elnéztem. Szimplán csak (nem) kicsit átvariálta a kezelését.

Tudni vmit a BSD grep UTF-8 támogatásáról? Merthogy nemrég volt cikk a hup-on, hogy elindultak (végre) az UTF-8 felé, ez a cikk meg a grep sebességéről szól, és megemlítik a GNU grep-re átállás lehetőségét, márpedig a GNU grep UTF-8 locale (azon belül is leginkább case insensitive keresés, ami ráadásul nyelvfüggő) esetén baromi lassú, leginkább azért mert a fejlesztők sem igen tudják, hogy hogyan lehetne megcsinálni gyorsra. Szóval egyelőre örülnünk kell hogy egyáltalán funkcionálisan jól (vagy nagyjából jól) működik. Kíváncsi lennék, sikerül-e a BSD-seknek megcsinálni helyesre és gyorsra UTF-8-ra is.

Hát igen..ezek az oroszok hihetetlen okosak néha ;-)

Ezt írja, "The GNU grep top called functions are (please ignore the .mcount entry, which is a gprof side effect):"

Tudja valaki, hogyan lehet a top-ot úgy használni, hogy egy futó program függvényhívásait mutassa, ahogy Dimitry levelében szerepel?

--
qmi

Ez nem top-featúra, hanem alighanem gprof.

Ja igen..bocs. Akkor ezt értettem félre. Most látom, jobban el kellett volna olvasnom.

Köszi

--
qmi

itt nem a `top` parancsrol van szo, hanem az n darab legtobbet hivott fuggvenyrol.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

:) Hát ezért nem értettem milyen feature -ről beszélnek feljebb.

--
When your mind is empty of prejudices you can see the Tao.
When your heart is empty of desires you can follow the Tao.