[BC3] [php/ubb]Parse engine is "af", graag tips ;)

[ACM]

En na lang knoeien (en wat programmeer werk) is mijn ubb parse engine eindelijk af.
Hij is dus nog steeds stack based en parsed nu zelfs "[ php][ php][ /php][ /php]" goed
Geen enkele tag wordt binnen php of code tags geparsed.

Magoed, uiteraard kan ik hem (of haar?) zelf nooit zo goed testen als een stel "domme" maar vooral objectieve gebruikers

Iedereen die hem wil testen is van harte welkom, alhoewel ik het sommige per icq al heb gevraagd
Mocht je tips hebben voor bepaalde onderdelen, graag.

De "reference" is de regexp-based (alpha-status) parser van jaapf (die van tomato heb ik er weer uitgehaald, maar kan er ook bij hoor) foutjes daarin kan ik niet veel aan doen dus

De url is onveranderd gebleven: parser

Veel plezier met het eventuele bugs vinden en met het mij uitlachen als je er een vindt

[ Voor 1% gewijzigd door ACM op 09-10-2007 22:43 . Reden: vulcanus.its.tudelft.nl is niet meer ]

[Verwijderd]

Mooi hoor, ik ben geen vaudjes tegen gekomen...

Wordt hij ook OpenSRC, ik denk dat je er een boel mensen () een plezier mee zou doen.

[ACM]

Op zondag 20 mei 2001 16:59 schreef dannydude het volgende:
Mooi hoor, ik ben geen vaudjes tegen gekomen...

Wordt hij ook OpenSRC, ik denk dat je er een boel mensen () een plezier mee zou doen.

Maybe, eerst maar es de code opschonen (1000 regels code voor een "simpele" ubb-parser is wat veel )
En dan verder zien dat ie nog wat flexibeler wordt.

[Apache]

bugje gevonden en gemaild

[ACM]

Op zondag 20 mei 2001 17:08 schreef Apache het volgende:
bugje gevonden en gemaild

En je hebt een reply
Bedankt

[brammetje]

heb je ook een terug-regex-script?

[ACM]

Op zondag 20 mei 2001 17:46 schreef PlayR het volgende:
heb je ook een terug-regex-script?

Komt nog
kan theoretisch met dezelfde code.

[wasigh]

zelfde test als vorige keer
(gewoon copy paste wat links staat)
andere fouten:

code:

Tag was: [/img], expected tag was:

-> closing all open tags, closing the
[/img] and then reopening all closed tags.
Next time, make a better post

Tag was: [/email], expected tag was: [/] ->
closing all open tags, closing the [/email]
and then reopening all closed tags. Next
time, make a better post


Parsing took: 0.0042599439620972
total procedure took: 0.01106595993042

reference took: 0.0023510456085205 [/code]

[ACM]

Probeer het nog es met "preparse" aangevinkt?

[wasigh]

dan krijg ik geen Error''s maar dit bij de uitvoer(aan het einde):

code:

[br] [img=blabla.jpg] [email=adress]
 [list=(A|a|I|i|1)]...[/list] [ulist]...
[/ulist] [li]...[/li] ... ... Beschikbare 
aliasen/alternatieven: [url]bla[/url] 
[list]...[/list] [*] [img]blabla.jpg[/img] 
[email]blabla[/email]

Of hoort dat??

[Verwijderd]

Op zondag 20 mei 2001 17:46 schreef PlayR het volgende:
heb je ook een terug-regex-script?

