You are not logged in.
- Topics: Active | Unanswered
#26 Re: Announcements » Discussion on 1.4 » 2009-07-12 22:44:45
- elbekko
That was an excellent read, thanks for that! I'll see about implementing and testing it tomorrow.
#27 Re: Announcements » Discussion on 1.4 » 2009-07-12 13:09:59
- elbekko
In that spirit, I'll be offering some positive contributions shortly...
Great, that's the way I like it ![]()
#28 Re: Announcements » Discussion on 1.4 » 2009-07-11 15:00:15
- elbekko
elbekko wrote:... I'd like to bring part of this discussion to the community. ...
And yet when they respond, you simply disregard their opinion because they obviously don't know what they are talking about! I may be new to the Pun/Flux development community, but I am certainly not new to programming. I've been working as a software engineer since 1981 and have a LOT of experience that you might just want to cultivate - including expertise in regular expressions which (from looking at the code), you guys could use some help with. As I said before, the first 2 (non-trivial) regexs I looked at in detail in the 1.3 parser have errors. I found no such errors in the 1.2 code (of the ones I looked at - but those aren't perfect either).
But it sounds like you have already made up your minds.
Feel free to post improvements then, instead of just saying "no, this can't possbily be good."
As for personally attacking me, I really don't give a damn, but it doesn't really make your opinion any more valid (quite the opposite, in fact).
#29 Re: Announcements » Discussion on 1.4 » 2009-07-11 12:48:27
- elbekko
I vote no.
For starters its feature creep and you promised this would not happen. And besides, the 1.2 parser code is smaller, cleaner and much more readable than 1.3, particularly with regard to the implementation of regular expressions (e.g. Just take a look at the preparse_bbcode() function for comparison). The few regexes that I took a close look at in the 1.3 parser were poorly written at best. (This is one of the main reasons I abandoned using 1.3). Note that the 1.3 parser has twice the bloat (28KB vs 14KB) and yet is poorly commented.
The 1.2 code is superior IMHO. Its not broken, don't fix it!
Yet it isn't. For 1.3 we worked on making the parser faster, as it was the biggest slowdown in the whole code. We're now porting it to 1.4 (which is nearly done) to provide this speed boost. What you think of the code and what it actually is are very different things obviously.
And I'd hardly call it feature creep if you're replacing instead of adding.
#30 Re: Core development » 2.0 Ideas » 2009-07-09 12:52:39
- elbekko
I like the idea of modularity, but it brings a host of problems just like the extension system ![]()
#31 Re: Core development » 1.4 beta 2 » 2009-07-06 00:08:47
- elbekko
Making it just display the error rather than trying to fix that error should fix it.
#32 Re: Core development » Code tags in code tags » 2009-07-04 13:42:21
- elbekko
I'm pretty sure that will be the case when we put the 1.3 parser in 1.4 ![]()
#33 Re: Announcements » Discussion on 1.4 » 2009-07-04 13:41:08
- elbekko
Yes, but as FSX said, there is also a slight issue with paragraphs that needs to be fixed. Still, the style changes would be very minor, and could probably be put in base.css so custom styles don't break.
#34 Re: Core development » 1.4 beta 2 » 2009-07-01 12:59:24
- elbekko
The whole subscription thing does feel like a bit of feature creep to be honest, and would be much better suited for a modification for now.
#35 Re: Announcements » Discussion on 1.4 » 2009-07-01 12:54:23
- elbekko
@Mpok:
Well, I don't see how a toolbar mod would break due to the inner workings of the parser changing. The BBCode won't change or anything, just how it is handled. Putting in the new parser is basically plug and play, and Paul has the code done already for a personal project.
Now, I can take a look at PunToolbar for you, but I have a feeling it won't break a thing. If it does, it's probably made in the wrong way ![]()
@sirena:
I wouldn't call it feature creep, it's just a few thoughts we want the opinion of the community on
As I said, it should be basically plug and play, so no code other than the parser would change.
#36 Announcements » Discussion on 1.4 » 2009-06-30 17:38:29
- elbekko
- Replies: 44
Right, since the next 1.4 release just might be close, us developers have been discussing a thing or two, and I'd like to bring part of this discussion to the community.
First up is the parser. We've been toying with the idea of implementing 1.3's parser in 1.4. It's cleaner, faster, and just overall better. The downside to this is that some minor style changes will need to be made, which may break user styles.
We'd really like your input on this ![]()
#37 Re: Core development » Question: 1.3 parser for 1.4 » 2009-06-29 17:47:51
- elbekko
And here I thought the parser was already in 1.4. If it isn't, I think it's important enough to port it and break a bit of backwards compatibility (won't break much).
#38 Re: Programming » Database update question » 2009-06-29 11:58:19
- elbekko
Well, the general consesus is usually 'let the database handle it', especially for constraints etc.
I'd go for the second case, you can always see if any rows were affected, so that isn't a reason to not do it this way either.
#39 Re: Feature requests » Can you move o_base_url to config.php » 2009-06-29 11:54:00
- elbekko
For 1.3 we moved it, but that obviously won't happen for compatibility purposes in 1.4.
#40 Re: General discussion » Smartys Rules! » 2009-06-28 19:34:37
- elbekko

Obviously.
#41 Re: General discussion » Firefox 3.5 » 2009-06-28 19:32:43
- elbekko
Waiting for the final, I just hope my extensions don't break.
#42 Re: Core development » Site update again » 2009-06-27 00:24:34
- elbekko
That is very, very nice.
#43 Re: General discussion » IE8 » 2009-06-26 19:52:24
- elbekko
Interestingly I just viewed a page I'm working on in Compatability mode then in IE7 mode using the developer tools. The rendering was different. It looked fine in compatability mode but in IE7 mode it required the usual "has layout" fix to work. In theory that means compatability mode is a waste of space for testing purposes because the page could still look wrong in IE7.
Did you try setting the browser mode to IE7 in the Developer Tools?
#44 Re: General discussion » IE8 » 2009-06-26 17:49:50
- elbekko
Compatibility mode = IE7 mode (or worse).
So yes.
#45 Re: Core development » 1.4 beta 2 » 2009-06-21 13:47:10
- elbekko
1.4 will replace 1.2, easy as that. I don't think there's any benefit in keeping 1.2 supported, apart from perhaps helping to port/rewrite popular mods for 1.2 to 1.4.
#46 Re: Feature requests » Facebook Connect plugin request » 2009-06-20 11:40:22
- elbekko
And what exactly would this do?
#47 Core development » 1.4 beta 2 » 2009-06-18 17:24:58
- elbekko
- Replies: 35
Anyone got any suggestions for stuff that needs to be done still?
I've had a thought that I think could be rather handy: a script that consolidates all CSS files, minifies them and caches them in the style folder as <stylename>_min.css, while keeping the original CSS files for editing. This would reduce the number of requests and decrease output file size. It would be a rather minor change to 1.4 that doesn't break anything. There's the Minify project, already in PHP, that could probably be adapted to work with PHP4.
#48 Re: Feature requests » CSS: rearrangement and resize (was "Common style parts") » 2009-06-18 07:33:33
- elbekko
What? I don't see how adding a file would be in any way beneficial.
If anything, I'd rather put it all together so not so many files need to be requested.
#49 Re: General discussion » Back... » 2009-06-13 11:37:51
- elbekko
Awesome, good to have you back ![]()
#50 Re: Feature requests » Improved subscription » 2009-06-11 10:10:13
- elbekko
What is this doing in Feature requests?
What version do you want to do this in?
