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
5191
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...?
5192
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...?
5193
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...
5194
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...!
5195
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.)
5196
No problem. I told you to look at our changelogs :P
5197
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.)
5198
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.
5199
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
5200
Other software / Re: Has SMF Gotten Slower?
« on May 17th, 2012, 12:22 AM »
+1.
5201
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...
5202
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...)
5203
It really is toy money innit... ;)
5204
Features / Re: Action buttons: positioning
« on May 16th, 2012, 11:01 AM »
Quote from Arantor on May 15th, 2012, 10:42 PM
Therein lies the problem, getting it to purge the cache does also imply having it able to purge other things, like when folks use memcache or whatever, which the current cache doesn't deal with either.
Do you mean the clear cache function doesn't clear non-file cache alternatives...?
Quote
I really think the whole 'number at the end of likes' structure would work better. As it stands you get the number before the Like wording and you get the extra space underlined when hovering because it's all part of the link.
I totally agree, and it was my plan to move it to after the word, actually... Because it looks like it's two icons side to side, so it's a bit unbalanced with the text coming to the right.

However, there's the minor problem of what the text should say. Which is why I haven't tackled it yet...

(like icon) (empty) Like
Pressing Like.
(unlike icon) (1) Unlike
It sort of implies, "1 person unlikes this"...
So, it should say:
(like icon) (1) Like/Likes whatever you want that is positive...
And on hover, have the mini-menu open with a "(unlike icon) Unlike" link among other things.
Quote
Converting it to [icon] Like ( number ) means the thumb icon + wording can be the action itself with the number being the popup. The UI aspect gets covered, there's somewhere to put the popup invocation and it deals with the underlining that looks weird otherwise.
I didn't think you'd care about such a little detail as the underlining... ;)
Actually, I did notice it and I hate that kind of thing -- it can be fixed very easily by simply duplicating the link and adding a space in between...
Quote from live627 on May 16th, 2012, 01:02 AM
The main thing I don't like about the mini-menu is it's too crowded. The recent restyling helped on that front since the borders are gone.
They're not gone, they're just no longer transparent ;)
Quote
Some extra padding in between the links would help as well.
I tried that, but wasn't happy with it.
Quote
The hover state would look better without the underline, and it might also look better if the background changed color, not the text.
Now, here's the thing...
Do you remember our blog style on wedge.org when I was using the Noisen codebase...?
If not, open an account (or use it if you already have one) at noisen.com, go to http://nao.noisen.com/ and check out the "Action" button on the upper right of any post... This is something of an innovation (SMF-wise) that I strived not to reproduce in Wedge, but the more I played with my layouts, the more I felt compelled to go there... And pretty much unaware, because I only recently realized that even the word 'Action' was from there. (It's how the More button is called in Mobile mode... And will probably even be renamed to Actions everywhere once I decide to go ahead and merge the Modify link and the Quick Edit button together into a Quick Edit button with a mini-menu to open a full edit version...)
Quote
Sorry for the nitpicking. Both my brother and my mother are graphic designers for our family book publishing company and I think it's rubbing off onto me.
I'm an amateur design. My designs suck. I'm always glad to hear suggestions on where I could improve Wedge's layouts.
Heck, Pete knows quite well that I'm constantly struggling with my bad taste -- he has to cope, along with me, with numerous style changes to Weaving that I'm applying to admins only (custom.admin.css, yay!), so right now we both have Calibri as our main font in Wedge and it'll probably change again before you know it... :P
Posted: May 16th, 2012, 10:29 AM

(And just to be clear: too many fonts in the kitchen!! I'm aware of that!!)
Posted: May 16th, 2012, 10:34 AM
Quote from Nao on May 16th, 2012, 10:34 AM
Quote
The hover state would look better without the underline, and it might also look better if the background changed color, not the text.
Now, here's the thing...
The thing is that it has a styling like you like ;)
(Forgot to be clear on this...)
5205
Features / Re: New revs - Public comments
« on May 16th, 2012, 09:55 AM »
Oh crap, I don't know what to answer to Pete's post... :^^;:

John, it's just a reference to Lucky Luke...

Re: thoughts, indeed $last_thought was an error on my part.
Also, it's amusing that you put id_master and id_parent into a variable - I did the same yesterday ;) Hadn't come to commit yet though... It's part of my process to attempt to show 'clean' thoughts after a reply.