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 8th, 2010, 12:32 AM »
No... "((?:topic=)\d+)" would return "topic=1", I'm pretty sure of it. (I wouldn't bet my life on it, but I'm still quite certain.)
10322
Features / Re: New revs
« on September 7th, 2010, 11:43 PM »
I assure you that it means "topic or topic". :whistle:
Okay, bed time for me...
Okay, bed time for me...
10323
Features / Re: New revs
« on September 7th, 2010, 11:35 PM »
- editor: I was surprised to have noticed that myself ;D
- Subs: (?:topic) really does nothing. The regex engine will disregard it. The only reason to use (?:) is if you provide a quantifier after the parenthesis. (?:topic)? is logical. It's either topic, or nothing. (?:topic) means it's even topic, or topic. :lol:
- Subs: (?:topic) really does nothing. The regex engine will disregard it. The only reason to use (?:) is if you provide a quantifier after the parenthesis. (?:topic)? is logical. It's either topic, or nothing. (?:topic) means it's even topic, or topic. :lol:
10324
Features / Re: New revs
« on September 7th, 2010, 10:56 PM »
rev 62
* URL prompt in editor should use [url] type instead of [url=] when no description is provided. (editor.js)
! Fixing on-the-fly rounded corners for IE when splitting topics. (SplitTopics.template.php)
* Minor stuff. (Recent.template.php, index.css, Subs.php)
--> when it comes to Subs.php, your modified regex had a "(?:topic)" in it... Just replaced it with "topic" ;)
* URL prompt in editor should use [url] type instead of [url=] when no description is provided. (editor.js)
! Fixing on-the-fly rounded corners for IE when splitting topics. (SplitTopics.template.php)
* Minor stuff. (Recent.template.php, index.css, Subs.php)
--> when it comes to Subs.php, your modified regex had a "(?:topic)" in it... Just replaced it with "topic" ;)
10325
Features / Re: New revs
« on September 7th, 2010, 12:14 PM »
rev 60
* Renamed files with mysql in the filename to make it more generic. (install.php, create_backup.php, repair.php, repair_settings.php, restore_backup.php, smf_api.php, upgrade.php, detailed-version.js, Load.php, renamed: Db*-mysql.php to Db*.php, Subs-Db-mysql.php to Subs-Database.php)
--> I think "DbExtra.php" doesn't look good, but it's better than "DbExtra-mysql.php" which is redundant (MySQL *is* a Db.) Maybe "Data-Extra.php" or "Database-Extra.php"...? Dunno. It's not very important ;)
Okay, I should get back to my templating stuff now...
* Renamed files with mysql in the filename to make it more generic. (install.php, create_backup.php, repair.php, repair_settings.php, restore_backup.php, smf_api.php, upgrade.php, detailed-version.js, Load.php, renamed: Db*-mysql.php to Db*.php, Subs-Db-mysql.php to Subs-Database.php)
--> I think "DbExtra.php" doesn't look good, but it's better than "DbExtra-mysql.php" which is redundant (MySQL *is* a Db.) Maybe "Data-Extra.php" or "Database-Extra.php"...? Dunno. It's not very important ;)
Okay, I should get back to my templating stuff now...
10326
Features / Re: New revs
« on September 7th, 2010, 11:40 AM »
It's just a matter of phrasing stuff correctly. I don't mean yours isn't correct -- just that it can be confusing.
I'm confused myself. With my post, not your phrasing. Or am I. Or is it.
I should go back to bed.
I'm confused myself. With my post, not your phrasing. Or am I. Or is it.
I should go back to bed.
10327
Features / Re: New revs
« on September 7th, 2010, 08:00 AM »
"Please enter what text the link should say." -> Is this straightforward, or could people be confused with this? I would have said (with my limited English) something like, "You may enter a caption (description?) for the link if you'd like." It doesn't seem mandatory.
10328
Features / Re: New revs
« on September 7th, 2010, 07:25 AM »
Great news for everything :)
(Install script or upgrade script?)
(Install script or upgrade script?)
10329
Features / Re: New revs
« on September 6th, 2010, 10:52 PM »Unless you did something funky, I found I needed it since link= doesn't accept msg on its own (it requires either (board+)topic or threadid, optionally followed by the msg number for the # fragment, or action=profile with user id for PMs)
Well, every time I do something half way big, I push it through a fresh install, so I'll be able to test. I'm not so worried about the upgrade script right now personally (since I'm not planning to test it anytime soon :P)
(In the end, it's my goal to convert wedgeo to a vanilla Wedge, of course.)
PS: 1000+ posts on wedgeo :)
10330
Features / Re: New revs
« on September 6th, 2010, 09:22 PM »
Don't remember having ever touched the code you modified to add msg=... Are you sure it was needed? :)
rev 57
! Extra tabs/spaces, and typo fixes in comments, like its/it's and lets/let's. (Many files)
Pete, I've re-read the install and upgrade scripts, and I really hope I got them done without breaking anything. In terms of logic, it should be okay. Just don't yell at me if you try running one of the scripts and it crashes :) I just wanted to be done with it...
rev 58
- Hopefully, removed all of the remaining multi-database code. (install.php, smfinfo.php, upgrade.php, DbPackages-mysql.php, DbSearch-mysql.php, Search.php, SearchAPI-Custom.php, SearchAPI-Fulltext.php)
rev 57
! Extra tabs/spaces, and typo fixes in comments, like its/it's and lets/let's. (Many files)
Posted: September 6th, 2010, 09:15 PM
Pete, I've re-read the install and upgrade scripts, and I really hope I got them done without breaking anything. In terms of logic, it should be okay. Just don't yell at me if you try running one of the scripts and it crashes :) I just wanted to be done with it...
rev 58
- Hopefully, removed all of the remaining multi-database code. (install.php, smfinfo.php, upgrade.php, DbPackages-mysql.php, DbSearch-mysql.php, Search.php, SearchAPI-Custom.php, SearchAPI-Fulltext.php)
10331
Features / Re: New revs
« on September 6th, 2010, 04:36 PM »Just to clarify: FIND_IN_SET has its place, like everything else. But to use it to hunt through what is really relational data (user belongs-to group, board belongs-to group), which results in a table scan vs using indexes really is ridiculous.
When you're done with that, I'll begin on replacing $scripturl with a constant (along with the other similar globals that shouldn't really be global variables but constants)
I noticed your use of constants inside SD...
May I give you my honest opinion?
It looks kinda ugly........... :unsure:
Actually takes me back to the days of SMF1, with $ID_MEMBER, $ID_BOARD and such.
Re Oracle: If we make the move to everything being properly relational anyway, it becomes so much easier to build for... but I don't like building for something I can't test, hahah.
+1 for going relational, though. We already have plenty of tables... Why not add a few dozen more, people won't notice :P
10332
Features / Re: New revs
« on September 6th, 2010, 04:28 PM »I think it can. Oracle has jettisoned the areas it's not interested in (OpenSolaris for one), and MySQL is a money maker for it, especially as it can sell very expensive training, then upgrades to Oracle gear later on (with support contracts)
10333
Features / Re: New revs
« on September 6th, 2010, 04:27 PM »*nods** Arantor hands Nao the axe to finish chopping the multi DB code out.
- 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.
Point of interest: vBulletin only supports MySQL,
"We only do evil, but we're good at it." :eheheh:
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?
But keeping it in place when trying to support other database systems would be silly, indeed.
10334
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 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 You mean, things like FIND_IN_SET?Quote Oh, you gotta love Microsoft... :)
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.
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.
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.)
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.
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.)
10335
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.
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.