Comments parsen

[xilent_xage]

Hoi,

Ik weet dat comments nujuist bedoeld zijn om NIET te parsen. Maar voor mijn debugger lijkt het me relaxed als comments dus worden gebruikt om debuglogs te maken. Voorbeeld:

code:

#dit is een comment
print_r($array());

Ik zou willen dat tijdens het parsen van deze code de comment wordt gebruikt om een functie aan te roepen a la $_debugger->add_debuglog("dit is een comment"); Op die manier hoef ik nl geen aparte logs meer aan te maken en worden alle comments gewoon automatisch in mijn debugger getoond.

Kan dat?

[Verwijderd]

De enige manier om dat te doen lijkt me de source doorzoeken via regex, op zoek naar comments en die dan loggen. Lijkt me geen nette oplossing, waarom niet direct de functie aanroepen in plaats van in comment zetten en daarna alsnog die functie aanroepen?

[xilent_xage]

Ja, ik had zelfs al bedacht om comments maar te schrappen en alleen debuglogs te gebruiken, en dan te proberen dat mijn editor deze debuglogs als comments weergeeft. Maar dan moet ik 15mb aan code gaan herschrijven

[Verwijderd]

xilent_xage schreef op donderdag 25 juni 2009 @ 19:22:
Ja, ik had zelfs al bedacht om comments maar te schrappen en alleen debuglogs te gebruiken, en dan te proberen dat mijn editor deze debuglogs als comments weergeeft. Maar dan moet ik 15mb aan code gaan herschrijven

15mb aan code? Dan had je voordat je aan dat mega-project begon na moeten denken dat het wel eens handig zou zijn om te loggen.

Maar het is een afweging die je moet maken: eenmalig de code zelf doorlopen om de comments te vervangen door een functie die het logt, of dit telkens bij het runnen automatisch te laten doen. Ik verwacht dat bij de tweede optie de performance beduidend lager zal zijn.

Het doorlopen van 15mb code hoeft nieteens hele handmatig trouwens, met bijvoorbeeld Zend Studio kan je Regex replaces doen, zo kan je (als de comments zo zijn als in je voorbeeld) alle comments per file in 1x doorlopen en vervangen door de functie.

[ Voor 14% gewijzigd door Verwijderd op 25-06-2009 19:28 ]

[Grijze Vos]

Wat je kunt doen is wat code generatie toepassen. Een inline-code expander zou dit werk prima kunnen doen. Wat je dan doet is je code preprocessen door alle comments te vervangen voor debugger calls. Je originele code bewaar je, en de gegenereerde code voer je uit.

Als je dan zorgt dat je generator voor elke regel comments een regel debugger genereert, verneuk je ook niet je line numbers i.v.m. debuggen.

[Trucker Her]

Jah, en 15mb aan code dat is beetje overdreven denk ik. 1 teken is 1 byte dus 15mb = 15*1000*1000 = 15000000 tekens. Lijkt me sterk. En anders is het wel een heel groot script en zoals GuidoH al zei voordat je aan zo'n groot project begint (15000000 tekens..!) ff over nadenken!

[Verwijderd]

inderdaad, mijn grootste project (ong 100 uur) is 150 KB...
het is wel asm, maar toch

edit: @ hieronder, Asm, ja...

[ Voor 34% gewijzigd door Verwijderd op 25-06-2009 20:15 ]

[Trucker Her]

Asm?

[Verwijderd]

offtopic:
Mijn grootste zit wel tegen de MB aan, daar zit zo'n 300 uur in gok ik. Nu weer verder ontopic?

[xilent_xage]

offtopic:
15 Mb is inderdaad veel, heeft me ook 2 jaar gekost En tja, natuurlijk probeer je alles zo goed mogelijk van tevoren te onderzoeken / voorzien. Maar zeker bij zo'n groot project kom je eigenlijk altijd wel tijdens het verloop tot nieuwe inzichten. Het betreft hier mijn framework + CMS, en nee het is niet vreselijk slordig geprogrammeerd / retetraag / overdreven groot. Wel overdreven veel mogelijkheden, maar das een keuze

Wat ik nog was vergeten te vermelden: Ik wil mijn debugger ook graag gebruiken voor andermans code waar ik in werk. Daarom zie ik vooral een charme in het parsen van de comments: dan werkt je debugger gelijk op vrijwel elke lap code die je em voert.

