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.
7606
Features / Re: These two bytes may not matter to you...
« on September 30th, 2011, 08:39 PM »
- Oh yeah, I forgot about that one, sorry...
- Well it's in the admin area only then, I guess... Nah, the skin selector base64-encodes all URLs it has in the query string :)
I suppose I could remove that, then, yeah... When you're back, have a look at the index.template.php change in rev 1043. The extra code is after the $qmark test. It's probably not worth removing, though... I mean, one extra substr... it's fast enough.
- Well it's in the admin area only then, I guess... Nah, the skin selector base64-encodes all URLs it has in the query string :)
I suppose I could remove that, then, yeah... When you're back, have a look at the index.template.php change in rev 1043. The extra code is after the $qmark test. It's probably not worth removing, though... I mean, one extra substr... it's fast enough.
7607
Features / Re: New revs
« on September 30th, 2011, 08:35 PM »
rev 1043
(6 files +1, 129kb)
+ Forgot to add the Matroska parser for mkv and webm support in the media area. (module.audio-video.matroska.php)
! Turned language flag URLs into relative URLs, fixing a wrong attempt by Wedge to re-prettify pretty URLs with both 'action' and 'board' variables in them. Eh, also makes the URLs shorter... (index.template.php)
+ Added support for 'rem' unit size in WeCSS's math function. (Class-CSS.php)
+ Forgot to translate an old item. Hmm. (index.french.php)
* Commenazi. (Load.php, getid3/*)
(6 files +1, 129kb)
+ Forgot to add the Matroska parser for mkv and webm support in the media area. (module.audio-video.matroska.php)
! Turned language flag URLs into relative URLs, fixing a wrong attempt by Wedge to re-prettify pretty URLs with both 'action' and 'board' variables in them. Eh, also makes the URLs shorter... (index.template.php)
+ Added support for 'rem' unit size in WeCSS's math function. (Class-CSS.php)
+ Forgot to translate an old item. Hmm. (index.french.php)
* Commenazi. (Load.php, getid3/*)
7608
Features / Re: These two bytes may not matter to you...
« on September 30th, 2011, 08:11 PM »
phpseclib... What does it do?
How would you trim the comments? Through a commandline tool? Some script? Or manually...? I've done some extra comment ripping but it's dull and frankly on the next getid3 update I probably won't bother at all. Oh man, how do I *hate* dirty source code with plenty of commented out functions, things like that... It's definitely not something I'd release, personally. And these pieces of code have been in there for years...!
Okay, a small one now. Does anyone remember any situation where Wedge/SMF might put a slash (/) inside the query string, i.e. after the "?" part of the URL? Any variable values that can contain a slash? I can't think of anything, but if I could be sure that it doesn't happen, I could safely remove a substr and a strpos from the main codepath.
How would you trim the comments? Through a commandline tool? Some script? Or manually...? I've done some extra comment ripping but it's dull and frankly on the next getid3 update I probably won't bother at all. Oh man, how do I *hate* dirty source code with plenty of commented out functions, things like that... It's definitely not something I'd release, personally. And these pieces of code have been in there for years...!
Okay, a small one now. Does anyone remember any situation where Wedge/SMF might put a slash (/) inside the query string, i.e. after the "?" part of the URL? Any variable values that can contain a slash? I can't think of anything, but if I could be sure that it doesn't happen, I could safely remove a substr and a strpos from the main codepath.
7609
Off-topic / Re: Post count fever
« on September 30th, 2011, 06:19 PM »
And I'm not processing all posts with php :p
7611
Off-topic / Re: Post count fever
« on September 30th, 2011, 06:15 PM »
Hmm I doubt Mysql has ?R in its regex list...
7612
Off-topic / Re: Post count fever
« on September 30th, 2011, 04:47 PM »
I don't know, my changelogs are usually smaller than yours.. :P
No, I'd suspect it's due to the amount of quoting I do. Obviously, quotes are taken into account. And I'm not going to create a new table, copy all messages into it, remove quotes recursively and restart the count... I won't! Will I? :P
No, I'd suspect it's due to the amount of quoting I do. Obviously, quotes are taken into account. And I'm not going to create a new table, copy all messages into it, remove quotes recursively and restart the count... I won't! Will I? :P
7613
Off-topic / Re: Post count fever
« on September 30th, 2011, 04:26 PM »
Oh, you're a clear winner then...!
Let me try it...
SELECT e.real_name, sum( length( m.body ) ) AS woot
FROM {db_prefix}messages AS m, {db_prefix}members AS e
WHERE e.id_member = m.id_member
GROUP BY e.id_member
ORDER BY woot DESC
LIMIT 0, 30
Nao 5320884
Arantor 4350826
Dragooon 444021
Bloc 242177
[Unknown] 215976
~DS~ 201932
live627 142454
snoopy-virtual 142245
MultiformeIngegno 102646
Aaron 75351
TE 73382
DirtRider 73004
spoogs 60875
dannbass 54347
Norodo 52533
Clara Listensprechen 44839
texasman1979 43416
CJ Jackson 40739
spuds 37685
billy2 33713
DoctorMalboro 33105
mforum 30462
YogiBear 29728
Road Rash 29556
Cassiel 28643
Nightwish 28612
Adonis 27529
dorje 25504
dazed 24767
hadesflames 23886
Err... What?! I must have made a mistake in my query :lol:
Let me try it...
SELECT e.real_name, sum( length( m.body ) ) AS woot
FROM {db_prefix}messages AS m, {db_prefix}members AS e
WHERE e.id_member = m.id_member
GROUP BY e.id_member
ORDER BY woot DESC
LIMIT 0, 30
Nao 5320884
Arantor 4350826
Dragooon 444021
Bloc 242177
[Unknown] 215976
~DS~ 201932
live627 142454
snoopy-virtual 142245
MultiformeIngegno 102646
Aaron 75351
TE 73382
DirtRider 73004
spoogs 60875
dannbass 54347
Norodo 52533
Clara Listensprechen 44839
texasman1979 43416
CJ Jackson 40739
spuds 37685
billy2 33713
DoctorMalboro 33105
mforum 30462
YogiBear 29728
Road Rash 29556
Cassiel 28643
Nightwish 28612
Adonis 27529
dorje 25504
dazed 24767
hadesflames 23886
Err... What?! I must have made a mistake in my query :lol:
7614
Plugins / Re: Add-on Manager: Mechanics
« on September 30th, 2011, 03:41 PM »
Sorry for the mixup.
7615
Plugins / Re: Add-on Manager: Mechanics
« on September 30th, 2011, 03:25 PM »
Oh you mean in plugin-info.XML? You had me confused with blocks ;)
7616
Plugins / Re: Plugin development
« on September 30th, 2011, 03:24 PM »
Pete, it's your code. Deal with it however you feel comfy with :)
7617
Plugins / Re: Add-on Manager: Mechanics
« on September 30th, 2011, 03:19 PM »
A template block? You mean using the ui to store non-ui data? I'm sure we could think of something more elegant..?
7618
Off-topic / Re: Need a regular expression
« on September 30th, 2011, 12:20 PM »
Didn't you write regex back in the smg times?
7619
Plugins / [Naming poll] Re: Packages
« on September 30th, 2011, 10:40 AM »
I know that me saying 'bed time' all the time has everyone laughing, but I like doing that because it means "if you're waiting for an answer -- go to bed, too!"
7620
Features / Re: These two bytes may not matter to you...
« on September 30th, 2011, 10:37 AM »
- File counter. Its code was obviously lifted from another, more complicated function, so it was doing unnecessary things in the middle, most notably doing a recursive search... When we really only needed to have the files in the current folder. count(glob()) was the faster solution in the end.
- It can be disabled individually... But then again, why would it?
- Gone.
- Updated to 1.9.1, with a few files removed in the process (never actually got around to using these id3 tags from mp3 files, so we might as well not include the files... Until someone actually wants to implement this.)
Also, the PHP 5.3 compat fixes were long overdue at the time, and obviously Aeva Media shipped with a version of 1.7.9 that was custom-fixed for PHP 5.3.
I'd estimate that around 10 to 20% of all code in getid3 is comments, and it doesn't compress well on top of that. Still, with the files I removed, the additional code and comments aren't too huge...
- Another thing worthy of note.
http://techblog.procurios.nl/k/news/view/34972/14863/Cache-a-large-array-JSON-serialize-or-var_export.html
I was curious about var_export(), because it stores the array in PHP format, so I made my own test...
Code: [Select]
As a result: (and I'm getting proportionally identical results with just a single string)
0.00023102760314941
0.00013899803161621
0.00025486946105957
0.00014996528625488
i.e. the unserialize solution, as used in SMF/Wedge, is nearly twice as fast as storing an array in PHP format...!
Meaning that if we actually went ahead and turned all of the array declarations to serialized strings in Wedge, it would improve performance :lol:
Well, of course it's hardly doable, if only because some array entries are dynamic, permission-based or similar, so that would require unsetting them after the unserialize which would waste some time, but... well, it's always good to know! :^^;:
- It can be disabled individually... But then again, why would it?
- Gone.
- Updated to 1.9.1, with a few files removed in the process (never actually got around to using these id3 tags from mp3 files, so we might as well not include the files... Until someone actually wants to implement this.)
Also, the PHP 5.3 compat fixes were long overdue at the time, and obviously Aeva Media shipped with a version of 1.7.9 that was custom-fixed for PHP 5.3.
I'd estimate that around 10 to 20% of all code in getid3 is comments, and it doesn't compress well on top of that. Still, with the files I removed, the additional code and comments aren't too huge...
- Another thing worthy of note.
http://techblog.procurios.nl/k/news/view/34972/14863/Cache-a-large-array-JSON-serialize-or-var_export.html
I was curious about var_export(), because it stores the array in PHP format, so I made my own test...
global $cachedir, $modSettings;
$myDataArray=array_merge($modSettings,$modSettings);
// Store cache
file_put_contents($cachedir.'/test1.php', json_encode($myDataArray));
file_put_contents($cachedir.'/test2.php', serialize($myDataArray));
file_put_contents($cachedir.'/test3.php', "<?php\n\$myDataArray = " . var_export($myDataArray, true) . ";");
file_put_contents($cachedir.'/test4.php', "<?php\nreturn '" . serialize($myDataArray) . "'; ?>");
// Retrieve cache
$a=microtime(true);
$myDataArray = json_decode(file_get_contents($cachedir.'/test1.php'));
echo microtime(true)-$a, ' ';
$a=microtime(true);
$myDataArray = unserialize(file_get_contents($cachedir.'/test2.php'));
echo microtime(true)-$a, ' ';
$a=microtime(true);
include($cachedir.'/test3.php');
echo microtime(true)-$a, ' ';
$a=microtime(true);
$myDataArray = unserialize(include($cachedir.'/test4.php'));
echo microtime(true)-$a;As a result: (and I'm getting proportionally identical results with just a single string)
0.00023102760314941
0.00013899803161621
0.00025486946105957
0.00014996528625488
i.e. the unserialize solution, as used in SMF/Wedge, is nearly twice as fast as storing an array in PHP format...!
Meaning that if we actually went ahead and turned all of the array declarations to serialized strings in Wedge, it would improve performance :lol:
Well, of course it's hardly doable, if only because some array entries are dynamic, permission-based or similar, so that would require unsetting them after the unserialize which would waste some time, but... well, it's always good to know! :^^;: