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
4756
Features / Re: Media boards: fishing for opinions
« on July 15th, 2012, 12:25 AM »
Well, going for album 'boards' means that we're going to get more 'custom boards' than just by offering blog boards.
And more custom boards, means that, as per Pete's remark, {query_see_boards} is going to require a subselect rather than get away with a IN (...), so it's bound to be a bit slower on all board-related queries.
No?

Of course I also saw another post on another website that swears a subselect is faster because it can make use of an index, I'm not even sure about that, and anyway it can hardly be faster than a pure string representation of the board list...?

I don't know.
4757
Features / Re: Media boards: fishing for opinions
« on July 15th, 2012, 12:07 AM »
I missed your reply, Pete...

Note: I've added a POLL for the media structure. Please answer if you can! The solution I described in my first post is the first one in the list. The last one is the equivalent to Aeva Media's album topic system (which AFAIK was never used by anyone but me -- in FoxProg, as a way to automatically fill my blog with new album uploads.)
Quote from Arantor on July 6th, 2012, 04:13 PM
The other kind is where it is not free, because it requires rewriting all the data in every row to align it to the new size. Changing the size or type of columns (mediumint to int, or the other way for example, or changing the type from numeric to textual etc) is very expensive on large tables as a result - and naturally it's usually fully table locking in the process. (Certain InnoDB operations can be done without it being a full table lock but generally assume it is)
Uh... Well. I can only imagine that if you put your forum into maintenance mode, it won't be too much of an issue...?
Quote
Also note that adding a column to an existing table has exactly the same problem. For most tables it's not preposterously expensive in most cases, because in most cases people with 100k+ posts don't generally go modifying their DB too much unless absolutely necessary because once they get to that size they're already aware of the limitations.
Well, I reached 220K on my old forum without knowing a damn thing about MySQL...
Quote
No, it's not compressed, but it is byte-packed, meaning that fields that don't need full bytes don't generally consume full bytes, but they pack all the fields in to use the least number of whole bytes.
Oh... Good, then. As such, I don't really see any reason to prevent the field from being set to a larger size?
Quote
id_topics appear in the indexes in multiple places. Take wedge_messages, of the litany of indexes that table has, four of them have id_topic as part of those indexes, and as a result of that, expanding the id_topic field to 4 bytes means we don't lose an extra byte per row, we lose that multiplied by 5 (1 for the row, 4 for indexes), so we gain 5 bytes per message, just in that one case, and in the case of indexes, we have a vested interest in keeping them lean.
Now, that's a real problem... :-/
4758
Features / Re: New revs
« on July 14th, 2012, 10:50 PM »
rev 1638
(2 files, 8kb)

- Removed code tag's hack code from theme.js because I did some testing and couldn't find a single browser that had problems with these. I'll restore it if someone can provide me with a clean test case. (theme.js)

* Moved img.resized JS code to the img tag parser, and got rid of theme.js contents in the process, saving about 200 gzipped bytes from the main script file. (install.sql, theme.js)

* Replaced CRLF codes with simple Linux linefeeds in bbcode PHP. This should be just fine this way. (install.sql)

* Ensuring that the install script declares all auto-incremented IDs as unsigned. I don't even know if it's possible to manually insert a negative ID in these... Probably possible, but pointless. (install.sql)

* Started harmonizing field sizes in the database. For instance, id_member is mediumint(8) unsigned (I don't think there's any case where an id_member is stored as negative, even for a pseudo-member), things like that. (install.sql)