Als ik het goed heb begrepen zou de code pre-processen voor mij dan een de minst slechte optie zijn, maar lijkt me wel dat dit zn performance-kosten meebrengt...

Is het niet mogelijk om in PHP aan te geven met welke tekens comments worden aangegeven? Dan zou je dat kunnen veranderen, an een functie #() maken

[Voutloos]

xilent_xage schreef op donderdag 25 juni 2009 @ 21:19:
Als ik het goed heb begrepen zou de code pre-processen voor mij dan een de minst slechte optie zijn, maar lijkt me wel dat dit zn performance-kosten meebrengt...

Deze manier van loggen ga je toch niet in productie gebruiken.
Toch?

Overigens kan ik mij het nut totaal niet voorstellen. Met het loggen van duizenden statische (!) teksten ga je echt niet veel beter begrijpen wat er gebeurd. Als je dit nu wil wegens een gericht probleem, moet je ook gewoon een gerichte tool er tegenaan gooien. Bijv.: als je nu een performance probleem hebt, en je weet niet waar het in zit, kijk dan naar een profiler ipv een compleet arbitraire logging van doc comments. Arbitrair, want wat doe je met comments buiten functies, of comments die voor een conditie staan welk naar false evalueert etc. etc.

Imo echt totaal nutteloos en een complete waste of time. Zo niet: overtuig me maar waarom dit echt dé oplossing voor je probleem is.

[ Voor 49% gewijzigd door Voutloos op 25-06-2009 21:32 ]

[xilent_xage]

Hangt af van de implementatie. In mijn huidige framework kun je de debugger aanzetten via een GET variabele (mits wel ingelogd in het CMS en een bekend IP). Als die get-variabele niet is opgegeven wordt de debugger niet gestart. Dus de debugger is als het ware latent aanwezig op de productiesites, maar inactief tenzij ik aan het debuggen ben. Want ja, in de praktijk moet dat soms ook op de productiesites.

Een onderdeel van mijn debugger is een profiler, die de gebruikte tijd bijhoudt en logt zodat ook historische debugdata beschikbaar is. Zo kun je zien of een onderdeel van de code na verloop van tijd sneller is geworden, of in een bepaalde tijd problemen heeft gegeven. Ik vermoed dat een preprocessor alle code ongeveer evenredig langzamer maakt (dat zou dus geen probleem zijn), maar dat weet ik niet helemaal zeker. Als zo'n preprocessor echt traag is zullen snelle segmenten relatief zwaar benadeeld worden. Vandaar mijn vraag over de vermoede performancekosten.

[xilent_xage]

Vwb de duizenden comments: Mijn debugger werkt met hierarchie, waardoor je gericht kunt zoeken binnen je code. Daarnaast is het natuurlijk ook niet zo dat de complete 15mb voor elke request wordt aangeroepen natuurlijk

[ Voor 16% gewijzigd door xilent_xage op 25-06-2009 21:50 ]

[hostname]

Probeer je nu niet xdebug zelf te implementeren?

[xilent_xage]

hostname schreef op donderdag 25 juni 2009 @ 21:44:
Probeer je nu niet xdebug zelf te implementeren?

