Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
10321
Features / Re: New revs
« on September 6th, 2010, 04:27 PM »
Quote from Arantor on September 6th, 2010, 03:30 PM
*nods*

* Arantor hands Nao the axe to finish chopping the multi DB code out.
rev 53
- Removed more of the multi-database code. (install.php, Settings.php, Settings_bak.php, create_backup.php, repair.php, repair_settings.php, restore_backup.php, smf_api.php, upgrade.php)
! Typo in repair.php, 'smc_compat_dtabase' (this should also be backported to SMF2.) (repair.php)
! Re-introducing SMF rev 9976's fix of the backup system when some tables have fields using reserved names. (DbExtra-mysql.php)

I'm not completely finished but nearly so... I should change $databases['mysql'] to just $database, but I'm a bit tired of constantly proof-reading my own code.
Quote
Point of interest: vBulletin only supports MySQL,
'course.
"We only do evil, but we're good at it." :eheheh:
Quote
Yeah, FIND_IN_SET is ridiculous, and doubly so since in PGSQL's case it doesn't exist at all, and has to be shoe-horned in as a user function (at a performance penalty, too), which returns T or F (or t or f sometimes), so you end up having to rewrite every instance of FIND_IN_SET in queries. I mean, seriously... who does it like that?
I actually like FIND_IN_SET... :lol:
But keeping it in place when trying to support other database systems would be silly, indeed.
10322
Features / Re: New revs
« on September 6th, 2010, 03:23 PM »
I need to find another solution for the CRLF stuff.
First, I should try if converting my diff files to LF will preserve LF on the target files at patching time. I may have to add --binary to the patch call though. And I don't know if it won't generate other issues.
Too bad setting up Subversion to use LF didn't help a bit.
Quote from Arantor on September 6th, 2010, 03:11 PM
Part of me would like to keep it, but there's no reason it should stay unless we're seriously planning on providing the ability to deal with it later, which I doubt.
Here's the thing: I'm no good at PG and SQLite. Really, no good. I don't know a thing. It took me twice longer to write the Ignore Topic mod because I had to add support for PG and SQ. I thought it sucked. Now, the thing is, the more I spend time on crap like that, the less I can spend time on more interesting features. MySQL has at least a 90% marketshare in forum software, so I don't care about the remaining 10%. I'm not here to eat market shares, I'm here to team up with you and have fun making the best possible forum software for MySQL and PHP5. I'll leave market share issues to SMF.
Another thing is -- if someone adds support for a new DB system, then we'll feel compelled to help with it. And then we'll end up having to support it. And then we'll figure, okay let's put back support for PG and SQLite, since it was already there to begin with, we can simply revert some stuff...
And we'll be back to square one.

