[php/ubb] Stackbased ubbparser verbeteren ;)

[ACM]

Goed, de meesten kennen mijn stackbased parser wel.

Omdat ik nooit toegekomen ben tot een serieuze optimalisatieslag en ook geen echt serieus gebruik meer zie (door mijzelf) is vanaf vandaag de source open (disclaimer: Let op de licentie als je het wil gebruiken ).

Er zijn een aantal nadelen aan de code en de belangrijkste is dat het enorm sloom is.
Overigens is de code erg slecht gedocumenteerd (sorry, was/ben lui ) maar bevat het weinig onbegrijpelijke constructies.

De code werkt verder in principe goed en heb ik ook behoorlijk uitvoerig getest.
Mocht iemand dus vragen hebben, stel ze hier.
Mocht iemand een verbetering weten, post die hier, ook al heb ik zelf de komende week niet echt tijd dat zelf te implementeren en/of testen

Btw, ga alsjeblieft niet de hele code hier posten, het is vrij veel (779 regels ofzo, 3000 was ergens anders van )

[chem]

't is idd vrij veel code, en eerlijk gezegd niet ff in 1x te lezen (tsk! )

ik zal er volgende week eens doorheen bladeren...

[ACM]

Op donderdag 21 maart 2002 12:44 schreef chem het volgende:
't is idd vrij veel code, en eerlijk gezegd niet ff in 1x te lezen (tsk! )

Ach de helft van de regels is leeg of bevat een { of }

Valt me van je tegen hoor, chem

[chem]

eerst eens aan de slag met de cracklib en expiration, dan komt jouw parser volgende week wel weer aan de beurt

[Dennis]

Hmmmmz, ik ga niet iemand hier af lopen kraken hoor, want ik zou het zelf niet kunnen maken, zo'n uitgebreide parser, maar ik vind je code wel slecht in elkaar gezet..

Misschien dat ik een keer zin heb om de hele parser te herschrijven in OO ofzo

[ACM]

Op donderdag 21 maart 2002 15:11 schreef ddc het volgende:
maar ik vind je code wel slecht in elkaar gezet..

Wat is er slecht aan?
Sommige stukken bevatten lapmiddel technieken maar das voornamelijk doordat er bugs opdoken en ik geen tijd had/wilde maken ze goed te fixen
Het grootste deel van de code is trouwens foutontdekkende/verbeterende code

En het gebrek aan commentaar is misschien wat vervelend voor het begrijpen van de code.

Maar geef maar voorbeelden van dingen die beter kunnen

[marcusk]

Op donderdag 21 maart 2002 15:11 schreef ddc het volgende:
Hmmmmz, ik ga niet iemand hier af lopen kraken hoor, want ik zou het zelf niet kunnen maken, zo'n uitgebreide parser, maar ik vind je code wel slecht in elkaar gezet..

Misschien dat ik een keer zin heb om de hele parser te herschrijven in OO ofzo

Dus als je geen OO gebruikt is het slechte code ofzo?

[justmental]

Op donderdag 21 maart 2002 12:35 schreef ACM het volgende:
Goed, de meesten kennen mijn stackbased parser wel.

Omdat ik nooit toegekomen ben tot een serieuze optimalisatieslag en ook geen echt serieus gebruik meer zie (door mijzelf) is vanaf vandaag de source open (disclaimer: Let op de licentie als je het wil gebruiken ).

Mag ik daaruit opmaken dat hij niet in het nieuwe forum gebruikt gaat worden?

Er zijn een aantal nadelen aan de code en de belangrijkste is dat het enorm sloom is.

Wat noem jij sloom?
Ik zie vergelijkbare constructies als in mijn eigen stackbased parser, die lijken me ook geen probleem.
Zo te zien loop je niet herhaaldelijk door de string of de arrays heen.

Het enige wat me opvalt is de hoeveelheid regex die ik nog zie in die settings, die zouden traag kunnen zijn.

[ACM]

Op donderdag 21 maart 2002 15:15 schreef justmental het volgende:
Mag ik daaruit opmaken dat hij niet in het nieuwe forum gebruikt gaat worden?

