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 - Arantor
3811
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 10th, 2012, 12:16 PM »
= isn't really an issue but + certainly used to be in Windows (though I think it's allowed in NTFS)
If you want to be sure about avoiding collisions and still fixing the problem and still being fast, instead fix where the cache key contains /... The only move is not to play.
If you want to be sure about avoiding collisions and still fixing the problem and still being fast, instead fix where the cache key contains /... The only move is not to play.
3812
Bug reports / Re: SMF bug 4770 (top level menu items should be clickable)
« on April 10th, 2012, 12:12 PM »
The reason the UX is broken... well, we have the main site-wide navigation menu which does expressly function as having the top level items be clickable, with dropdowns that are also normal dropdowns. While the menu in the profile and admin etc. the top level items are not clickable, meaning they are inconsistent.
Then you have the fact that the top level menu items in admin menus are rendered the same way the generic tabs are (for per-section navigation), and now we're confusing the user because we have two things that look the same which do not act the same: tabs that are links and tabs that are not links but cause menus to occur.
If we can't solve the top level destination, what the hell do we do with the main site-wide menu?
Then you have the fact that the top level menu items in admin menus are rendered the same way the generic tabs are (for per-section navigation), and now we're confusing the user because we have two things that look the same which do not act the same: tabs that are links and tabs that are not links but cause menus to occur.
If we can't solve the top level destination, what the hell do we do with the main site-wide menu?
3813
Test board / Re: Test topic.
« on April 10th, 2012, 12:08 PM »
Because quick edit does something totally separate to Post2.php, it never actually calls either Post file at all, it's all in JSModify.php - and preparsecode is called at a different time, and notably, the Aeva on-posting code is never called at all (which is why the other stuff re the url bbcode doesn't happen in quick editing)
Even more than ', it bothers me about having " tags, and I'm not sure you wouldn't have to alter how the bbc parser works then since some parameters can be quoted.
Even more than ', it bothers me about having " tags, and I'm not sure you wouldn't have to alter how the bbc parser works then since some parameters can be quoted.
3814
Off-topic / Re: Random idea: non-generic default avatars
« on April 10th, 2012, 12:07 PM »
I actually think I'd rather have only a small part of the name rather than the full name, I just think it'd look better that way, but won't know until I try it.
The other thing regarding fonts is that whatever we decide to use, we have to be shipping with Wedge itself, so the licence must allow for downloading and onward distribution, it's not like you can just use a web font for this one. And dingbat fonts tend to be heavier than regular fonts.
The other thing regarding fonts is that whatever we decide to use, we have to be shipping with Wedge itself, so the licence must allow for downloading and onward distribution, it's not like you can just use a web font for this one. And dingbat fonts tend to be heavier than regular fonts.
3815
The Pub / Re: Wedge and International Domain Names (IDNs)
« on April 10th, 2012, 12:05 PM »
Tthe forum will basically function, provided that $boardurl is set up properly. (And, I suppose, the column in the boards table might need to be longer to hold the domain name too) I don't recall there being any checks made by the installer as to the validity of $boardurl, merely that it isn't empty, because the default value is usually right.
However, the url bbcode will not auto link internationalised domains, though it should continue to link Punycode domains (since the whole point is that they're Latinised to use the same characters in the standard character set that domains always used to have to be)
However, the url bbcode will not auto link internationalised domains, though it should continue to link Punycode domains (since the whole point is that they're Latinised to use the same characters in the standard character set that domains always used to have to be)
3816
Test board / Re: Test topic.
« on April 10th, 2012, 12:00 PM »
Yay for entirely separate code paths -_-
3817
Archived fixes / Re: SMF bug 4956 (slash in cache key causes cache to fail)
« on April 9th, 2012, 10:08 PM »
Apart from the fact I don't know if base 64 is faster than md5 or not (I haven't benched it), I do know that base64 as PHP implements it can include +, = and / which may or may not be legal characters, and which doesn't leave us any closer to a workable solution. That would mean we'd end up with doing either a strtr or str_replace on top of the base64_encode.
What I'll do is benchmark MD5 vs SHA1 vs base64_encode for performance.
Quote Code: [Select]
It's crude but illustrates the relative performance. B64 is fastest - if we can rely on it never generating invalid characters in the keys, which we can't.
What I'll do is benchmark MD5 vs SHA1 vs base64_encode for performance.
Posted: April 9th, 2012, 09:51 PM
Carrying out 500000 iterations
String: `something short`
MD5: 0.62707901000977 seconds
SHA1: 0.62861299514771 seconds
B64: 0.44805788993835 seconds
B64/sstrtr: 1.0246500968933 seconds
B64/str_replace: 1.4543380737305 seconds
String: `something much much much much much longer that we can use to benchmark these things.`
MD5: 0.67529892921448 seconds
SHA1: 0.75934195518494 seconds
B64: 0.47315502166748 seconds
B64/sstrtr: 1.0639209747314 seconds
B64/str_replace: 1.5031769275665 seconds
String: `something impossibly and unrealistically long, after longer than the typical cache key will be but just in case it is worth having an idea of relative performance`
MD5: 0.74138998985291 seconds
SHA1: 0.8517210483551 seconds
B64: 0.50031614303589 seconds
B64/sstrtr: 1.154757976532 seconds
B64/str_replace: 1.6336131095886 seconds
<?php
$strings = array(
'something short',
'something much much much much much longer that we can use to benchmark these things.',
'something impossibly and unrealistically long, after longer than the typical cache key will be but just in case it is worth having an idea of relative performance',
);
$iters = 500000;
echo 'Carrying out ', $iters, ' iterations<br>';
foreach ($strings as $str)
{
echo '<hr><br>String: `', $str, '`<br>';
$time_start = microtime(true);
for ($i = 0; $i < $iters; $i++)
$dummy = md5($str);
$time_end = microtime(true);
echo ' MD5: ', $time_end - $time_start, ' seconds<br>';
$time_start = microtime(true);
for ($i = 0; $i < $iters; $i++)
$dummy = sha1($str);
$time_end = microtime(true);
echo ' SHA1: ', $time_end - $time_start, ' seconds<br>';
$time_start = microtime(true);
for ($i = 0; $i < $iters; $i++)
$dummy = base64_encode($str);
$time_end = microtime(true);
echo ' B64: ', $time_end - $time_start, ' seconds<br>';
$time_start = microtime(true);
for ($i = 0; $i < $iters; $i++)
$dummy = strtr(base64_encode($str), '+/=', '-__');
$time_end = microtime(true);
echo ' B64/sstrtr: ', $time_end - $time_start, ' seconds<br>';
$time_start = microtime(true);
$s = array('+', '/', '=');
$r = array('-', '_', '_');
for ($i = 0; $i < $iters; $i++)
$dummy = str_replace($s, $r, base64_encode($str));
$time_end = microtime(true);
echo ' B64/str_replace: ', $time_end - $time_start, ' seconds<br>';
}It's crude but illustrates the relative performance. B64 is fastest - if we can rely on it never generating invalid characters in the keys, which we can't.
3818
Bug reports / Re: SMF bug 4961 (no index.php or .htaccess file when new attach folder made)
« on April 9th, 2012, 09:46 PM »
You both win an internet ^_^
3819
Bug reports / Re: SMF bug 4834 (no way to disable PM body being sent in notifications)
« on April 9th, 2012, 07:16 PM »
Well, they do, but if there's enough people that would prefer to have the option, we can leave the option in - but having the option does constrict what editing you can do of PMs that are as yet unread.
3820
Archived fixes / Re: SMF bug 4859 (Text limit not necessarily enforced properly)
« on April 9th, 2012, 07:16 PM »
Not *many*, no.
However, there's all sorts of fringe problems.
1) Set a post length of 64000, create a post where you add 63999 characters. It will be checked, validated as being within the limit, then preparsed, whereupon it will get bigger in almost every case (e.g. the newline conversion) where now it might not fit in to the text buffer.
2) If you set a limit of 0, there is absolutely no check made on content length and posts will be truncated at 64K without any warning.
3) If you set the length to > 64K, the table will be adjusted without warning, which is a full table lock. There isn't even a reminder to put it in maintenance mode.
4) If you set the length to > 64K, then back afterwards, the table will be downsized, without any validation of posts' content, meaning that any posts > 64K, they will be truncated without warning.
Now, we have two choices. We can accept the extra byte per message, or we can implement measures to remedy all of the above.
However, there's all sorts of fringe problems.
1) Set a post length of 64000, create a post where you add 63999 characters. It will be checked, validated as being within the limit, then preparsed, whereupon it will get bigger in almost every case (e.g. the newline conversion) where now it might not fit in to the text buffer.
2) If you set a limit of 0, there is absolutely no check made on content length and posts will be truncated at 64K without any warning.
3) If you set the length to > 64K, the table will be adjusted without warning, which is a full table lock. There isn't even a reminder to put it in maintenance mode.
4) If you set the length to > 64K, then back afterwards, the table will be downsized, without any validation of posts' content, meaning that any posts > 64K, they will be truncated without warning.
Now, we have two choices. We can accept the extra byte per message, or we can implement measures to remedy all of the above.
3821
Off-topic / Re: Random idea: non-generic default avatars
« on April 9th, 2012, 07:08 PM »
There's no licence stated in the file itself, nor any stated on that page. Dominic's a pretty reasonable chap (as I know from discussing other licences with him in the past, as he's the guy who wrote ImpactJS), but in any case I don't think it matters. The font, however, is certainly free for any use and as far as I can tell can be safely redistributed (Regular is the variant used, but there's also a Bold and a Light variant)
The reason I suspect it doesn't really matter is that the code is actually very simple - but even then we'd be rewriting it to suit us a bit better. All that happens is that there are a selection of colour schemes which form two background colours and a text colour. The method is to fill the background with the first BG colour, draw a very large glyph as a background using the second BG colour (choices are 0, o, > or //) then draw the actual characters in the FG colour.
There's not really a lot of variation in the code (except possibly in the sizing proportions) but I'd think we'd want something a bit bigger than 40x40?
(There is also a glass.png file that is attached as an overlay but the visual difference is pretty small IMO)
The reason I suspect it doesn't really matter is that the code is actually very simple - but even then we'd be rewriting it to suit us a bit better. All that happens is that there are a selection of colour schemes which form two background colours and a text colour. The method is to fill the background with the first BG colour, draw a very large glyph as a background using the second BG colour (choices are 0, o, > or //) then draw the actual characters in the FG colour.
There's not really a lot of variation in the code (except possibly in the sizing proportions) but I'd think we'd want something a bit bigger than 40x40?
(There is also a glass.png file that is attached as an overlay but the visual difference is pretty small IMO)
3822
Off-topic / Re: Random idea: non-generic default avatars
« on April 9th, 2012, 05:04 PM »
Considering how identicon and monsterid are actually types of Gravatar implementation, I doubt it.
3823
Off-topic / Re: Random idea: non-generic default avatars
« on April 9th, 2012, 04:39 PM »
What do you mean 'more library like this'? I just picked this up from the blog I linked. He has a bunch of quirky ideas but not quite so much in the way of actually shared code.
3824
Bug reports / Re: SMF bug 4961 (no index.php or .htaccess file when new attach folder made)
« on April 9th, 2012, 04:09 PM »
Also, having investigated web.config files, it seems that these won't help matters because they don't seem to kick in except on .asp/.aspx files.
3825
Archived fixes / Re: SMF bug 4859 (Text limit not necessarily enforced properly)
« on April 9th, 2012, 03:04 PM »
I can't seem to find anything which suggests mediumtext is any more vicious than a text is, bearing in mind the fact that a mediumtext requires 3 bytes per row rather than 2, which means an extra byte per message, so you've got the extra I/O impact.
But really, given the way that you can accidentally trigger the code internally to perform an ALTER TABLE on the messages table without being aware of it, I'd rather just make the switch, which would typically solve the problem, you only then hit the query packet limit, rather than some shorter arbitrary limit (and it means that to all intents and purposes, 0 really does mean no limit)
But really, given the way that you can accidentally trigger the code internally to perform an ALTER TABLE on the messages table without being aware of it, I'd rather just make the switch, which would typically solve the problem, you only then hit the query packet limit, rather than some shorter arbitrary limit (and it means that to all intents and purposes, 0 really does mean no limit)