I really, really would vote for removal of what is left of the multiple database code. (Not a priority, though, but if it can save time generating a SMF page, then I want it.)
Quote
Most of the hacks for PGSQL are because SMF uses this banal system of comma-separated values in a string column. It may have made sense long ago but in the current day and age, it's not viable.
You mean, things like FIND_IN_SET?
Quote
Don't even get me started on trying to hack in MSSQL support, I actually gave that up as a lost cause in the current environment. (Seriously, how stupid is it not to support LIMIT x, y as a clause? You can have the TOP x rows, but can't page through like that.)
Oh, you gotta love Microsoft... :)
10323
Features / Re: New revs
« on September 6th, 2010, 03:05 PM »
Yeah, the problem with other databases is that they're not plug & play when it comes to replacing MySQL functionality... Even the current state of SMF2 is a series of hacks designed to add support for PG and SQLite, but it doesn't help much. I'm sure that if the core team wanted to add support for some other DB at this point, they would have to hack into new areas as well because they found out there's an incompatibility here and there...
It's quite pointless to me. SMF started as MySQL and MySQL is still the de facto database system on the Interneds.
(I'm not removing extra support code unless you want it too, though.)

rev 52
* Updated to SMF rev 10095. Also fixed line endings, hopefully for the last time...
  ! Fixed avatars resized with javascript (script.js)
  * Tweaked the attachments cleaning to allow single file removals (script.js, Post template) [Bug 3559]
  & Tweaked the language string accordingly (Post english)
  ! Chose a hopefully more portable fix for cleaning file input (script.js) [Bug 3780]

--------> rev 10096 and 10097 are about fixing LF endings... Unfortunately, I just tried, and svn diff still generates a CRLF file, and patch still generates a CRLF file as well. So... I don't know.
10324
Features / Re: New revs
« on September 6th, 2010, 02:10 PM »
@Dismal> Actually, since last Thursday, Norv committed about 23 times, and some of Wedge's commits (many of mine, actually) aren't really feature additions, rather feature removals, which are easier to do... Such as this one:

rev 51
- Removed smflib folder (not used in SMF2, not likely to be used in Wedge.)
- Removed compatibility code for array_combine, array_fill, sha1, file_put_contents, ob_clean, ob_get_level (although this one isn't really needed.) (create_backup.php, repair.php, restore_backup.php, smf_api.php, webinstall.php, Display.php, DumpDatabase.php)
- Removed rawdata templating (leftover from SMF 1.0 days.) (ManageMaintenance.php, ManageServer.php, RepairBoards.php, Subs.php)
10325
Features / Re: New revs
« on September 6th, 2010, 12:25 PM »
rev 49
* SMF2 changelog, back to LF endings... (yawn) (changelog.txt)
* More PHP5 optimization. Ain't done yet. (phpBB3_Login_Fix.xml, install.php, Display.php, Load.php)
- complex_preg_chars trigger (PHP 4.3.3+) is no longer needed. (Class-Editor.php, Load.php, Register.php, Search.php, Subs-Members.php, Subs-Post.php, Subs.php)
Posted: September 6th, 2010, 10:31 AM
Quote from Arantor on September 6th, 2010, 12:48 AM
I'd kind of like to keep the code in there in case we ever want to support something alongside MySQL (i.e. community support),
Community support?
Quote
but really, the way it's all engineered generally, the entire query system would need rewriting to support proper query building.

In which case... you know where the delete button is, hehe :D
Is it the red one or the blue one?
Posted: September 6th, 2010, 10:32 AM

rev 50
* Cleaned up some of the convert.php file... Honestly, this one is a real mess, I only did the end of it. (convert.php)
- Removed debug_* compatibility code. (convert.php, recount_boards.php, recount_categories.php, recount_membergroups.php, upgrade.php, Class-Package.php, Errors.php, Subs-Db-mysql.php)
- Kept removing PHP4 compatibility code. (convert.php, readme_*.html, Display.php, Load.php, LogInOut.php, QueryString.php, Search.php, Subs-Auth.php, Subs-OpenID.php, Subs.php, Help.english.php)
- Deleted Subs-Compat.php file, as it's no longer needed. Will reintroduce... if ever needed again.

So that's 50 commits in a week and a half or so. Nice numbers :)
Lunch break...
10326
Features / Re: New revs
« on September 5th, 2010, 11:43 PM »
I don't know about which one Tortoise uses, I installed a package or something...
repair_settings.php was my own fix. It wasn't touched by Norv.

BTW, there's more legacy code in repair_settings.php on selecting the current database type. I guess all of this should be removed? We're never going to go beyond ONE supported db system are we?
I just want to clean it up as soon as possible. $db_type should be a good search word.
Also need to finish php_version and function_exists searches.
And also re-fix board list in Search template.

Tomorrow is 100% work for me, at last :) (People who enjoy work... Looneys!)


rev 47
* First part of the big commit on the rounded corner rewrite. botslice and topslice empty spans are replaced with a parent class of wrc. IE adds support through Javascript. (ssi_examples.php, admin.css, index.css, and these templates, wait for it: Admin, Display, Errors, Help, index, ManageAttachments, ManageBans, ManageBoards, ManageCalendar, ManageMail, ManageMaintenance, ManageMembergroups, ManageMembers, ManagePaid, ManagePermissions, ManageScheduledTasks, ManageSearch, ManageSmileys, ModerationCenter, MoveTopic, Packages, PersonalMessage, Post, Profile, Register, Reports, Search, SendTopic, SplitTopics, Stats, Themes and Who.)
10327
Features / Re: New revs
« on September 5th, 2010, 11:15 PM »
rev 46
* One-line version of a 4-line block. (Subs.php)
@ Okay, I just committed this because I discussed it, and forgot to commit.
10328
Features / Re: New revs
« on September 5th, 2010, 11:09 PM »
I don't know, I'm trying my best to imagine it's not their fault but mine. (Blame my low self-esteem.)

http://gnuwin32.sourceforge.net/packages/patch.htm
Quote
On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be used as line endings. A file with LF may give the error: "Assertion failed, hunk, file patch.c, line 343," unless the option '--binary' is given.
Maybe Tortoise forces the patch file to be in CR-LF format to ensure patch.exe won't screw it...? Because yes, the diff patch is itself in CR-LF in the first place. So that could explain it..?
(For devs using Windows or Linux as their platform) -> editing a LF file -> saving as LF -> committing patch
(For other dev using Windows as their platform) -> updating SVN (LF) -> generating a manual diff patch to apply on other branch (automatic CR LF) -> applying patch (CR LF) -> doing changes on that branch, committing to SVN in CR LF. File is 'remembered' as CR LF on the svn server (where data is always stored in LF.)

I really don't know. What I know is, the best way to get rid of these seems to have some sort of script that would automatically turn CRLF files into LF after a patch is done, or before a commit is done.

In any case, even though my SMF SVN indeed has a mix of CRLF and LF that can only be explained through the above examples (or simply a bad editor...), *my* commits are at fault, too. I should be careful.

PS: ah, I see you finally caught up with me in terms of posts here! I was wondering why it took you so long. :) Next step: 10k posts by next week! :lol:
10329
Features / Re: New revs
« on September 5th, 2010, 10:43 PM »
Can you believe I always forget to make sure it's okay?