Dat mag je best doen, maar niks is gegarandeerd omtrend het nieuwe forum totdat het er daadwerkelijk is en zelfs dan nog niet

Wat noem jij sloom?

Vergeleken met dusty's recursieve versie en tomato's (minder flexibele) regexp versie was het 5-10x trager.

Zo te zien loop je niet herhaaldelijk door de string of de arrays heen.

Sterker nog, het terugbrengen van de strpos aanroepen van 3 naar 2 per iteratie leverde nauwelijks winst op.

Het enige wat me opvalt is de hoeveelheid regex die ik nog zie in die settings, die zouden traag kunnen zijn.

En daar is het waarschijnlijk ook het traagst door. Ik heb ook daar nooit echt zin voor gehad dat op te gaan lossen.

Misschien, als ik tijd heb, doe ik dat nog es
Of iemand moet met steengoede tips aan komen zetten natuurlijk

[Nielsz]

Op donderdag 21 maart 2002 15:11 schreef ddc het volgende:
Hmmmmz, ik ga niet iemand hier af lopen kraken hoor, want ik zou het zelf niet kunnen maken, zo'n uitgebreide parser, maar ik vind je code wel slecht in elkaar gezet..

Misschien dat ik een keer zin heb om de hele parser te herschrijven in OO ofzo

HAHHAHAHAHA
* Nielsz heeft zelf nu ook een maandje kennis van OO, nadat de * Nielsz het hem heeft geleerd

[justmental]

Op donderdag 21 maart 2002 15:19 schreef ACM het volgende:
Of iemand moet met steengoede tips aan komen zetten natuurlijk

* justmental kijkt de andere kant op
_{waarom denk je dat ik overgegaan ben op een stackbased parser?
regex zuigt}

[Dennis]

Op donderdag 21 maart 2002 15:15 schreef marcusk het volgende:
Dus als je geen OO gebruikt is het slechte code ofzo?

Nee dat niet, maar er wordt hier wel heel veel van global gebruik gemaakt.

[ACM]

Op donderdag 21 maart 2002 15:40 schreef justmental het volgende:
* justmental kijkt de andere kant op
_{waarom denk je dat ik overgegaan ben op een stackbased parser?
regex zuigt}

Lol, nah ik wil inderdaad odd ook nog van die regexp-validatie van de tags af

Op donderdag 21 maart 2002 15:46 schreef ddc het volgende:
Nee dat niet, maar er wordt hier wel heel veel van global gebruik gemaakt.

En?
Is dat je enige argument??
Dat scheelt enorm veel geheugen-copien hoor

[edit]
* ACM klungelt even met posts

[Dennis]

Op donderdag 21 maart 2002 15:26 schreef Nielsz het volgende:
HAHHAHAHAHA
* Dennis heeft zelf nu ook een maandje kennis van OO, nadat de * Nielsz het hem heeft geleerd

[justmental]

Op donderdag 21 maart 2002 15:47 schreef ACM het volgende:
Lol, nah ik wil inderdaad odd ook nog van die regexp-validatie van de tags af

Bij mij is dat er ook uit, eigenlijk is het ook heel eenvoudig om te maken.

Ik gooi in het begin de string naar upper, vervolgens scan ik op '[' en ']' en gooi alles ertussen in tabel van array's met een indicatie of er een '/' bij stond.
Daarna scan ik de tabel op valide tags en of er bij de begintag ook een eindtag aanwezig is en markeer dit in de tabel.
Daarna komt het conversie gedeelte.

[ACM]

Die validatie is ook het moeilijkste niet

Eigenlijk moet ik hem gewoon chop()-pen en vervolgens met een in_array op een array van de beschikbare tags werken oid

En daarna die losse conversie methoden nog omwerken

[Nielsz]

Op donderdag 21 maart 2002 15:58 schreef justmental het volgende:
[..]
Daarna scan ik de tabel op valide tags

Hoe doe je dit dan?
met een array_search(); ofzo? Want in mijn optiek is regexp 'de' beste manier om 2 strings goed met elkaar te vergelijken.

[ACM]

Op donderdag 21 maart 2002 16:04 schreef Nielsz het volgende:

[..]

