s> First off, I'm no Perl expert so I didn't judge his code in that.
s> I have used it with sucess at work and its not bad for me.
s> I had to add to his handler setup and a couple of other things.
s> Overall though the core parse doesen't show conceptual errors,
s> but is'nt compatible sometimes for old html.
s> You mention dislike for "else" clause, especial when nesting and
s> only have 25 of in 10k code lines. If one can avoid an else with a
s> return in the conditional block (or continue) it should be done, no
s> question. But you may want to re-think if it is believed that
s> nested code is being touched every time. No matter how constructs
s> tabularized through indirection (compiled) the end result is
s> machine jump code being executed. Wether its relative (conditional)
s> or absolute jump. Your code paths are absent of jumps? Conditional
s> jumps are the fastest instruction per effectiveness a cpu can do.
you are very lost here. machine code and perl execution of conditionals
have ABSOLUTELY nothing in common. the layers separating perl from
machine code are deep and nasty. you obviously don't know about how
interpreters are written. please stop this illogical line you seem to
think matters. the key bottleneck in perl is the op code dispatch loop
and not any particular machine instruction. you don't see to realize how
loops/branches are done in perl and that they are about the same speed
as most builtin simple ops. the machine jumps are not even on the radar
at that level. please study some interpreter designs and learn about
them. this machine language babble of your is so off the mark it is not
funny.
s> I don't know of Perl "op" loops you talk about. I would have to
s> imagine them being the translation table into an execution
s> processor (interpreter) creating code pages for the processor. That
s> again produces a binary based on the "op" codes of the underlying
s> processor, when executed. To me, an "op code", from back in my
s> dissasembly days, is the character translation of the assembly
s> major "operation" into its binary code from the table.
no no no no. since you don't know about perl's guts why do you insist on
talking about them at a machine level? the machine is several levels
down from perl's source and you could never tell what machine code is
being execute for any perl op. and as i keep telling you perl ops are
way larger in cpu usage than ant single machine instruction. your
assembler background is useless in understanding perl optimization.
s> Perl provides a C like language construct. I hope its a close
s> proximity in its constructs in performance, otherwise it should not
s> be.
it has no closeness to the metal at all. you don't understand
interpreter design at all. except for a few special cases which do some
JIT code generation, none generate any machine code directly. and even
those that do are not at the same level as hand written c.
s> Finally, Perl can't do pointers that I know of. Pointers offer more
s> granularity in code design when it comes to parsers, for instance, xml
s> is highly controlled by escape codes, albeit ascii ones. If one could
s> write code on that level, jump if >,!=,<,== based on the result in the
s> accumulator, the its the fastest possible. But a string comparison is
s> really out of the question.
again, you don't know what you are talking about. perl has references
and can do most anything with them that c could except for pointer math
and that perl's references are safer and can't cause core dumps. i will
take refs over pointers any day.
s> Appaently in C, you can parse xml/html, using a more granular approach
s> with pointers and bit-mapped state variables, as it pertains to control
s> characters. This however is not possible in Perl. As well I don't see
s> pointer arithmatic being available.
huh??? you are making no sense. there are many ways to parse
anything. the issue is that robic's parser is BAD and BUGGY perl. it may
work for your special cases but in the general sense it is broken in
many ways. it could be optimized in many ways, cleaned up, whatever but
it is crappy code. you are probably the only user of it besides its
psychotic author. just wait until you try to communicate with him for a
bug fix or improvement
s> To me this guy looks like did ok. You could probably make his code
s> more efficient. Sounds like alot of folks here don't like him much
your approval means little. you have not shown any understanding of good
perl code, perl optimization, interpreter design, parser design,
etc. this means you are not experienced enough to properly give a
professional opinion on that module. as for people not liking him,
please google for his past posting and you will see why. as for his
code, i am not the only one who thinks it is crap. you are the only one
who likes it. think about that.
uri
arser to strip HTML tags from my files. I noticed