I really need to find the setting in Subversion that will allow for all files be saved as LF...
10330
Features / Re: New revs
« on September 5th, 2010, 09:27 PM »
Nice! Although that adds a lot of lines, but they'll run fast enough so that's okay :)
BTW --> I compressed the two isset()->unset() into a single unset() with both variables listed in it. isset() isn't needed, as PHP5 won't generate an error if you try unsetting a non-existent variable (it won't even do it if you try to unset an array entry in a non-existent array). So, might as well unset both in one go. :)

My first big one is here... (Mostly Norv's doing.)

rev 44
Code: [Select]
- More PHP4 stuff removal. (index.php, SSI.php)
* Updated to SMF rev 10093:
  ! Fixed calculating steps/substeps for log_actions changes (upgrade script) [Bug 4427]
  ! Added the optional (in 1.1 spec) assoc_type to OpenID parameters (Subs-OpenID.php) [Bug 4420]
  ! Small improvement to be more mod-friendly, a useless variable usage could have caused issues with mods (Load.php) [Bug 4445]
  ! Avatars loaded from remote locations may have failed resizing in some cases (script.js) [Bug 3842]
  ! Re-added a couple of flock() calls, as fclose() does not unlock the file on PHP 5.3.2+ (Load.php, ManageMaintenance.php) [Bug 4330]
  ! Improved 'who's online' behavior for a user who toggles WYSIWYG view (index.php) [Bug 4415]
  ! MySQL needs the autoincrement column defined as primary key (DbPackages-mysql.php) [Bug 4422]
  ! A variable was overwritten for font-size style tag, but needed later for <a> tag preservation (Subs-Editor.php -> Class-Editor.php) [Bug 4447]
10331
Features / Re: New revs
« on September 5th, 2010, 06:02 PM »
Quote from Arantor on September 5th, 2010, 04:55 PM
Just for reference, yes, try/catch (I keep typing cache instead, haha)
Thta's not a porblem, we're not hree to witre a thises. We're hree to wrok on Webge Wegde[/s] Wgede.
Quote
would be a syntax error in PHP 4, so yes it would crash PHP in that respect.
Yeah, that's what I feared...
Oh well, as I said, it's okay because convert.php is unlikely to be used if the installer refused to work in the first place.
10332
Features / Re: New revs
« on September 5th, 2010, 04:52 PM »
Quote from Arantor on September 5th, 2010, 04:43 PM
Quote
Yeah, but I don't know if it could crash a PHP4 just by having some instructions it doesn't understand -- maybe com_exception, things like that.
It'll be a fatal error since try/catch is a language construct not in PHP 4. Since we don't support PHP 4 at all, it's not worth worrying about unless we reinstate the original branch too (since the eval will just return false in PHP 4 and do absolutely nothing otherwise)
I think I need to explain myself better, sorry. What I mean is, when you put a syntax error into a function, even a function that never gets called, PHP will directly crash on running the file. Would the try+catch and com_exception be considered as syntax errors? Because in that case, it would crash convert.php even before getting to the error message about the need to upgrade php.
However, it doesn't really matter, because you need to install your forum before you can convert to it, and if it won't install, there's no need to run the file anyway. So I'm good.
Quote
All I did was remove the code that defines session_regenerate_id() if it doesn't exist, it's not done with a PHP_VERSION check but a function_exists(), so it's possible you wouldn't find it otherwise.
I was actually planning to do a site-wide search on function_exists() as well, don't worry :) I only thought about it at the last moment though, so you're right, I could just as well have forgotten about it.
Quote
Sure, can assign stuff, it's been a while since I worked in a team!
We're a bit rusty :blush:

@Lorenzo> If you share that piece of code, even under a nickname, we'll KNOW it was your doing!

@Pete> He was kidding, re-read my previous PM with the code quote ;)
10333
Features / Re: New revs
« on September 5th, 2010, 04:38 PM »
@Lorenzo> An exclusive for you! Here's a short sample from some of our custom code!

Code: [Select]
if (!empty(

Sorry, can't show more. Hope it keeps you excited  :eheh:
Quote from Arantor on September 5th, 2010, 03:45 PM
If you're referring to the eval that's executed with a check on PHP 5 (line 2436 or so), just dropping it back out of being an eval and removing the other branch would be fine. The point is that try/catch is a language construct in PHP 5 and would choke in PHP 4.
Yeah, but I don't know if it could crash a PHP4 just by having some instructions it doesn't understand -- maybe com_exception, things like that.
Quote
Trouble is, it's all based on the logic in SimpleDesk.php, particularly shd_helpdesk_listing() IIRC - haven't touched that code in months, but it's the main part of SimpleDesk.php, which handles querying for data and processing it... it's not pretty, because it does have the ability to paginate on each block independently, and preserve pagination as you go, so if you hit page 2 of one block, and page 3 of another, both are preserved.
That's nice... But I'm sure it can be rewritten, still ;)
Quote
! Do not add extraneous Core rows in themes table on install (install_2-0_mysql.sql)
! Set it to return to post after posting by default (install_2-0_mysql.sql)
Yeah, I have yet to look into the mysql install files. I'm really removing things as things go, like, this morning I was simply looking for php_version and tried getting rid of all of the unneeded stuff. Still a lot remains to be done. Nothing biggie though.
Quote
Revision: 42
Author: arantor
Ahhhh!! You, filthy thief!![1] You stole my rev! I was looking forward to committing it myself! :P

'kay, just kidding, I already had rev 10.000 on SMF, and no one will take that one away from me... Despite Norv's efforts to revert part of that commit :niark:
Next stop: rev 69. Who will be getting it? :ph34r:

We just finished eating and I'm quite a bit wasted, again. What a weekend... And what with that 26'' monitor my hosts are using?! Why do they need that much space?
Anyway, I'll deal with all of these commits tonight (I have at least 3 on my waiting list, as I try to separate different fixes/additions into different commits).
Quote
! Remove legacy PHP 4.3.2 and lower compatibility function (Subs-Auth.php)
Can't look into the svn right now (see above), so... Are you doing stuff in my stead? Maybe we should determine how to deal with commit conflicts. Usually we work on different parts at the same time so it's okay, but for instance, if you're going to tackle a task in the bug tracker, could you assign it to yourself first? That way I would have a way to make sure we're not working on fixing the same issue at the same time. Which at best is a waste of time for one of us, and at worst, brings commit confusion. (I'm talking about big fixes and features, of course. If it's just a few lines of code, who cares if we're wasting time.)
 1. I like the sound of that.
10334
Features / Re: New revs
« on September 5th, 2010, 12:05 PM »
rev 39
- Removed php_412_bugfix leftovers. (Load.php, smf_api.php, install.php)
- Some of the files were not requiring PHP 5. (index.php, webinstall.php, install.php, upgrade.php, Subs-Compat.php)
@ Is the eval() necessary in convert.php? Will it run on PHP4 without them? (Considering PHP4 isn't supported, it's not important but...)

--> The eval() stuff should be unneeded, but I'm just not sure whether PHP4 won't choke on some stuff in it. I don't think so, but I kinda have a hangover, AND I'm about to go to that stupid party in a minute.
Anyway, I'm not yet finished with the PHP5 requirements (I only did the files that should be a "barrier" to installing Wegde on PHP4). There are many more lines to remove, I'll do them later today when I get back, so we're finished with it.

I've also upgraded to the latest SMF rev (10093), and I'm nearly finished with the botslice/topslice stuff, hopefully, tonight, or tomorrow morning everything will be committed.
10335
Features / Re: New revs
« on September 5th, 2010, 09:20 AM »
Thanks for the auto-topic fix, I really don't have time to work on anything this weekend... (I hate it.)
BTW, the "Mark Resolved" feature in SD doesn't seem to work when clicked from within a ticket. It does work when using the icon in the ticket list.
I really should rewrite the template for the homepage, btw, just so it shows tickets a bit more like Mantis & PT do... Right now it's a bit confusing to me, because of this whole "waiting for user/admin feedback" thing that really isn't necessary here.
Quote
The reason for this one is to make it much easier to build on and/or replace in the event of using something like CKEditor; now whatever we do in terms of altering the code, we just have to update wedgeEditor rather than liberally hitting up the code throughout Wedge.
Oh... Right! Then it's fantastic.
I love it that you baptized our project :) Very logically, too, since this is something that is unlikely of reaching SMF at all. (And if it does, they'd better keep the name :P)