Hoe doe je dit dan?
met een array_search(); ofzo? Want in mijn optiek is regexp 'de' beste manier om 2 strings goed met elkaar te vergelijken.

Lower/Uppercase maken en vervolgens vergelijken evt dmv een array_search/in_array

Argumenten zijn dan het enige vervelende Maar die 'negeer' ik (iig) toch al bij de tag-validatie.

[Nielsz]

Op donderdag 21 maart 2002 16:05 schreef ACM het volgende:

[..]

Lower/Uppercase maken en vervolgens vergelijken evt dmv een array_search/in_array

Argumenten zijn dan het enige vervelende Maar die 'negeer' ik (iig) toch al bij de tag-validatie.

yep
en als ik nu een [.img="blaat.jpg"][/img] doe, ipv met '? Dan moet je er weer een andere in de tabel voor zetten, lijkt me niet optimaal

[justmental]

Op donderdag 21 maart 2002 16:05 schreef ACM het volgende:
Lower/Uppercase maken en vervolgens vergelijken evt dmv een array_search/in_array

Argumenten zijn dan het enige vervelende Maar die 'negeer' ik (iig) toch al bij de tag-validatie.

Argumenten zet ik gelijk in een ander veld erbij.
Het begin van een tag is altijd '['
Het eind altijd ']'
Als tweede char='/' dan is het een eindtag.
Als binnen tagstring '=' aanwezig is dan argument is achter '='

[ACM]

Op donderdag 21 maart 2002 16:09 schreef Nielsz het volgende:
en als ik nu een [.img="blaat.jpg"][/img] doe, ipv met '? Dan moet je er weer een andere in de tabel voor zetten, lijkt me niet optimaal

Je weet toch dat ALLES achter een spatie/= genegeerd mag worden voor die validatie?

Maar idd, het kan wat vervelend zijn.
Mijn parser ondersteund in principe ook tags als:
[img=...
w=5 h=10
b=1]

[justmental]

Op donderdag 21 maart 2002 16:04 schreef Nielsz het volgende:
Hoe doe je dit dan?
met een array_search(); ofzo? Want in mijn optiek is regexp 'de' beste manier om 2 strings goed met elkaar te vergelijken.

Ik werk niet met php dus die array_search ken ik niet.
De boel staat al in uppercase dus ik kan de strings gewoon lettelijk vergelijken.

[justmental]

Op donderdag 21 maart 2002 16:13 schreef ACM het volgende:
Je weet toch dat ALLES achter een spatie/= genegeerd mag worden voor die validatie?

Maar idd, het kan wat vervelend zijn.
Mijn parser ondersteund in principe ook tags als:
[img=...
w=5 h=10
b=1]

Flexibiliteit is omgekeerd evenredig met performance.
Zou ik niet doen dus voor dit soort parsers.

[Nielsz]

Op donderdag 21 maart 2002 16:13 schreef ACM het volgende:

[..]

Je weet toch dat ALLES achter een spatie/= genegeerd mag worden voor die validatie?

Maar idd, het kan wat vervelend zijn.
Mijn parser ondersteund in principe ook tags als:
[img=...
w=5 h=10
b=1]

** ja ja ja ja jaja jaja **
_{langzaam maar zeker wordt het duidelijk}

Array_search zal in alle talen die 'm ondersteund gewoon hetzelfde doen, in een array kijken voor een bepaalde string en het arrayid returnen

[ACM]

Op donderdag 21 maart 2002 16:15 schreef justmental het volgende:
Flexibiliteit is omgekeerd evenredig met performance.
Zou ik niet doen dus voor dit soort parsers.

Ach, aangezien spaties/enters/etc gewoon tekens in een string zijn maakt het niet vreselijk veel uit.

Maar verder heb je wel gelijk, ik geloof dat zo'n tag ook helemaal niet werkt met de huidige implemenatie

[Ebayzo]

Sorry voor het kicken van dit oude forum maar toch even een klein vraagje. Hoe kan ik deze parser gebruiken in mijn eigen site? Heb je source al gepakt maar hoe roep ik de parser nou aan

[Skaah]

Beide files includen, en daarna

PHP:

$html = parse($ubb);

[ACM]

