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
2026
Other software / Re: SMF reaction to 'unused, useless globals'
« on January 8th, 2014, 11:26 PM »
Yeah... But of course, he'd never admit that it was thanks to the very script he dismissed as silly, would he now...? :whistle:
There's still tons (hundreds?) of unneeded globals left, though. A huge difference compared to the 3 left in Elk (not counting the ones in install.php), and the zero in Wedge[1].
There's still tons (hundreds?) of unneeded globals left, though. A huge difference compared to the 3 left in Elk (not counting the ones in install.php), and the zero in Wedge[1].
| 1. | One, actually... I committed an unneeded global today. Lulz. I'll fix that in the next commit. |
2027
Features / Re: New revs
« on January 8th, 2014, 05:09 PM »
[master 2f7fb2c]
16 files changed, 90 insertions(+), 90 deletions(-), 2.21 KiB
* Turning all normallist classes into the unused 'list' class. This will make life easier for me later on, if I do what I'm planning to do. (16 files, boring search & replace.)
16 files changed, 90 insertions(+), 90 deletions(-), 2.21 KiB
* Turning all normallist classes into the unused 'list' class. This will make life easier for me later on, if I do what I'm planning to do. (16 files, boring search & replace.)
2028
Features / Re: New revs
« on January 8th, 2014, 04:57 PM »
[master 73ef974]
12 files changed, 135 insertions(+), 51 deletions(-), 4.00 KiB
+ Added new cache system: session-based. This is very different from all other implementations, as it holds the entire cache in memory, but from my experience, it's never more than a couple dozen kilobytes. The cache is loaded on session read (any call to the cache before that, such as retrieving $settings, will use the file cache), and saved on session write, but only if it was actually modified. Wedge also handles cache expiration manually. This is superior to my prior attempt at implementing this last week, on which I'd given up. On my system, there's about a 5% performance improvement compared to the file-based cache, but it depends on many factors and may be slower for you. The fact is, install Wedge, then switch between all cache types, and decide which one is the best for your setup. (Load.php, ManageServer.php, Subs-Cache.php, ManageServer.language.php)
+ Added a new SQL insert method, 'update', which will attempt a regular UPDATE query first, and then fall back to the normal codepath for any data set that failed to update. It's only a basic update, the condition query is taken from the first data set entry, and thus is limited to 'variable = {type:variable}'. Still, it can be useful here and there. (Class-DB.php, Load.php)
+ Added auto-optimization of the session table. It's been historically the biggest space waster in the entire table list of SMF/Wedge, and even the auto-optimize weekly task is fairly inefficient on it. It needs to be triggered more often, so I thought this could be a welcomed addition. Only doing optimization on 10% of all session removals. Should be often enough, but I'll need some testing to ensure this is an ideal number. (Load.php)
* Merged both flat and nested versions of the skin list into the same cache entry. Well, it certainly can't hurt. (Themes.php)
+ Added a placeholder for skin enabling/disabling code. Still needs the actual UI for it, of course. (Themes.php)
* Details. (ManageMaintenance.php, ManageMedia2.php, Subs-Media.php, install.php)
12 files changed, 135 insertions(+), 51 deletions(-), 4.00 KiB
+ Added new cache system: session-based. This is very different from all other implementations, as it holds the entire cache in memory, but from my experience, it's never more than a couple dozen kilobytes. The cache is loaded on session read (any call to the cache before that, such as retrieving $settings, will use the file cache), and saved on session write, but only if it was actually modified. Wedge also handles cache expiration manually. This is superior to my prior attempt at implementing this last week, on which I'd given up. On my system, there's about a 5% performance improvement compared to the file-based cache, but it depends on many factors and may be slower for you. The fact is, install Wedge, then switch between all cache types, and decide which one is the best for your setup. (Load.php, ManageServer.php, Subs-Cache.php, ManageServer.language.php)
+ Added a new SQL insert method, 'update', which will attempt a regular UPDATE query first, and then fall back to the normal codepath for any data set that failed to update. It's only a basic update, the condition query is taken from the first data set entry, and thus is limited to 'variable = {type:variable}'. Still, it can be useful here and there. (Class-DB.php, Load.php)
+ Added auto-optimization of the session table. It's been historically the biggest space waster in the entire table list of SMF/Wedge, and even the auto-optimize weekly task is fairly inefficient on it. It needs to be triggered more often, so I thought this could be a welcomed addition. Only doing optimization on 10% of all session removals. Should be often enough, but I'll need some testing to ensure this is an ideal number. (Load.php)
* Merged both flat and nested versions of the skin list into the same cache entry. Well, it certainly can't hurt. (Themes.php)
+ Added a placeholder for skin enabling/disabling code. Still needs the actual UI for it, of course. (Themes.php)
* Details. (ManageMaintenance.php, ManageMedia2.php, Subs-Media.php, install.php)
2029
Test board / Re: First Test in 2014
« on January 8th, 2014, 12:18 AM »
Hmm, looks like you managed to break footnotes...... :wow:
2030
Features / Re: One theme to rule them all?
« on January 8th, 2014, 12:13 AM »
Today I've flattened the skin system, so this last question of mine is preeeetty much the last hurdle before I can publish the source code. (Well, I'll also do a test-run of the install process, of course. I'm 66.67% sure it's broken again.)
Thus, I'd like to make sure we all agree on a 'best of the worst' solution for the general folder structure. I think we all agree[1] we can gather most PHP/CSS/JS files in src, but we need to determine the folder names, mostly (src? sources? code? Something else? What about the JS files? js, or scripts? etc.), and whether or not the Sources/*.php files should be in /src/php/ or in the /src/ root[2].
Thus, I'd like to make sure we all agree on a 'best of the worst' solution for the general folder structure. I think we all agree[1] we can gather most PHP/CSS/JS files in src, but we need to determine the folder names, mostly (src? sources? code? Something else? What about the JS files? js, or scripts? etc.), and whether or not the Sources/*.php files should be in /src/php/ or in the /src/ root[2].
| 1. | Although I'm very open to discussing other possibilities, of course. |
| 2. | Pros of having them in /src/php: easy to create new sub-folders, as is the case in SMF, Elk or current Wedge. Clean structure. Cons of having them: it takes one extra step to update the website by FTP. I don't like the idea of an extra step, hmm... |
2031
Features / Re: New revs
« on January 8th, 2014, 12:09 AM »
[master 509ea9b]
2 files changed, 34 insertions(+), 32 deletions(-), 1.17 KiB
! Skin folder loading order is important, so I restored the original order. I also rewrote the code to use the skin list cache in order to determine the top-level skin for the current skin chain. (Subs-Cache.php, Themes.php)
- Debug code. (Themes.php)
@ Note to self: need to move the skin list cache code to Subs-Cache.
2 files changed, 34 insertions(+), 32 deletions(-), 1.17 KiB
! Skin folder loading order is important, so I restored the original order. I also rewrote the code to use the skin list cache in order to determine the top-level skin for the current skin chain. (Subs-Cache.php, Themes.php)
- Debug code. (Themes.php)
@ Note to self: need to move the skin list cache code to Subs-Cache.
2032
Features / Re: New revs
« on January 7th, 2014, 07:59 PM »
* It's just one line, but it's good for my git history. (Wilderless/skin.xml)
2033
Features / Re: New revs
« on January 7th, 2014, 07:55 PM »
[master 9f36769]
23 files changed, 123 insertions(+), 117 deletions(-), 6.73 KiB
* Rewrote the skin system to use a flat folder structure. While nested folders are good to help understand how it all works, and is globally a bit faster, they make it impossible to use sub-folders elegantly in skins (and I'm all about elegance), and they take more time to update manually. (Subs-Cache.php)
* Simplified wedge_get_skin_list. A lot. It no longer even does recursion to build the array. I never thought I'd manage to do that. (ManageBoards.php, Themes.php)
- Removed css_folder initialization from loadTheme(); it was redone later in the process anyway. (Load.php)
@ Note: I'm having trouble with moving Wilderless, so I'll just be moving it in this commit, and will commit the xml changes in the next one. Also, I refrained myself from using a lambda function in the CSS file builder, but only because these things are called from the installer, too. I should probably just abruptly exit from the installer if PHP 5.3 is not found, instead of going through the templating system. Adding that to my to-do list.
23 files changed, 123 insertions(+), 117 deletions(-), 6.73 KiB
* Rewrote the skin system to use a flat folder structure. While nested folders are good to help understand how it all works, and is globally a bit faster, they make it impossible to use sub-folders elegantly in skins (and I'm all about elegance), and they take more time to update manually. (Subs-Cache.php)
* Simplified wedge_get_skin_list. A lot. It no longer even does recursion to build the array. I never thought I'd manage to do that. (ManageBoards.php, Themes.php)
- Removed css_folder initialization from loadTheme(); it was redone later in the process anyway. (Load.php)
@ Note: I'm having trouble with moving Wilderless, so I'll just be moving it in this commit, and will commit the xml changes in the next one. Also, I refrained myself from using a lambda function in the CSS file builder, but only because these things are called from the installer, too. I should probably just abruptly exit from the installer if PHP 5.3 is not found, instead of going through the templating system. Adding that to my to-do list.
2034
Features / Re: New revs
« on January 6th, 2014, 10:19 PM »
[master ae6147f]
2 files changed, 2 insertions(+), 2 deletions(-), 668 bytes
! Profile options were broken due to a typo. (ManageMemberOptions.php)
! Stats page went into a bad infinite loop, but only if visiting it in January (yeah, yeah...) (stats.js)
2 files changed, 2 insertions(+), 2 deletions(-), 668 bytes
! Profile options were broken due to a typo. (ManageMemberOptions.php)
! Stats page went into a bad infinite loop, but only if visiting it in January (yeah, yeah...) (stats.js)
2035
Archived fixes / Re: Stats are broken
« on January 6th, 2014, 10:15 PM »
Phew... Problem fixed. I'd experienced it for a few days, but thought it was only on mobile. It was also on desktop. The reason was due to Date().getMonth() returning a 0-based value, rather than 1-based, and January is 0, and Wraph simply wasn't built for a graph that ended in a zero month. Technically, the 'bug' would have fixed itself in February, but I figured, people will probably want it to work now... :P
The reason for the crash was that the whole script was caught in an infinite loop. It was totally unrelated to the jQuery version. (Yes, I'm aware that beta 3 is out, but I'd rather wait for the final release to be out, and the current beta is working just fine for me, so...)
The reason for the crash was that the whole script was caught in an infinite loop. It was totally unrelated to the jQuery version. (Yes, I'm aware that beta 3 is out, but I'd rather wait for the final release to be out, and the current beta is working just fine for me, so...)
2036
Features / Re: One theme to rule them all?
« on January 6th, 2014, 09:05 PM »
Because of the folder names I suppose?
2037
Features / Re: One theme to rule them all?
« on January 6th, 2014, 08:28 AM »
I'm more into brunettes, but thanks :P
Need more opinions!
Well, today I'll be spending most of my day watching GamesDoneQuick.com anyway, like every year at the same date now, but I'm still listening eheh.
Need more opinions!
Well, today I'll be spending most of my day watching GamesDoneQuick.com anyway, like every year at the same date now, but I'm still listening eheh.
2038
Features / Re: New revs
« on January 5th, 2014, 11:30 PM »
! Fixed wrong assets URL in JavaScript. Oops. (index.template.php) <-- just one line, not reproducing everything.
2039
Features / Re: One theme to rule them all?
« on January 5th, 2014, 11:21 PM »
Downloaded it, and I think you've got the wrong idea... ;)
Anyway, I'm still unsure where to go, right now. Should languages/ be a parent folder to all language sub-folders, or should these sub-folders be directly in the root? Should the parent folder for all things css/js/templates, hold the source files directly, or have them in another sub-folder? If not in a sub-folder, then should we have multiple sub-folders for php sources? (currently it's the case, we have media/, notifiers/ and captcha/, and I'm worried that these would 'conflict' with other top-level folders such as templates.)
PS: I fixed bbcode buttons, BTW. Sorry for the delay!
Anyway, I'm still unsure where to go, right now. Should languages/ be a parent folder to all language sub-folders, or should these sub-folders be directly in the root? Should the parent folder for all things css/js/templates, hold the source files directly, or have them in another sub-folder? If not in a sub-folder, then should we have multiple sub-folders for php sources? (currently it's the case, we have media/, notifiers/ and captcha/, and I'm worried that these would 'conflict' with other top-level folders such as templates.)
PS: I fixed bbcode buttons, BTW. Sorry for the delay!
2040
Features / Re: New revs
« on January 5th, 2014, 10:10 PM »
[master 57390d8]
1 file changed, 1 insertion(+), 1 deletion(-), 428 bytes
! Nice bug... Was calling add_hook instead of call_hook. Thankfully, I never did that anywhere else. (Feed.php)
1 file changed, 1 insertion(+), 1 deletion(-), 428 bytes
! Nice bug... Was calling add_hook instead of call_hook. Thankfully, I never did that anywhere else. (Feed.php)