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
2056
Features / Re: New revs
« on January 4th, 2014, 06:43 PM »
[master ed3e209]
4 files changed, 7 insertions(+), 17 deletions(-), 1.02 KiB
! No need for reservedVars when these are no longer put into $theme. (Profile-Modify.php)
- Removed ability to access $theme folder in skins. This never had any use anyway. (Subs-Cache.php, index.css)
* Details. (Wilderless/extra.css)
4 files changed, 7 insertions(+), 17 deletions(-), 1.02 KiB
! No need for reservedVars when these are no longer put into $theme. (Profile-Modify.php)
- Removed ability to access $theme folder in skins. This never had any use anyway. (Subs-Cache.php, index.css)
* Details. (Wilderless/extra.css)
2057
Features / Re: New revs
« on January 4th, 2014, 06:01 PM »
[master 252c2b1]
309 files changed, 4 deletions(-), 327 bytes
* Okay, moved folders up a level, as I said. Give me some time to prepare myself for a more radical move. (Themes/default/* -> Themes/)
309 files changed, 4 deletions(-), 327 bytes
* Okay, moved folders up a level, as I said. Give me some time to prepare myself for a more radical move. (Themes/default/* -> Themes/)
2058
Features / Re: New revs
« on January 4th, 2014, 05:02 PM »
[master 6872d91]
16 files changed, 38 insertions(+), 38 deletions(-), 10.75 KiB (Seriously, these patch sizes are getting more and more disconnected from reality. I won't carry on with them once I automatize log posting.)
* Fixed code to consider /Themes/default moved up one level. The actual move will happen once I manage to do it, there are always files that cause problems, so I'll have to do it from a cleaner repo. (QueryString.php, Subs-Template.php, Themes.php, index.template.php, install.php, install.sql, readme_install.html)
! Fixed some asset URLs. (Class-Editor.php, Subs-Sound.php, ManageMembergroups.template.php, ManageSettings.language.php, editor.js, register.js, suggest.js, install.sql, readme_install.html, ssi_examples.php)
16 files changed, 38 insertions(+), 38 deletions(-), 10.75 KiB (Seriously, these patch sizes are getting more and more disconnected from reality. I won't carry on with them once I automatize log posting.)
* Fixed code to consider /Themes/default moved up one level. The actual move will happen once I manage to do it, there are always files that cause problems, so I'll have to do it from a cleaner repo. (QueryString.php, Subs-Template.php, Themes.php, index.template.php, install.php, install.sql, readme_install.html)
! Fixed some asset URLs. (Class-Editor.php, Subs-Sound.php, ManageMembergroups.template.php, ManageSettings.language.php, editor.js, register.js, suggest.js, install.sql, readme_install.html, ssi_examples.php)
2059
Off-topic / Re: Happy Holidays !
« on January 4th, 2014, 03:37 PM »
Who's Jeff? Not Jeff Lewis right..?
I don't have plans to take over the forum world. I had those in 2010 with Pete. But he went too much further from my original project (basically take Noisen and make it into a platform), and as years went by, it was clear the advance we had (HTML 5 stuff, jquery etc) was being canceled by the competition catching up with these important things while Pete was postponing Wedge to finish complicated Admin features he had his eyes on. It's partly my fault so I won't blame it all on him, but it's been a while since I've wanted to be at the top. Now I just want to be proud of what I did. And get something good out of it, even if it's not anything I wanted originally.
Seriously, ElkArte is doing fine so they're what Wedge ambitioned to be in 2010 (a fuck you to a dying SMF). Wedge is just a high five to power admins who don't like being held by the hand and want to put all their strength into something they can be proud of.
I'm just sad that you've been ignoring your users. Had you given some prior warning, it would have been okay. But at this point, even I have lost hope to see you release something. It's too bad because I really loved protendo's strengths, they were so close in spirit to my old work on Noisen.
"We will always have Vienna."
I don't have plans to take over the forum world. I had those in 2010 with Pete. But he went too much further from my original project (basically take Noisen and make it into a platform), and as years went by, it was clear the advance we had (HTML 5 stuff, jquery etc) was being canceled by the competition catching up with these important things while Pete was postponing Wedge to finish complicated Admin features he had his eyes on. It's partly my fault so I won't blame it all on him, but it's been a while since I've wanted to be at the top. Now I just want to be proud of what I did. And get something good out of it, even if it's not anything I wanted originally.
Seriously, ElkArte is doing fine so they're what Wedge ambitioned to be in 2010 (a fuck you to a dying SMF). Wedge is just a high five to power admins who don't like being held by the hand and want to put all their strength into something they can be proud of.
I'm just sad that you've been ignoring your users. Had you given some prior warning, it would have been okay. But at this point, even I have lost hope to see you release something. It's too bad because I really loved protendo's strengths, they were so close in spirit to my old work on Noisen.
"We will always have Vienna."
2060
Features / Re: One theme to rule them all?
« on January 4th, 2014, 09:45 AM »
Didn't I already fix that one last night..? The avatars are showing up for me, at least. Cache issue? Try to reload the page.
Oh well, no worries, I've moved the folder around again; this should ensure that your cache is not read. Plus, it saves two bytes of bandwidth per avatar load. (I'm that sick.)
Oh well, no worries, I've moved the folder around again; this should ensure that your cache is not read. Plus, it saves two bytes of bandwidth per avatar load. (I'm that sick.)
2061
Features / Re: One theme to rule them all?
« on January 3rd, 2014, 08:45 PM »
I actually fixed that an hour ago. How timely! But I haven't committed or uploaded it yet, because it needs some further testing (I replaced a variable across the codebase), and right now I'm busy watching TV. What, TV doesn't matter? Not when it's Community and Sherlock! :P
2062
Features / Re: New revs
« on January 3rd, 2014, 01:59 PM »
[master a226178] -- this is *all* I had left to commit apart from JS and CSS tweaks that I'm taking years to complete, hmm...
12 files changed, 82 insertions(+), 51 deletions(-), 3.61 KiB
+ Added ability to choose your cache type, so, most likely, to force the file cache if another cache type is discovered. This is due to the fact that wedge.org's APC cache is much less efficient than the file cache. I could probably tweak some php.ini settings to fix that, but let's face it, the file cache is often just as efficient as any other cache type, so in addition to this, I've made file caching the default setting. Then you can enable debug mode to check your performance numbers, and cycle through the various caching options available to you, and decide which one is best for your server. (Class-System.php, ManageServer.php, ManageSettings.php, Settings.php, Settings_bak.php, ManageSettings.language.php)
* cache_get_data now accepts an extra callback parameter where you can put a cache generation lambda function that returns the data to be cached. (Subs-Cache.php)
! Fixed warning message for users without any contact lists. (Class-System.php)
! Settings.php data saving didn't allow for select-box-based variables. (ManageServer.php)
! wesql::fetch_all and fetch_rows needed some help in case the original request returned no results. (Class-DB.php)
* Commenazi, and details. (index.php, Credits.php)
@ Note: I'd originally started working on a session-based cache, and was thrilled by the performance improvement (about 10% compared to file-based), but: (1) it depends on whether your database is on your server or a dedicated server, and even whether that dedicated server is efficient (or you could just disable database sessions), (2) I don't think it's worth the hassle overall. While it's interesting to fetch and store all cache data within one single free database call, it also takes more time to unserialize. I'm still keeping the idea around (possibly in a new branch), but right now, I don't want to deal with the TTL and expiration issues this technique implied.
12 files changed, 82 insertions(+), 51 deletions(-), 3.61 KiB
+ Added ability to choose your cache type, so, most likely, to force the file cache if another cache type is discovered. This is due to the fact that wedge.org's APC cache is much less efficient than the file cache. I could probably tweak some php.ini settings to fix that, but let's face it, the file cache is often just as efficient as any other cache type, so in addition to this, I've made file caching the default setting. Then you can enable debug mode to check your performance numbers, and cycle through the various caching options available to you, and decide which one is best for your server. (Class-System.php, ManageServer.php, ManageSettings.php, Settings.php, Settings_bak.php, ManageSettings.language.php)
* cache_get_data now accepts an extra callback parameter where you can put a cache generation lambda function that returns the data to be cached. (Subs-Cache.php)
! Fixed warning message for users without any contact lists. (Class-System.php)
! Settings.php data saving didn't allow for select-box-based variables. (ManageServer.php)
! wesql::fetch_all and fetch_rows needed some help in case the original request returned no results. (Class-DB.php)
* Commenazi, and details. (index.php, Credits.php)
@ Note: I'd originally started working on a session-based cache, and was thrilled by the performance improvement (about 10% compared to file-based), but: (1) it depends on whether your database is on your server or a dedicated server, and even whether that dedicated server is efficient (or you could just disable database sessions), (2) I don't think it's worth the hassle overall. While it's interesting to fetch and store all cache data within one single free database call, it also takes more time to unserialize. I'm still keeping the idea around (possibly in a new branch), but right now, I don't want to deal with the TTL and expiration issues this technique implied.
2063
Features / Re: One theme to rule them all?
« on January 2nd, 2014, 08:05 PM »
Thanks, I'll look into these. They show up in my error log anyway, but it's good to know it's still buggy.
Well, the second one isn't an error, it's actually some debug code I forgot to remove. I've reuploaded the slower, APC-based version so I don't have to revert my current cache tests. I'm trying to 'break' the $_SESSION-based caching system, but unfortunately it's not very encouraging, because the performance is pretty much the same as the file-based cache (even though it only stores one entry in the database), and I don't know if it's worth the huge hassle. I know that saving bits of processing power, little by little, is what brought Wedge to be so fast, but OTOH the fastest performance improvement I ever got with Wedge is by disabling the APC cache, so, whatever...
Well, the second one isn't an error, it's actually some debug code I forgot to remove. I've reuploaded the slower, APC-based version so I don't have to revert my current cache tests. I'm trying to 'break' the $_SESSION-based caching system, but unfortunately it's not very encouraging, because the performance is pretty much the same as the file-based cache (even though it only stores one entry in the database), and I don't know if it's worth the huge hassle. I know that saving bits of processing power, little by little, is what brought Wedge to be so fast, but OTOH the fastest performance improvement I ever got with Wedge is by disabling the APC cache, so, whatever...
2064
Features / Re: One theme to rule them all?
« on January 2nd, 2014, 05:50 PM »
And that's it. I just updated wedge.org (took 45 minutes, because I had to convert everything, rather than just reinstall from scratch, as I would have done on a regular 'test' forum...), and it's looking good now. Well, it's the same as one hour ago, but you get what I mean.
The main difference is that the forum you're seeing now, no longer relies on themes.
I'm a bit disappointed with performance, as it's pretty much the same as before I removed themes. But Wedge is already as fast as it can be, so I'm not surprised a 5% increase (or anything like that) isn't noticeable. I did my tests on page 157 of the New Revs topic, and the page was consistently loading between 0.06s and 0.14s. If I disable the file cache and rely only on APC, I get between 0.06s and 1.02s, so... Well, that APC really is some fine piece of crap! I need to focus on committing my new version of the cache system.
Please post here if you notice any issue regarding the site update! Thanks.
The main difference is that the forum you're seeing now, no longer relies on themes.
I'm a bit disappointed with performance, as it's pretty much the same as before I removed themes. But Wedge is already as fast as it can be, so I'm not surprised a 5% increase (or anything like that) isn't noticeable. I did my tests on page 157 of the New Revs topic, and the page was consistently loading between 0.06s and 0.14s. If I disable the file cache and rely only on APC, I get between 0.06s and 1.02s, so... Well, that APC really is some fine piece of crap! I need to focus on committing my new version of the cache system.
Please post here if you notice any issue regarding the site update! Thanks.
2065
Plugins / Re: Lang. files?
« on January 2nd, 2014, 04:30 PM »
Well, Pete did that for BBCode, and we know how it ended... No UI to modify the codes, and if I happen to consider changing the default code for a tag, I'll have to ditch my table and refill it.
Also, it doesn't help with uploading modified files by FTP... :^^;:
Unless maybe Wedge started doing something revolutionary, like updating any and all of its files through the github repo... In which case, well, I guess for one it totally rocks your house, and for two it's a recipe for disaster... :P
(Although, I'll point out that it worked quite well with Aeva Media, but it was only with the site list, NOT with the mod's files!)
Also, it doesn't help with uploading modified files by FTP... :^^;:
Unless maybe Wedge started doing something revolutionary, like updating any and all of its files through the github repo... In which case, well, I guess for one it totally rocks your house, and for two it's a recipe for disaster... :P
(Although, I'll point out that it worked quite well with Aeva Media, but it was only with the site list, NOT with the mod's files!)
2066
Features / Re: New revs
« on January 2nd, 2014, 01:34 PM »
[master 0e0a700]
15 files changed, 40 insertions(+), 45 deletions(-), 2.29 KiB
* Renamed $settings['avatar_directory'] to 'avatar_dir', for consistency with other variables. (ManageAttachments.php, Profile-Modify.php, Admin.language.php, install.sql)
* Renamed theme_id to source_id in some function, to avoid confusion. (ManageLanguages.php)
* Renamed $settings['avatar_url'] to AVATARS where possible. That's not a lot, but it doesn't really matter. (Load.php, Subs.php, Profile.template.php)
- Removed $context['avatar_url'], never used AFAIK. (Profile-Modify.php)
- Removed another file that didn't get deleted properly. (Smileys/.htaccess)
- Removed unused globals. (ManageLanguages.php, ManageSmileys.php, Aeva-Gallery.php, Subs-Media.php, Themes.template.php)
15 files changed, 40 insertions(+), 45 deletions(-), 2.29 KiB
* Renamed $settings['avatar_directory'] to 'avatar_dir', for consistency with other variables. (ManageAttachments.php, Profile-Modify.php, Admin.language.php, install.sql)
* Renamed theme_id to source_id in some function, to avoid confusion. (ManageLanguages.php)
* Renamed $settings['avatar_url'] to AVATARS where possible. That's not a lot, but it doesn't really matter. (Load.php, Subs.php, Profile.template.php)
- Removed $context['avatar_url'], never used AFAIK. (Profile-Modify.php)
- Removed another file that didn't get deleted properly. (Smileys/.htaccess)
- Removed unused globals. (ManageLanguages.php, ManageSmileys.php, Aeva-Gallery.php, Subs-Media.php, Themes.template.php)
2067
Features / Re: Plugin revs
« on January 2nd, 2014, 01:26 PM »
[master ce04274]
10 files changed, 14 insertions(+), 17 deletions(-), 7.89 KiB (<--- What?!)
* Skin selector updated to remove an unused string and add a new string to replace a risky dependency. (skin_selector/*)
* Fascinating $helptxt update. (Birthday-Admin.english.php, Calendar.language.php, ManageCalendar.language.php)
- Unneeded global. (WedgeDesk.template.php)
10 files changed, 14 insertions(+), 17 deletions(-), 7.89 KiB (<--- What?!)
* Skin selector updated to remove an unused string and add a new string to replace a risky dependency. (skin_selector/*)
* Fascinating $helptxt update. (Birthday-Admin.english.php, Calendar.language.php, ManageCalendar.language.php)
- Unneeded global. (WedgeDesk.template.php)
2068
Features / Re: New revs
« on January 2nd, 2014, 12:34 PM »
[master 62c5304]
455 files changed, 17 insertions(+), 37 deletions(-), 6.40 KiB
* With most of the theme removal completed, it's time to get to the meat of it... Moved these folders to /assets/. Ah, finally!!
/Themes/default/images (to its root)
/Themes/default/fonts (to fonts)
/Themes/default/aeva (to aeva)
/Smileys/ (to smileys)
/avatars/ (to avatars)
* Updated code to match new URLs or simply remove support for per-theme image folders. Don't worry, I've got something in the works that will be ten times better than that crappy system anyway! (QueryString.php, Themes.php, Themes.language.php, install.php, install.sql)
- Removed a custom file I shouldn't have committed. Not a biggie, though, it had like 2 lines. (Wilderless/custom.css)
* Commenazi. (SSI.php, Subs-Template.php)
455 files changed, 17 insertions(+), 37 deletions(-), 6.40 KiB
* With most of the theme removal completed, it's time to get to the meat of it... Moved these folders to /assets/. Ah, finally!!
/Themes/default/images (to its root)
/Themes/default/fonts (to fonts)
/Themes/default/aeva (to aeva)
/Smileys/ (to smileys)
/avatars/ (to avatars)
* Updated code to match new URLs or simply remove support for per-theme image folders. Don't worry, I've got something in the works that will be ten times better than that crappy system anyway! (QueryString.php, Themes.php, Themes.language.php, install.php, install.sql)
- Removed a custom file I shouldn't have committed. Not a biggie, though, it had like 2 lines. (Wilderless/custom.css)
* Commenazi. (SSI.php, Subs-Template.php)
2069
Plugins / Re: Lang. files?
« on January 2nd, 2014, 01:18 AM »
Still bumping for ideas on how to deal with the languages repo.
Possible solutions:
1- Just have everything in a single folder. Very, very messy, but whatever.
2- Keep English and French in the root, and have other versions in sub-folders. Meaning I'd probably drop support for other languages on wedge.org if I can't bother to update these folders here.
3- Have all languages in different subfolders, and expect me to systematically update my root languages folder with the files, everytime I apply a change. Don't count too much on that.....
4- Use some sort of symlink system that would allow me to use a separate repo with one folder per language, but have all of these folders' files (or at least most of the current ones) show up in my local Wedge repo's language folder. This is what I've been looking into, but I just have one problem: I have no idea how to do that. I'm aware that NTFS allows for 'proper' symlinks, i.e. hardlinks à la Linux, not silly 'shortcuts' à la Windows 95, I even have a program that moves games around on my hard drives and still lets them run without reinstalling (thanks to hardlinking), but I don't know how I'd do that with Wedge, plain and simple.
So... Again, opinions welcome! I'd like to do the languages repo next, really. That's REALLY the very first repo I'll be expecting contributions to, and I can't wait for that. (At the current point, it's unlikely that the language files are going to change a lot. Manipulating them was Pete's habit, but personally I prefer to avoid playing with them if I don't have to.)
Possible solutions:
1- Just have everything in a single folder. Very, very messy, but whatever.
2- Keep English and French in the root, and have other versions in sub-folders. Meaning I'd probably drop support for other languages on wedge.org if I can't bother to update these folders here.
3- Have all languages in different subfolders, and expect me to systematically update my root languages folder with the files, everytime I apply a change. Don't count too much on that.....
4- Use some sort of symlink system that would allow me to use a separate repo with one folder per language, but have all of these folders' files (or at least most of the current ones) show up in my local Wedge repo's language folder. This is what I've been looking into, but I just have one problem: I have no idea how to do that. I'm aware that NTFS allows for 'proper' symlinks, i.e. hardlinks à la Linux, not silly 'shortcuts' à la Windows 95, I even have a program that moves games around on my hard drives and still lets them run without reinstalling (thanks to hardlinking), but I don't know how I'd do that with Wedge, plain and simple.
So... Again, opinions welcome! I'd like to do the languages repo next, really. That's REALLY the very first repo I'll be expecting contributions to, and I can't wait for that. (At the current point, it's unlikely that the language files are going to change a lot. Manipulating them was Pete's habit, but personally I prefer to avoid playing with them if I don't have to.)
2070
Off-topic / Re: Happy Holidays !
« on January 2nd, 2014, 12:52 AM »You know, I was thinking the same..I have an urge to release Protendo now, although there are much more I'd like to add to it. And there are some bugs in it. But not everything must be in right now anyway..just have to make sure I don't corner myself with features that cannot be easily changed later on. :D
Seriously... It's not funny. Closing down your website every other day, without any explanation, is not respectful of your users, and doesn't encourage them to post over there, because they can never know if their posts will survive your mood changes. People remember Blocweb, they remember ViennaBBS, they'll remember Protendo. Do you really, really want them to remember them for the bad reasons...?