De parse-methode aanroepen met je ubb-tekst en dan een van de twee velden uit het array pakken, print_r is your friend (of de code bekijken natuurlijk )

[ Voor 6% gewijzigd door ACM op 29-03-2004 11:05 ]

[Ebayzo]

ACM schreef op 29 maart 2004 @ 11:04:
De parse-methode aanroepen met je ubb-tekst en dan een van de twee velden uit het array pakken, print_r is your friend (of de code bekijken natuurlijk )

Had de code bekeken en parse($blaat); enzo gedaan. Ik had dus $blaat = parse($blaat); moeten doen?

[ACM]

PHP:

function parse($input_text, $pre_parse=true)
{
//...
  return array($output_array, $output_text);
}

$resultaat = parse($invoertekst);
echo $resultaat[1];

Zou moeten werken.

[Ebayzo]

ACM schreef op 29 maart 2004 @ 11:21:

PHP:

function parse($input_text, $pre_parse=true)
{
//...
  return array($output_array, $output_text);
}

$resultaat = parse($invoertekst);
echo $resultaat[1];

Zou moeten werken.

**

Ok hij werkt nu gedeeltelijk...nog even kijken voor de volgende fout

[ Voor 108% gewijzigd door Ebayzo op 29-03-2004 15:31 ]

[TheRookie]

die staat uit-gecomment in de settings file:

PHP:

function getmicrotime()
{
    list($usec, $sec) = explode(" ",microtime());
    return ((float)$usec + (float)$sec);
}

[Ebayzo]

TheRookie schreef op 29 maart 2004 @ 15:30:
die staat uit-gecomment in de settings file:

PHP:

function getmicrotime()
{
    list($usec, $sec) = explode(" ",microtime());
    return ((float)$usec + (float)$sec);
}

Nou hij werkt inmiddels....bij 1 van mijn berichten..

Bij de tweede komt hij al met:

Fatal error: Cannot redeclare build_param() (previously declared in c:\inetpub\wwwroot\nitt\inc\settings.php:90) in c:\inetpub\wwwroot\nitt\inc\settings.php on line 90

[.oisyn]

Ik zal de mijne ook eens online zetten

[Ebayzo]

.oisyn schreef op 29 maart 2004 @ 15:42:
Ik zal de mijne ook eens online zetten

Vertel....


[ontopic]
Het eerste bericht uit de SQL database doet ie nu gewoon goed maar bij de tweede gaat het verkeerd

[code]
include("inc\parser.php");

$resultaat = parse($log['log_tekst']);

echo $resultaat[1];
[/code]

En dit staat dan in een WHILE lus...

maar bij de 2e geeft ie dan de volgende fout:

[quote]
Fatal error: Cannot redeclare build_param() (previously declared in c:\inetpub\wwwroot\nitt\inc\settings.php:78) in c:\inetpub\wwwroot\nitt\inc\settings.php on line 78
[/quote]

En daarna stopt alle uitvoer van PHP...


Schaam

include_once("inc\parser.php"); did the trick!

Alleen loopt ie nu wel de hele tijd te blaten dat hij $height en $width mist bij images! Eens kijken hoe ik dat ga oplossen want ik vergeet vaak height en width mee te geveb

[ Voor 88% gewijzigd door Ebayzo op 29-03-2004 16:08 ]

[Verwijderd]

Leer jezelf even af om backslashes te gebruiken in paden. Dat gaat gegarandeerd problemen opleveren als je het bestand narf.php in de inc directory wilt includen. Je kunt misschien wel raden waarom.
Goed, je kunt dat inderdaad voorkomen door de backslashes te escapen (\\), maar beter is het om slashes te gebruiken (/).

[Ebayzo]

Verwijderd schreef op 29 maart 2004 @ 16:27:
Leer jezelf even af om backslashes te gebruiken in paden. Dat gaat gegarandeerd problemen opleveren als je het bestand narf.php in de inc directory wilt includen. Je kunt misschien wel raden waarom.
Goed, je kunt dat inderdaad voorkomen door de backslashes te escapen (\\), maar beter is het om slashes te gebruiken (/).

Ja idd...dat is ook zoiets wat ik moet leren...

(\t van images\testbeeld.gif vond ie namelijk ook niet leuk )

