New revs

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #30, 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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #31, on September 5th, 2010, 10:46 PM »
Can you believe the SMF team are still this sloppy?

It wouldn't hurt to fix it on our side, but they should be fixing it on theirs, and really how can you do a commit review if you can't check it is what it is supposed to be?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #32, 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:
Re: New revs
« Reply #33, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #34, on September 5th, 2010, 11:22 PM »
Does Tortoise use GNU patch? I thought it used its own to be honest.

But if that's the case, repair_settings.php should be affected out of the last patch - and it wasn't. Which means it still is with them. It wouldn't hurt to have our stuff above reproach, but really it should be fixed at source, and how many times have you told them about this?

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #35, 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.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #36, on September 6th, 2010, 12:48 AM »
Quote
I guess all of this should be removed? We're never going to go beyond ONE supported db system are we?
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), 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


Hmm, maybe it is the patch executable then? Hmm, I don't know.
Posted: September 5th, 2010, 11:49 PM

Anyway.

I got brave and just did this.


Revision: 48
Author: arantor
Date: 23:47:06, 05 September 2010
Message:
! Added PMs being saved in sent items by default for new accounts (install_2-0_mysql.sql)
----
Modified : /trunk/other/install_2-0_mysql.sql

MultiformeIngegno

  • Posts: 1,337

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #38, 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...

Dismal Shadow

  • Madman in a Box
  • Me: Who is Arantor? Cleverbot: It stands for time and relative dimensions in space.
  • Posts: 1,185
Re: New revs
« Reply #39, on September 6th, 2010, 01:40 PM »
Wedge's 50 commits vs SMF's 1 commit per week...
“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!


   Jack in, Wedge,
   EXECUTE!

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #40, 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)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #41, on September 6th, 2010, 02:34 PM »
Quote
Community support?
Something that YSF discussed, the idea that the core would support only MySQL by default but that those who wanted other things (PGSQL, SQLite, heck even MSSQL) could bolt it on. Trouble is, each of those has their own requirements and the way to go is not to throw the query from MySQL at a series of string replacements to make it sort of work with other things (and in MSSQL's case, that's asking for trouble anyway)

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #42, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #43, 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.

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.)

Nao

  • Dadman with a boy
  • Posts: 15,974
Re: New revs
« Reply #44, 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... :)