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
5176
Features / Re: Action buttons: positioning
« on May 17th, 2012, 08:46 PM »
auto = default, quite simply put... ;)
5177
Features / Re: Action buttons: positioning
« on May 17th, 2012, 05:00 PM »
Okay... I *think* it's because some browsers don't consider that 'left: auto' is the same as 'left: 0'... I don't know why, eh.
But it seems to work when I do it that way... Meh.
5178
Features / Re: Action buttons: positioning
« on May 17th, 2012, 04:54 PM »
Menus, please :P
(Trying to keep this on-topic... Just that I don't want long posts about the cache stuff to kill the action button discussion ;))
Oh BTW, I'm trying to go back to relative positioning and figure out why exactly it fails in iOS etc...

Will answer your post once I'm done!
5179
Features / Re : Rewriting the skin file parser...
« on May 17th, 2012, 03:31 PM »
Quote from Arantor on May 17th, 2012, 03:16 PM
SMF 1 has no file cache.
(Which is why I switched to SMF 2 in the first place... and, because it was in private beta, how I got into the SMF community after a couple of years of just using SMF1 and posting on my own forums. Anyway -- the file cache never really helped performance on my old server and moving it to a new server helped. I've always been worried about performance in general, and it shows in Wedge...)
Quote
The difference as compared to SMF 2 is though, when you're starting out, the cache miss frequency will be much higher due to low traffic, so in starting out (and, unsurprisingly, prime shared hosting territory) you're not only not benefitting much from the cache because it expires too quickly for the low traffic, you're also paying the overhead attached to it too.
Yeah, that would explain a lot... (Although my forum already had 200k+ posts when I tried making the switch.)
Quote
I think the file cache is worth doing. The problems with the cache subsystem as they stand are:
1. It's totally I/O bound. As nend's experiments show, there's little you can do to optimise that.
It's pretty much up to PHP to keep things in memory for other simultaneous sessions, yeah.
Quote
So the speed benefit is finite. There are advantages to using the SQLite system as nend suggested, though.
But again, it's mostly I/O bound... (i.e. whether SQLite can deal with the disk access faster than a pure PHP call is up to the machine and setup, I guess...?)

Relying on SQLite, to me, is a bit like creating temp tables in MySQL that bear the names of the cache keys :) Eh, that could be an idea... :lol:
Quote
2. Things are not best using the cache, but that's not systemic to the cache itself; the fact $settings is not cached by things other than the file cache is not the fault of the file cache, it is the fault of the housekeeping that drives all of the caching system. Transferring the cache settings to be in Settings.php means it's possible to cache $settings, something not possible in Wedge currently except through the file cache (which is better than nothing)
You mean it's not possible without a similar rewrite, right..?
Quote
3. Clearing the non-file caches is difficult and unreliable. Clearing the file cache or even parts of the file cache is trivial by comparison.
Isn't it possible to send a global timeout notice or something to the cache handlers...?
5180
Features / Re : Rewriting the skin file parser...
« on May 17th, 2012, 03:22 PM »
I'll deal with the OT later, but menus -- I don't understand what you're trying to say. Any real-life cases of a layout change that happens often enough for absolutely-positioned menus to be a big con for you...?
5181
Features: Posts & Topics / Re: Likes
« on May 17th, 2012, 03:08 PM »
Well, we can always add this later and do a small script to import all data from the likes table of course...
5182
Features / Re: Action buttons: positioning
« on May 17th, 2012, 02:59 PM »
Quote from Arantor on May 17th, 2012, 12:57 PM
Quote
After SMF 2.0 you mean?
Yup, as far as I know it was patched in their Git repo, along with the fact that the cache level and type are now globals and not in $settings. (So that the settings table can actually be cached and read properly from cache, regardless of which cache we're talking about)
So, it's fixable right...?

Your posts make me feel like it's a bad idea to use the file cache for... pretty much anything?!

Re: topic, so I've made a working prototype that uses the parent's offset position to show the element, rather than relative+nested absolute positioning (which always had my preference).

Pros:
- it will work everywhere... hopefully...
- it's relatively easier to understand what it does
- no, or less, esoteric hacks that even I can barely understand

Cons:
- if you resize the window while the menu is open (e.g. in Opera if I press F4 to show or hide the sidebar that holds my tab list), it'll be repositioned somewhere else (usually not under the parent item!)
- if you modify the CSS layout or HTML structure while a menu is open, the same will happen...
- and it does the same even if the menu isn't open, unless you store the parent's coordinates on all mouseenter events (which is what I'm doing right now, it's probably a tad slower too...)
- it's not as cool.
- it takes a bit more JS code (~20 bytes...)
- did I say more code..?
- and more code, too.

I could apply this to the main menu, too... This would avoid similar issues with IE8, although I fixed them with an odd hack as mentioned in the other topic.

I'm not exactly sure at this point, which way I should follow...
Posted: May 17th, 2012, 02:48 PM

Oh... Also: absolute positioning makes it harder to work in non-JavaScript environments, unless I'm very careful. Basically, I'd need to add position:relative to the parent in CSS, and remove it through JS to allow for positioning relative to the document. Meh...!
5183
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 17th, 2012, 01:34 PM »
I'm positive that I specified it's a SMF bug. (ie everytime I fix a bug, I check the SMF 2.0 codebase to see if it's there too. If it is, I specify it in the changelog so that the SMF team can fix it as well.)
5184
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 17th, 2012, 01:02 PM »
No problem. I told you to look at our changelogs :P
5185
Bug reports / Re: SMF bug 4905 (signature length verified before preparsecode)
« on May 17th, 2012, 12:06 PM »
Hey emanuele, since I see you're online -- hope you didn't miss my SMF/Wedge bug fix related to this feature ;) (i.e. a regex was missing the 'global' modifier and as a result it incorrectly calculated the size.)
5186
Features: Posts & Topics / Re: Likes
« on May 17th, 2012, 10:59 AM »
Is it as desired, that we're not caching likes in the posts table...? (ot topic table even? per first-post or for all posts in the topic?)

I could see it as an interesting sort method, even if we still need to tell if our own likes are in these.
5187
Features / Re: Action buttons: positioning
« on May 17th, 2012, 10:34 AM »
Quote from Arantor on May 16th, 2012, 02:51 PM
Quote
Do you mean the clear cache function doesn't clear non-file cache alternatives...?
Correct. I believe SMF has patched it as best possible given the nature of the caches though.
After SMF 2.0 you mean?
What should I do? Because I liked the idea of caching this... (Or at least I should do some benchmarking.)
Quote
I get what you're saying but I don't think it's that big a deal to be honest. How about we try it and see how people react?
I'll try, when I'm done with what I'm working on (several things.)

Re: topic, I'm pissed. I just discovered that my iPod is having the hidden user menu bug AGAIN... I had it fixed yesterday. Then it didn't work correctly in Opera and Safari (wrong positioning.) So I rewrote the code to use the main menu technique, and it worked... Except I didn't test in my iPod. And it fails exactly the same way. >_<
Posted: May 17th, 2012, 10:22 AM

Ugliest hack ever... (thankfully, for iOS stylesheets only)

Code: [Select]
h4 .mime
position: absolute
5188
Other software / Re: Has SMF Gotten Slower?
« on May 17th, 2012, 12:22 AM »
+1.
5189
Features / Re: New revs - Public comments
« on May 16th, 2012, 06:22 PM »
Nope, it wasn't... :)

Yet, I still have issues with my current work on this... I'm trying to get Wedge to correctly determine that a deleted thought was deleted if it's being retrieved by a child as reference. Currently, if you delete a parent, it'll say "@> Something". Grmpf... I'd like for it to say something like "@(Deleted)> Something." Or just "Something", actually...
5190
Features / Re: New revs - Public comments
« on May 16th, 2012, 06:10 PM »
Quote from Nao on May 16th, 2012, 09:55 AM
Re: thoughts, indeed $last_thought was an error on my part.
I take that back... :P
$last_thought = id_thought.
I'm doing strlen($last_thought) because that's what it looks like when it's serialized... (I know it's a bit odd to do a search on a serialized array, but it's always going to be stored the same way, so why bother...)