[.oisyn]

.oisyn schreef op 29 maart 2004 @ 15:42:
Ik zal de mijne ook eens online zetten

http://www.oisyn.nl/tests/omltest.php

De parser werkt als volgt:
Hij deelt mbv een regex de te parsen string op in tokens: stukken tekst en open en sluittags

Dan doorloopt ie gewoon de tokenlijst en houdt ie wat state variabelen bij. Als ie een open-tag tegenkomt die ondersteund wordt (dit komt uit een lijst met settings die je meegeeft aan de parser), dan treedt er een open event op. Voor alle losse stukken tekst in die tag treedt er een pre event op. Als ie een sluittag tegenkomt dan treedt er een post event, en vervolgens een close event op.

Je kunt in de settings per tag specificeren in welke events je geinteresseerd bent, en je kunt een callback functie opgeven die dan wordt aangeroepen. Voor de pre en post events moet je de omgezette tekst retourneren (in de regel doe je in een pre event de smilies en de htmlspecialchars enzo, en in een post event zet je er html tags omheen). Je kunt ook specificeren wat de attributen zijn voor een tag (en in welke volgorde ze geparsed moeten worden als je de [bla=1,2,3] variant gebruikt), of ze een sluittag moeten of mogen hebben, en of ze andere tags mogen bevatten.

Eigenlijk wil ik nog toevoegen dat je kan specificeren welke tags in welke tags gebruikt mogen worden, maar aangezien je dit ook met de callback functie te doen is en het enorm veel werk is om het allemaal te specificeren, heb ik dit maar achterwege gelaten

Het omzetten naar html doe je dus zelf in de callback functies, de parser heeft daar niets mee te maken.

.edit: ik zal er even een parse-tijd bijzetten, hoewel dat natuurlijk weinig betekenis heeft als het op een andere server draait

.edit2: de source

http://www.oisyn.nl/tests/omltest.phps -> de php file
http://www.oisyn.nl/tests/omlsettings.phps -> de settings
http://www.oisyn.nl/tests/oml.phps -> de parser

Voor de codetag gebruikt ie trouwens mijn syntax highlighter module (die hier ook op GoT draait), die is ook opensource, maar dat is dus C/C++ code

Verder is vrijwel alles uncommented

[ Voor 25% gewijzigd door .oisyn op 29-03-2004 17:51 ]

[Alex]

* .oisyn gaat dat dingetje verkopen?
Of gaat * .oisyn dit dingetje beschikbaar stellen ann Tweakertjes

[darkrain]

Nice .oisyn.

Hij is zeker niet open zource zoals die van ACM?
Of anders misschien onder dezelfde voorwaarden te gebruiken?

Ik ben wel geintereseerd.

[/laat]

[ Voor 4% gewijzigd door darkrain op 29-03-2004 17:30 ]

[Tux]

In de settings.php van ACM's parser staat de functie build_img()

Daar staat het volgende stukje code:

PHP:

if(isset($matches[1][1]))
            $height=" height='{$matches[1][1]}'";
        if(isset($matches[2][1]))
            $width=" width='{$matches[2][1]}'";

        return " src='{$matches[0][1]}'$height$width";

Dit werkt niet helemaal goed in sommige gevallen. Hij geeft dan namelijk een warning dat $height en $width niet bestaan.
Ik heb het ooit opgelost door $height = ""; en $width = ""; boven die if-check te plaatsen.

Een andere manier is :

PHP:

$height  = isset($matches[1][1]) ? ' height="' . $matches[1][1] . '"' : '';
$width = isset($matches[2][1]) ? ' width="' . $matches[2][1] . '"' : '';

return ' src="' . $matches[0][1] . '"' . $height . $width;

[ Voor 60% gewijzigd door Tux op 29-03-2004 17:41 ]

[.oisyn]

Oh ja source vergeten

http://www.oisyn.nl/tests/omltest.phps -> de php file
http://www.oisyn.nl/tests/omlsettings.phps -> de settings
http://www.oisyn.nl/tests/oml.phps -> de parser

Voor de codetag gebruikt ie trouwens mijn syntax highlighter module (die hier ook op GoT draait), die is ook opensource, maar dat is dus C/C++ code