Wat mij een cleaner idee lijkt, is om gewoon een cache veldje aanmaken waar de geparsed''de text in staat, en het origineel onveranderd te laten. Nadeel is wel een grotere (bijna 2x zo grote) tabel:(

[ACM]

Als ik letterlijk de "beschikbare" tags erin plak doet ie gewoon wat ik wil hoor?
Je moet wel naar de "bovenste" helft kijken, ik zal de code van jaapf even uit zetten

[Verwijderd]

Op zondag 20 mei 2001 17:53 schreef wasigh het volgende:
dan krijg ik geen Error''s maar dit bij de uitvoer(aan het einde):

code:

[br] [img=blabla.jpg] [email=adress]
 [list=(A|a|I|i|1)]...[/list] [ulist]...
[/ulist] [li]...[/li] ... ... Beschikbare 
aliasen/alternatieven: [url]bla[/url] 
[list]...[/list] [*] [url=blabla.jpg][afbeelding][/url] 
[email]blabla[/email]

Of hoort dat??

Dat is het resultaat van mijn script (de reference):D Komt omdat mijn tags op een andere manier werken, of de desbetreffende tags niet geimplementeerd zijn in mijn script.

[ACM]

Op zondag 20 mei 2001 17:58 schreef Jaapf het volgende:
Dat is het resultaat van mijn script (de reference):D Komt omdat mijn tags op een andere manier werken, of de desbetreffende tags niet geimplementeerd zijn in mijn script.

Script van jaapf was een beetje in alpha status

Eventueel kan ik tomato''s script er wel naast zetten als je mijn code niet vertrouwend

[brammetje]

waar ga je het eigenlijk voor gebruiken?

[ACM]

Op zondag 20 mei 2001 21:52 schreef PlayR het volgende:
waar ga je het eigenlijk voor gebruiken?

Jaaaaaaaa

[Rense Klinkenberg]

Op zondag 20 mei 2001 21:52 schreef PlayR het volgende:
waar ga je het eigenlijk voor gebruiken?

Zal wel voor een nieuwsubmit scripje zijn

[ACM]

Op zondag 20 mei 2001 22:35 schreef freak007 het volgende:
Zal wel voor een nieuwsubmit scripje zijn

Och het heeft allerlei potentieel he?

[chem]

leg eens uit, HOE hij werkt? conceptueel gezien?

[ACM]

Op zondag 20 mei 2001 23:02 schreef chem het volgende:
leg eens uit, HOE hij werkt? conceptueel gezien?

Ach, vrij simpel.
Ik zoek een tag op, check of ie geldig is en duw hem op de stack, eind tags hetzelfde.
Daarna bouw ik de stack weer af met een andere loop en voer de bijbehorende functies op de tekst erbinnen uit, en plant er eventueel een tag(html oid) voor en achter.

[chem]

hoe werken stacks dan? nog nooit iets mee gedaan nl. ...

[mbravenboer]

Op zondag 20 mei 2001 23:19 schreef chem het volgende:
hoe werken stacks dan? nog nooit iets mee gedaan nl. ...

Droog je nooit af?

[brammetje]

Op zondag 20 mei 2001 23:21 schreef mbravenboer het volgende:
Droog je nooit af?

ik doe dat altijd met een handdoek, heb ik geen stacks voor nodig

[ACM]

Op zondag 20 mei 2001 23:27 schreef PlayR het volgende:
ik doe dat altijd met een handdoek, heb ik geen stacks voor nodig

Oftewel: hoe werkt een stapel borden.
Bij het afwassen leg je bijv. de borden op een stapel, de gene die ze afdroogt pakt de bovenste eraf en droogt die af (en gooit hem weg, want het voorbeeld is verder voorbij)

[chem]

owh

een array dus

[wasigh]

een stack is een lifo systeem:
last in first out

De variabelen(of objecten) die er het laatst op gezet worden, worden er weer het eerst vanaf gehaald. In tegenstelling tot Fifo (wat elke vakkenvuller kent )
Het heeft nogal vat voordelen dit stackbased te doen, Je hoeft namelijk geen foutgevoelige regex te bedenken.. En een tag toevoegen word ook makkelijker. (als het ontwerp goed is tenminste)

[bartvb]

Nope, geen array..

Bij een array kan je een willekeurig element accessen, verwijderen, veranderen. Bij een stack kan dat (normaalgesproken) niet. Daar gooi je dingen op en die haal je er (over het algemeen) in dezelfde volgorde weer van af..

Maar in PHP implementeer je het inderdaad als een array Stack klinkt alleen wat fancier

[chem]

nix mis met een hippe naam voor een oude truuk

nog nooit gehoord van enhanced reversed, double-flipped, triple-offscreenbuffered, bezier-curved anti-aliased met enorm l33t functies scripting?

(nee, ''t betekent nix )

[wasigh]

Het is niet alleen in andere naam, (in de meeste talen dan)

Maar een andere structuur. Het is voor gemaakt om zo efficient mogelijk te werken voor "stack-doeleinden" recursie etc

Terwijl Array, meer voor andere doeleinden bedoeld zijn. 2X2 matrixen etc.
Het is dus meer als een naampje

[mbravenboer]

Trouwens wellicht leuk om te weten dat je code ook op een stack wordt uitgevoerd .

Jaja, dat geeft afdrogen weer een hele andere dimensie! .

[wasigh]

Op zondag 20 mei 2001 23:50 schreef mbravenboer het volgende:
Trouwens wellicht leuk om te weten dat je code ook op een stack wordt uitgevoerd .

Jaja, dat geeft afdrogen weer een hele andere dimensie! .

Er zijn toch ook processors die zonder stack werken? Of ben ik ech aan slaap toe?

[bartvb]

Die zijn er vast wel, maar dat zijn zeker geen gangbare

Stacks zijn best wel errug belangrijk bij de ''normale'' architecturen. Vooral bij context switches en interrupts. Alles in de registers wordt dan op de stack geperst en er na de interrupt weer vanaf getrokken.

Maar moet zeggen dat ik behoorlijk onder de indruk was van de snelheid van ACM''s progsel. Ben erg benieuwd hoe het er nou uit ziet

[ACM]

Op maandag 21 mei 2001 00:00 schreef bartvb het volgende:
Maar moet zeggen dat ik behoorlijk onder de indruk was van de snelheid van ACM''s progsel. Ben erg benieuwd hoe het er nou uit ziet

Mwoh, hij''s met grote hoeveelheden tekst ~10keer trager dan een regexp variant (die niet zulke goede code uitpoept )

[bartvb]

Indeed, laatste keer dat ik gekeken had deed die regexp variant (die 10x sneller was) ook 10x minder

[dusty]

ACM weer wat vrolijker gemaakt, dat wordt weer een paar uur extra programmeren voor hem

[ACM]

Toch bedankt dusty

[RobzQ]

Niet echt een een bug maar ik zie een spatie in de <br /> tag.

[ACM]

Op woensdag 23 mei 2001 00:58 schreef RobzQ het volgende:
Niet echt een een bug maar ik zie een spatie in de <br /> tag.

Helemaal geen bug.
De code is namelijk zoveel mogelijk XHTML compliant en die vereist dat.

[Steven]

Op woensdag 23 mei 2001 01:02 schreef ACM het volgende:

[..]

Helemaal geen bug.
De code is namelijk zoveel mogelijk XHTML compliant en die vereist dat.

Hert heeft ook zijn nadelen om in HTML te kunnen posten

[ACM]

Ik kan helemaal niet in html posten hoor?

Maar er is inderdaad een vaag bugje in mijn parser die dat in een enkel geval toelaat

[RobzQ]

Op woensdag 23 mei 2001 01:02 schreef ACM het volgende:

[..]

Helemaal geen bug.
De code is namelijk zoveel mogelijk XHTML compliant en die vereist dat.

Ok, weer wat geleerd vandaag

[Verwijderd]

Op zondag 20 mei 2001 23:43 schreef bartvb het volgende:
Nope, geen array..

Bij een array kan je een willekeurig element accessen, verwijderen, veranderen. Bij een stack kan dat (normaalgesproken) niet. Daar gooi je dingen op en die haal je er (over het algemeen) in dezelfde volgorde weer van af..

Maar in PHP implementeer je het inderdaad als een array Stack klinkt alleen wat fancier

Als je er een object van maakt met access methods, en de array private maakt heb je een echte stack.

[ACM]

Op woensdag 23 mei 2001 17:00 schreef joska het volgende:
Als je er een object van maakt met access methods, en de array private maakt heb je een echte stack.

Ga jij nou maar een foto opsnorren

Dat is verder niet relevant, mijn code gebruikt er ook een array voor, maar dan wel met de array_pop en array_push methoden.

[Verwijderd]

Op woensdag 23 mei 2001 01:02 schreef ACM het volgende:

[..]

Helemaal geen bug.
De code is namelijk zoveel mogelijk XHTML compliant en die vereist dat.

XHTML vereist dat helemaal niet. Het is alleen een veelgebruikte truc om XHTML enigzins in NS4.* te laten werken.

[ACM]

Ok anders en minder kort gezegd.
XHTML vereist de afsluiting van _elke_ tag.
Dus ook de <br> om nou niet elke keer
</br> te moeten plaatsen mag je dat dus ook met <br/> doen.
En zoals jaapf zegt, ns4 werkt daar niet zo lekker mee, dus mag je ook <br /> gebruiken.

edit:
Wel leuk als je niet (door het bestuur) wordt verteld dat je htmlrechten hebt

[brammetje]

Op woensdag 23 mei 2001 18:37 schreef ACM het volgende:
Ok anders en minder kort gezegd.
XHTML vereist de afsluiting van _elke_ tag.
Dus ook de
om nou niet elke keer
</br> te moeten plaatsen mag je dat dus ook met <br/> doen.
En zoals jaapf zegt, ns4 werkt daar niet zo lekker mee, dus mag je ook <br /> gebruiken.

of je onthoudt gewoon dat je (x)html gewoon wordt behouden, en niet word omgezet.

[ACM]

Op woensdag 23 mei 2001 18:50 schreef PlayR het volgende:
of je onthoudt gewoon dat je (x)html gewoon wordt behouden, en niet word omgezet.

Duidelijker zo?