Wedge

Go tell that to the SMF team...
I myself spend most of my time working on Wedge. A small flame war from time to time is not a problem-- I deal with them during my breaks anyway. But marketing, I can't do alone.

Shakespeare, decent writing? "Wherefore art thou my Romeo"? It's not even proper English!!!! :niark:

A theater production? Ah, they should do it as a redubbing of the movie... That would be fun, too.

Re: parse_bbc performance.

- Maybe we should use the opportunity of a full import to do some sanitizing work on posts that weren't sanitized in the first place (e.g. posed through a non-complying mod, things like that.) That way, we could remove some of the legacy code from parse_bbc. Hopefully.

- For those who aren't in the private area and can't follow my little adventures... One of the features I added was a complex block replacement system that supports optional params. I'd crafted this beautiful regular expression that worked great. Then it crashed a few pages, so I rewrote it for performance (with inspiration from my 'goddess of all regex'[1] and that really odd atomic grouping thing). It became extremely reactive and I couldn't get to crash it anywhere. Was satisfied with it. Only, I wasn't sure it wouldn't crash anywhere else (although my experience with the 'goddess' tends to confirm that it wouldn't...), and I was curious about something: performance of a complex but very optimized regex, against the use of pure non-regex PHP. So I started working on a small function that would do the same work as the regex.

Quite surprisingly, it only took me 20 minutes to get it working, it only took a few lines of code, and it was fucking fast. The final version is about 10% faster than the regex version, and the more blocks you replace, the faster it gets -- once you reach 300 blocks, it becomes a strain on Wedge in the regex version while the pure PHP version still keeps flying (about 5 times faster.)

This is only mean to explain that I used to think regexes were the ultimate solution for complex performance-aware searches/replacements. I'm not so sure about that anymore. Actually, I'm starting to wonder if I'm not going to turn this pure PHP version into a regular multi-purpose function with associated callbacks, that will happily handle any kinds of tags, be it HTML, BBC or Wedge block tags (<we:block>). Maybe then, we can start doing tests in parse_bbc and see if it can be done faster.

One of the things we should sanitize in posts is tag cases. I mean, I don't see why we should accept [Html] tags when it should be 'html', in lowercase. Case insensitivity is one of the things that regular expressions are great at, as Pete can confirm. My pure PHP version is case sensitive. Had I added support for case insensitivity (and I did at some point), it would have been twice slower. Which is okay when you have 300 blocks to deal with (it's still 2.5x faster than the regex version), but it becomes 80% slower than the regex version when using only a dozen blocks.

So... These are a few of the solutions I could offer to try.

1.

This is a special regular expression I wrote for Aeva Lite back in 2008. It fixed a crash bug that had plagued AEVAC for months, and that pretty much drove Karl Benson to give up on the mod. As far as I can remember, getting that regex to work was a defining moment for me -- that's when I accepted the idea that I had become capable of handling SMF mods.

Pete opened Pandora's box in the first place... Anyone posted over there is a spammer anyway. :niark:

Why? We aren't certain Smf or Wedge are safe either ;)

Hey.  Funny quote from mister "gpl is god, fuck you if you plan to sell a non-gpl plugin!"

Matt Mullenweg, wrote. “We presume our source code was exposed and copied. While much of our code is open source, there are sensitive bits of our and our partner's code.