Verder is vrijwel alles uncommented

[zeroxcool]

.oisyn schreef op 29 maart 2004 @ 17:50:
Voor de codetag gebruikt ie trouwens mijn syntax highlighter module (die hier ook op GoT draait), die is ook opensource, maar dat is dus C/C++ code

En waar is die te vinden ?

[darkrain]

Ja precies waar kunnen wij die syntax highlighter vinden.
Ik heb al behoorlijk gezocht op GoT maar niet gevonden nog.

Misschien een linkje?

[simon]

De syntax highlighter van onze grote vriend ACM werkt namelijk niet zo goed, om een of andere reden gaan de kleuren altijd bij mij mis.. Hoe fix ik dat? Het is overigens een erg goed te gebruiken parser, imho

[ludo]

Ik ben een tijdje geleden ook bezig geweest met het in elkaar knutselen van een soortgelijke parser Hij was vooral bedoeld om even een beetje met PHP5 te spelen en is niet uitgebreid getest ofzo. Maar misschien vinden jullie het leuk om er even naar te kijken

De parser is opgebouwd uit twee classes, eentje is de parser zelf, de andere is voor de smileys. De codes voor deze smileys staan in een xml bestandje.

• class.BBMLParser.phps
• class.BBMLEmoticon.phps
• data.emoticons.xml

Ik heb helaas geen server met PHP5 aanstaan zodat jullie hem ook even 'live' kunnen testen...

Aanroepen gaat als volgt:

PHP:

$parser = new BBMLParser($data);
$data = $parser->getOutput();

Tips zijn natuurlijk altijd welkom. Als je hem wilt gebruiken, gelieve de credits dan te laten staan.

Ow ja, heb ook nog wat 'documentatie': http://www.bierclan.nl/parse/doc/

[ Voor 6% gewijzigd door ludo op 29-03-2004 22:56 ]

[.oisyn]

http://www.oisyn.nl/SyntaxHighlighter.zip

Geen idee of dat zo compilet trouwens... je hebt iig flex++ nodig. Voor windows kun je die halen bij http://gnuwin32.sourceforge.net, maar voor linux heb je tegenwoordig een nieuwere die dus niet compatible is met de header en skeleton file in het zipje
Ik heb wel een werkende linux makefile voor die nieuwere versie, maar daar heb je dus een andere FlexLexer.h voor nodig (de FlexLexer.h die standaard bij flex zit is niet de goede!)

De talen die ondersteund worden zijn C, C++, C#, Java, Delphi, VB, VB.Net en PHP

.edit: ik heb 'm wat aangepast, in readme.txt staan instructies, en ik heb de nieuwere FlexLexer.h in de directory newflex gezet

[ Voor 11% gewijzigd door .oisyn op 29-03-2004 19:51 ]

[darkrain]

had ik al gezeg dat je super bent .oisyn??
bij deze dan.

[zeroxcool]

.oisyn schreef op 29 maart 2004 @ 19:32:
http://www.oisyn.nl/SyntaxHighlighter.zip

Geen idee of dat zo compilet trouwens... je hebt iig flex++ nodig. Voor windows kun je die halen bij http://gnuwin32.sourceforge.net, maar voor linux heb je tegenwoordig een nieuwere die dus niet compatible is met de header en skeleton file in het zipje
Ik heb wel een werkende linux makefile voor die nieuwere versie, maar daar heb je dus een andere FlexLexer.h voor nodig (de FlexLexer.h die standaard bij flex zit is niet de goede!)

De talen die ondersteund worden zijn C, C++, C#, Java, Delphi, VB, VB.Net en PHP

.edit: ik heb 'm wat aangepast, in readme.txt staan instructies, en ik heb de nieuwere FlexLexer.h in de directory newflex gezet

Beetje late reactie, bedankt .oisyn, ziet er leuk/goed uit :)!

[Ebayzo]

Lol never mind

[ Voor 92% gewijzigd door Ebayzo op 02-04-2004 16:45 ]

[eamelink]

.oisyn, zit je hier nou gruwelijk je eigen parser te spammen??

http://ubb.eamelink.nl <- Woohoo