ik hoop het niet? geen ervaring met xdebug, maar als ik hun manual zo even snel scan werkt dat toch net even anders. Geloof ook niet dat xdebug de comments parsed, maar ik kan ernaast zitten (geen tijd om de hele manual te lezen

[Confusion]

xilent_xage schreef op donderdag 25 juni 2009 @ 19:12:
Ik weet dat comments nujuist bedoeld zijn om NIET te parsen.

Comments worden toch ook geparsed: dat is de fase waarin bepaald wordt dat iets een comment is? De volgende vraag is of ze in de parse tree gestopt worden of niet. Zonee, dan moet je sowieso een aanpassing aan de parser zien te doen om te zorgen dat ze erin blijven zitten.

Kan dat?

Een debugger ziet normaalgesproken alleen de output van de interpreter lijkt me; anders ben je het interpreteren zelf aan het debuggen en niet de code die de interpreter gegenereerd heeft. Als je wilt dat de interpreter op basis van een comment actie onderneemt, dan moet je de interpreter zelf aan zien te passen. (Geen idee hoe de PHP interpreter te werk gaat: in theorie zou je natuurlijk tijdens het interpreteren al de commando's kunnen gaan uitvoeren, maar wordt het geheel niet eerst in een tussenvorm omgezet die daarna pas uitgevoerd wordt?)

Met een preprocessor comments in log statements omzetten is natuurlijk altijd mogelijk, maar vertraagt je script met de tijd die het preprocessen kost.

[ Voor 11% gewijzigd door Confusion op 25-06-2009 21:57 ]

[Voutloos]

xilent_xage schreef op donderdag 25 juni 2009 @ 21:54:
[...]
ik hoop het niet? geen ervaring met xdebug, maar als ik hun manual zo even snel scan werkt dat toch net even anders. Geloof ook niet dat xdebug de comments parsed, maar ik kan ernaast zitten (geen tijd om de hele manual te lezen

Ga toch maar lezen dan, dan ontdek je wat er allemaal al mogelijk is zonder zelf het wiel opnieuw uit te vinden. Comments loggen is idd niet mogelijk verklap ik al vast, maar zie eerder sceptische opmerking.

[xilent_xage]

Voutloos schreef op donderdag 25 juni 2009 @ 22:04:
[...]
maar zie eerder sceptische opmerking.

Dacht dat ik die gepareerd had toch ? Zie screenshot... op die manier is een flinke lap debuginfo prima te beheren / gebruiken. En als je punt is dat ik in plaats van mijn eigen debugger beter xdebug had kunnen gebruiken... misschien waarschijnlijk heb je gelijk. Maargoed, ik heb nu mn eigen speeltje gebouwd, dat was ook heel leuk en leerzaam. En... ik heb em precies zoals ik dat wil!

Misschien ben ik wel de enige die dit makkelijk vind, maar ik ben zelf erg happy met mn debugger, nogmaals zie screenshot. Ideaal toch?

[ Voor 13% gewijzigd door xilent_xage op 25-06-2009 22:11 ]

[Voutloos]

Ik zie een best leuke tool in het screenshot, wat wellicht ook leerzaam geweest is. Maar, tov het inzetten van standaard beschikbare tools is het - afgezien van het leeraspect - een behoorlijke berg weggegooide tijd.

Binnen 3 minuten kan je met xdebug + webgrind hetzelfde bereiken. En door een uurtje te besteden aan een andere, krachtiger *grind programma ga je aan al je profiling needs voldoen.

[hostname]

xilent_xage schreef op donderdag 25 juni 2009 @ 21:54:
[...]


ik hoop het niet? geen ervaring met xdebug, maar als ik hun manual zo even snel scan werkt dat toch net even anders. Geloof ook niet dat xdebug de comments parsed, maar ik kan ernaast zitten (geen tijd om de hele manual te lezen

In ieder geval het hele profile gedeelte is zo ongeveer hetzelfde (minder uitgebreid; maar daardoor duidelijker ) als van xdebug.

Debuggen met xdebug kan ook step-by-step, dus dan heb je je code er zelfs naast (en je comments dus ook).

[xilent_xage]

Als ik me niet vergis gebruik je bij xdebug een applicatie? In dat geval wil ik nog als voordeel aanhalen dat mijn debugger geheel webbased is, hij geeft boven elke pagina een toolbar weer met erin het aantal errors / queries / cache hits/misses / parsetijd (van alle requests samen!) en externe verbindingen. Onder de pagina verschijnt dus bovenstaand screenshots met alle aangeroepen files onder mekaar (dus ook js/css/images), die parse ik ook met php...



Maargoed ik besef ook wel dat t een beetje vechten tegen de bierkaai is, ik kan in mn eentje nooit maken wat zo'n community neerzet...

Ik denk dat ik het voorlopig maar bij het oude laat, als ik het goed heb begrepen zijn mn ideeen gewoon niet eenvoudig uitvoerbaar. Bedankt voor de feedback en het meedenken!

[steffex]

xilent_xage schreef op donderdag 25 juni 2009 @ 23:58:
...Onder de pagina verschijnt dus bovenstaand screenshots met alle aangeroepen files onder mekaar (dus ook js/css/images), die parse ik ook met php...

waarom zou je dit dan in hemelsnaam willen? onnodig informatie door je php parser heenhalen, is alleen maar performance loss...

misschien kun je ook eens kijken naar de firefox plugin firebug en de daar bovenop beschikbare firephp (http://www.firephp.org/)