+ Added an id_media field to topics, for future use. (Yeah, don't have to be Einstein to get that one...) (install.sql)
4759
Features / Re: New revs
« on July 14th, 2012, 10:49 PM »
rev 1637
(6 files, 3kb)

* Spacinazi and other details. (Class-Editor.php, index.css, sections.css)

+ Added an 'add_js_unique' helper function, which allows you to add a JS snippet multiple times while ensuring it's only printed once. Very useful for adding JS from a function we don't know how many times will be called. (Subs-Cache.php)

* Turned profile page's name back into a link. Although it's linking to the same page, at least we get the proper group color... (And I'm wary of re-introducing color fetching from the database. For now at least.) (Profile.template.php)

! Wrong color alignment in the stats page. (Stats.template.php)
4760
Features / Re: New revs - Public comments
« on July 14th, 2012, 07:45 AM »
Or maybe I have a tendency to either do Babylon ripoffs using Noisen-inspired color sets :P (Which are basically a series of color sets I build in a few minutes for fun and then offered as choices to blog creators on the site...)

I have a Samsung 971P monitor, it's a high-quality 5/4 monitor (like, one of the very last before this annoying 16/9 & 16/10 wave took over everything... Gosh where can I find 4/3 or 5/4 monitors now?!), it's pretty well known for the quality of its colors too.
I think that my IPS screen actually shows 'blander' but 'more accurate' colors than a TN screen. What's yours?
Posted: July 14th, 2012, 07:42 AM

(Also, these colors are closer to the postbg ones, I'd say.)
4761
Features / Re: New revs
« on July 13th, 2012, 11:51 PM »
rev 1636
(14 files, 5kb, diff patch is 11kb, I need to let go of what svn tells me when committing...)

! Fixed a potential undefined index when the client doesn't have any headers specifying the requested host name. This certainly means it's a mischievous bot, but it should already have been stopped by Bad Behavior at this point, so no need to generate a regular error as well... In case it's a 'proper' query, rebuilding the host name from the default one. (Load.php)

! Fixed another undefined index error that would trigger when visiting a Media admin page with an outdated session ID. (ManageMedia.php)

- Removing some unneeded tab_data elements. (Admin.php, ManageMail.php, ManagePaid.php, ManagePermissions.php, ManageScheduledTasks.php, ModerationCenter.php, PackageGet.php, RepairBoards.php)

* If a file was shortened after an error was generated in it, and the error was near the end, Wedge would show nothing in the file viewer popup. Replacing this with a warning about the user being out of bounds. (ManageErrors.php, ManageMaintenance.language.php)

* Don't bother specifying a height for file viewer popups. Really, most browsers will behave and choose the best possible height. Except for IE, but I don't give a damn. (ManageErrors.php)

* Changed default windowbg colors for Weaving. I like change from time to time... (index.css)

* Chrome doesn't cooperate with box-sizing stuff. As far as I know, 0.4% * 2 + 49% < 50%, but it still would insist on showing just one column per row, instead of two. Decreasing the width by 0.1% helps it behave better. Meh. (index.css)

@ And I just discovered that TortoiseSVN, or RepoHosting, now allow editing any changelog's body or author... :) Used to refuse to let me do it!
4762
Features / Re: New revs
« on July 13th, 2012, 10:09 AM »
rev 1635 - the playlist commit
(4 files, 1kb) (must be buggy because the diff patch is 11KB! For rev 1634 it was 6KB...)

! Fixed playlists no longer working after the latest Foxy commit. (Aeva-Foxy.php)

! Fixed undefined variable when visiting a playlist page with at least one vote. (Aeva-Foxy.php)

! Fixed non-AeMe calls to Zoomedia generating undefined errors. (Aeva-Subs-Vital.php)

* Moved the rest of playlists' inline JavaScript to player.js. (Aeva-Foxy.php, player.js)

* Moved playlist and media item names to the category header. (Aeva-Foxy.php, Aeva-Gallery.php)
4763
Features / Re: New revs
« on July 13th, 2012, 10:08 AM »
rev 1634
(8 files, 4kb)

* Stripped tags from HTML-safe page titles. No longer generating this variable before it's really needed. (Subs-Template.php, Subs.php)

* Adjusting error log's code popup height. I'm not exactly sure why it didn't fit anymore... (ManageErrors.php)

* Adjusting height for PM post boxes as well. (PersonalMessage.php)

+ Added commas between voter names when polls allow to view them. (Display.template.php)

* Reverted the HTML validator to the good old URL, as they appear to have fixed their earlier issues. (index.template.php)

* Giving more breathing space to unordered lists. (index.css)

* Couple of bytes saved. (sbox.js)
4764
Features / Re: Github & stuff
« on July 13th, 2012, 07:57 AM »
What does RH offer that others don't...?

So, going with what works = SVN + RH, private right now, public repo later?

Meh. I don't know. I'd rather use RH to try for a dual SVN/Git repo where we do some Git testing or something.
Or perhaps we could use Github with a SVN client... (It sounds silly but they do support that.. https://github.com/blog/966-improved-subversion-client-support and https://github.com/blog/1178-collaborating-on-github-with-subversion)
4765
Features / Re: Auto_increment madness...
« on July 13th, 2012, 07:52 AM »
Quote from Arantor on July 13th, 2012, 12:09 AM
Quote
Well, err... I thought you'd fixed that one...?
I fixed most of it but you since showed me that there are edge cases where it still happens which haven't yet been fixed.
Oh... The iPod thing...?
Crap... :(
I'd moved on. Never really had another opportunity to look at my drafts. I just looked at them now and sure thing, I have some drafts from this week that are quite obviously from iPod posts... :-/
Quote
I'll be happy with running it on a multi-million post forum. I've only seen one billion-post forum in the past and they started out on phpBB2 some years back (and have since rewritten it - that's Gaia Online), everyone else of that sort of scale (the likes of Slashdot et al) wrote their own.
It's been years, and I have yet to understand the point in Gaia Online...
Well, to each their own! If I could create my very own Gaia Online I wouldn't care what others think of it :P
Quote
Biggest SMF forum I've seen is 22m posts and growing daily.
And I don't understand its point, either...
4766
Features / Re: Auto_increment madness...
« on July 13th, 2012, 12:02 AM »
Quote from Arantor on July 12th, 2012, 10:03 PM
Quote
I dont remember this story about phantom rows.
You're the one who reported it - where drafts get saved even when they shouldn't be - the result is phantom rows that shouldn't really be saved in the first place.
Well, err... I thought you'd fixed that one...?
Once I find a bug of mine, I tend not to let go until it's fixed. (Just spent 3 hours on a stupid JS bug in playlist pages... My dear Opera, it was your fault... You failed to report that it was a declaration error.... -_-)
Quote
Quote
We could add a maintenance task to flush the cache though. Like, "okay the forum is quiet these days, I can do that..."
If you mean the regular cache,
No, I mean the draft table (the draft cache).
Quote
If you mean cases like this, I'd suggest not doing that on an automatic fashion. I'm not sure it's ever going to be a problem.
Well, if the table is filled, I guess we can always tell them to do a TRUNCATE on it...
Quote
As per http://stackoverflow.com/questions/6130672/mysql-auto-increment-primary-key-running-out there are notes about keeping the primary key as small as possible (especially on InnoDB), and that's important as that's now the default in MySQL. Let's leave it as is and we can deal with it if and when we actually get near to those limits.
Interesting.

Yeah, I just don't wanna be accused of thinking on the short term. But we've got a long way to go until Wedge is run on a billion-post forum!
4767
Features / Re: Auto_increment madness...
« on July 12th, 2012, 09:33 PM »
I dont remember this story about phantom rows.
Really.

8500+ is a lot for a basically temp table.
We could add a maintenance task to flush the cache though. Like, "okay the forum is quiet these days, I can do that..."
4768
Features / Re: Github & stuff
« on July 12th, 2012, 06:42 PM »
I'm going to check all code as I do these days. i.e. carefully but not being too anal about it.

What would you prefer to do yourself, Pete, regarding:
- When to change our system (if ever)?
- What system to use? (SVN, Git, Mercurial, Bazaar...?)
- Where to host it? (Repohosting, Bitbucket, Google Code, Github...)

Right now I'd say Bitbucket + private Mercurial (and public later), but I have a feeling that we're going to end up going to Github, like most people... (It's nearly funny, watching all of the other sites pointing people to their most active repos, and when you click a repo whose name you've heard of, you end up with this final commit message: "Moved project to github"... Lol. It happened several times. Last one I remember is XBMC.)
4769
Features / Re: Auto_increment madness...
« on July 12th, 2012, 06:39 PM »
Quote from Arantor on July 12th, 2012, 04:29 PM
Quote from Nao on July 12th, 2012, 04:22 PM
Ah well, another good intention that comes down the toilet... :(
It is a good intention but I suspect we'll be better served by dealing with phantom drafts anyway ;)
How do you envision it then..?
4770
Features / Re: Auto_increment madness...
« on July 12th, 2012, 04:22 PM »
Ah well, another good intention that comes down the toilet... :(

(And don't tell me "I know how you feel", I know you do :P)