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
3256
Archived fixes / Re: Flexbox bug
« on April 5th, 2013, 06:36 PM »
Problem is -- I disabled flexbox yesterday, and don't think I've restored it since..? So how would the bug show up?
3257
Plugins / Re: Hook parameters...
« on April 5th, 2013, 05:04 PM »
Who did what? The PHP team or SMF team..?
It just seems like the SMF team went through this pain and found the better solution, and I've been trying to reinvent the wheel... I probably should have used that time on something more constructive ;)
Anyway -- now we now what to expect: if we want to give a hook the ability to modify a variable, we have to add the ampersand. Otherwise, call_hook will make only provide a copy of it. Good to know for future hooks, eh..?
It just seems like the SMF team went through this pain and found the better solution, and I've been trying to reinvent the wheel... I probably should have used that time on something more constructive ;)
Anyway -- now we now what to expect: if we want to give a hook the ability to modify a variable, we have to add the ampersand. Otherwise, call_hook will make only provide a copy of it. Good to know for future hooks, eh..?
3258
Features / Re: Github & stuff
« on April 5th, 2013, 04:30 PM »
Welcome to the madness that is called git... :lol:
3259
Plugins / Re: Hook parameters...
« on April 5th, 2013, 12:54 PM »
So... Here are my findings on this.
I spent an hour trying to work it around -- it was possible to do call_hook('hook_name', &$val, &$val1, &$val2...) in PHP 4.x, but not in PHP 5.x, because of the dreaded 'call-time by reference deprecated', which is fine by me... So, what about removing the ampersands? Fine. In call_hook, func_get_args() will return the proper list of variables... But a copy of them, not references to them. So, after the variables are modified by the actual hooks, there is no way to return these values to their actual owners.
Another solution was to do debug_backtrace(), and accessing the argument list from that object, because 'args' would hold references to the actual variables, rather than their values. Well, I naively implemented that (it makes call_hook about 50% slower (not counting the execution time of the hooks themselves), which is alright considered it's not called a lot and it's super fast anyway), and unfortunately it looks like this is not the case in PHP 5... No references. I read somewhere that you need to pass an ampersand explicitly in the call anyway, so it's a PHP4-only trick, eh... I guess?
At any rate, variable arguments lose references in PHP 5. That's something we'll have to accept...
So, with the current implementation in Wedge, i.e. call_hook('hook_name', array(&$byref)), removing the ampersand is NOT A CONVENIENCE. I repeat, it DOES NOT HELP AT ALL. The array() call is there to remove PHP's deprecation warning -- so that we can freely choose whether to pass a reference or a copy. If you do not add an ampersand to every variable, the hooks will not be able to modify them, regardless of whether they add ampersands in THEIR own function declaration.
Again: if Wedge called the hooks directly without going through call_hook(), it WOULD be possible to modify the variables directly. But because we have to go through an intermediate, and said intermediate can't explicitly require references, it's not possible.
So: http://wedge.org/do/thoughts/?in=7837#t7842 <--- this, is wrong in our particular case.
We *have* to use ampersands in our call_hook() calls, if we intend to provide for the ability to modify a variable. Which we don't always want, anyway...!
:edit: Just saw your post, John.
I spent an hour trying to work it around -- it was possible to do call_hook('hook_name', &$val, &$val1, &$val2...) in PHP 4.x, but not in PHP 5.x, because of the dreaded 'call-time by reference deprecated', which is fine by me... So, what about removing the ampersands? Fine. In call_hook, func_get_args() will return the proper list of variables... But a copy of them, not references to them. So, after the variables are modified by the actual hooks, there is no way to return these values to their actual owners.
Another solution was to do debug_backtrace(), and accessing the argument list from that object, because 'args' would hold references to the actual variables, rather than their values. Well, I naively implemented that (it makes call_hook about 50% slower (not counting the execution time of the hooks themselves), which is alright considered it's not called a lot and it's super fast anyway), and unfortunately it looks like this is not the case in PHP 5... No references. I read somewhere that you need to pass an ampersand explicitly in the call anyway, so it's a PHP4-only trick, eh... I guess?
At any rate, variable arguments lose references in PHP 5. That's something we'll have to accept...
So, with the current implementation in Wedge, i.e. call_hook('hook_name', array(&$byref)), removing the ampersand is NOT A CONVENIENCE. I repeat, it DOES NOT HELP AT ALL. The array() call is there to remove PHP's deprecation warning -- so that we can freely choose whether to pass a reference or a copy. If you do not add an ampersand to every variable, the hooks will not be able to modify them, regardless of whether they add ampersands in THEIR own function declaration.
Again: if Wedge called the hooks directly without going through call_hook(), it WOULD be possible to modify the variables directly. But because we have to go through an intermediate, and said intermediate can't explicitly require references, it's not possible.
So: http://wedge.org/do/thoughts/?in=7837#t7842 <--- this, is wrong in our particular case.
We *have* to use ampersands in our call_hook() calls, if we intend to provide for the ability to modify a variable. Which we don't always want, anyway...!
:edit: Just saw your post, John.
3260
Plugins / Hook parameters...
« on April 5th, 2013, 09:55 AM »
I'm stumped, Pete...
I tested some pass-by-ref stuff on my plugin, and it looks like it's doing exactly the reverse of what you said:
call_hook('receiving', array(&$var)) associated with either receiving($var) or receiving(&$var) WORK.
call_hook('receiving', array($var)) associated with either receiving($var) or receiving(&$var) DO NOT WORK.
You said that technically, the second solution is the right one, as long as &$var is used in receiving().
My concern stems from the fact that the call_hook function sends an ARRAY of variables, i.e. their VALUES. From the moment you send an array, the call_hook function can no longer access the array values as references, so it can't pass them as refs either...
It makes no sense to me.
Heck, I think we can also easily do away with the arrays.
Anyone knows anything about these? This is the first time I'm looking into plugins, really, and never used call_hook before for any reason whatsoever... ;)
I tested some pass-by-ref stuff on my plugin, and it looks like it's doing exactly the reverse of what you said:
call_hook('receiving', array(&$var)) associated with either receiving($var) or receiving(&$var) WORK.
call_hook('receiving', array($var)) associated with either receiving($var) or receiving(&$var) DO NOT WORK.
You said that technically, the second solution is the right one, as long as &$var is used in receiving().
My concern stems from the fact that the call_hook function sends an ARRAY of variables, i.e. their VALUES. From the moment you send an array, the call_hook function can no longer access the array values as references, so it can't pass them as refs either...
It makes no sense to me.
Heck, I think we can also easily do away with the arrays.
Anyone knows anything about these? This is the first time I'm looking into plugins, really, and never used call_hook before for any reason whatsoever... ;)
3261
Off-topic / Re: A simple PHP extension... wut?
« on April 5th, 2013, 12:41 AM »
Reminds me of when I made my first suggestions to the SMF team... ;)
3262
Plugins / [Plugin] Re: User Mentions v1.0 (9th March 2013)
« on April 4th, 2013, 10:47 PM »
Uploaded another version, which will excite @Dragooon because now the popup will only show unread items ;)
I also added a limit of 10 items in the popup, it's totally arbitrary though, maybe it should be higher..? Or unlimited?
There are also a few bugs in this version, but I don't have time to work on them tonight, so it'll have to wait, sorry. :)
Design is also still a WIP...
PS: everybody please like this post, so I can get some 'easy to remove' notifications... Thanks ;)
I also added a limit of 10 items in the popup, it's totally arbitrary though, maybe it should be higher..? Or unlimited?
There are also a few bugs in this version, but I don't have time to work on them tonight, so it'll have to wait, sorry. :)
Design is also still a WIP...
PS: everybody please like this post, so I can get some 'easy to remove' notifications... Thanks ;)
3263
The Pub / Re: Don't update log_online for certain actions
« on April 4th, 2013, 07:43 PM »
Look at it when you have a minute, and tell me if that's okay.
Considering I did multiple concessions in this one (including getting rid of the '.xml' to 'feed' action converter for SMF... That one was hard to part with >_<), if you're not happy, then you need to tell me...
Considering I did multiple concessions in this one (including getting rid of the '.xml' to 'feed' action converter for SMF... That one was hard to part with >_<), if you're not happy, then you need to tell me...
3264
Plugins / [Plugin] Re: User Mentions v1.0 (9th March 2013)
« on April 4th, 2013, 07:26 PM »
Notifications popup updated... It's a bit better now.
It's using the same template as on the notifications page, with a few minor modifications.
Also, everything is now pulled through Ajax (HTML included), so it makes for a shorter HTML container and JS file as well. (About 80 bytes saved in JS, dunno for HTML but it's all right too.)
I'm very close to being able to commit... Hopefully tomorrow. Then I'll just have to merge Dragooon's changes ;)
Which reminds me: id_member_notified sounds a bit strange... Instead of "ID of member who notified you", it implies to me "ID of member to be notified"... Wouldn't it be better to use something like 'id_issuer' or 'id_member_from'...?
It's using the same template as on the notifications page, with a few minor modifications.
Also, everything is now pulled through Ajax (HTML included), so it makes for a shorter HTML container and JS file as well. (About 80 bytes saved in JS, dunno for HTML but it's all right too.)
I'm very close to being able to commit... Hopefully tomorrow. Then I'll just have to merge Dragooon's changes ;)
Which reminds me: id_member_notified sounds a bit strange... Instead of "ID of member who notified you", it implies to me "ID of member to be notified"... Wouldn't it be better to use something like 'id_issuer' or 'id_member_from'...?
3265
The Pub / Re: Don't update log_online for certain actions
« on April 4th, 2013, 07:09 PM »
I don't know, did you look into my latest commit..? Isn't that what you wanted..?
3266
Archived fixes / Re: Wedge.org today
« on April 4th, 2013, 06:21 PM »
Hmmm... How annoying.
Although my code worked great 'theoretically', I forgot to take something into account: images... Loading avatars, signatures and attachments will change the post's height over time, so in order to enforce a proper minimum height for posts, we have to do it on $(window).load() as well.
So, here are the various solutions...
- Just do it on DOMContentReady. Pro: it's done quickly, you don't see any changes to the page. Cons: any time you have an image (e.g. an avatar!!) in your post, the proper height is incorrect. So you get the action bar halfway between the bottom of your body, and the bottom of the post. Meh... :-/
- Just do it on Load. Pro: it's accurate. The results are the same as with display: flex, and they work across ALL browsers. Cons: on posts with short messages, i.e. where the function will take full effect, you can clearly see the action bar move to the bottom once the page is loaded. Of course how long it takes depends on the number of images in the page... Wedge has less issues than SMF with that, for instance. But it still needs to load avatars...
- Do it in both places. Pro: it's accurate, and the action bar displacement is less visible. The height of the move roughly matches the height of the current avatar. Con: well, you still get the glitch. Also, it takes 6 more bytes than the Load-only solution.
- Do it nowhere... To hell with action bars in the bottom? (Let's just say, I'm... not a fan of that solution.)
- Do it nowhere, keep doing the flexbox model, and pray that all browsers will end up fixing the ton of bugs they have with it.
- Do it nowhere, and use <table> tags for posts. (Right now, if using the JavaScript solution, Wedge uses display:table, which is supposed to be the same as <table>, but isn't exactly -- display:table doesn't support colspan/rowspan, making it impossible to have a flexible height post body, only the last row is flexible.)
Any comments...?
PS: I'm installing the JS hack on Wedge.org, so you can see in action the effect of the "Do it in both places" solution. Also, executing the function on a full topic page takes about 20 to 50ms, multiply that by two if calling twice, although doing it on .load() will have little to no impact on performance.
(And, of COURSE, it isn't working properly in here... -_- Oh, frak. I'm leaving it as is for now.)
Although my code worked great 'theoretically', I forgot to take something into account: images... Loading avatars, signatures and attachments will change the post's height over time, so in order to enforce a proper minimum height for posts, we have to do it on $(window).load() as well.
So, here are the various solutions...
- Just do it on DOMContentReady. Pro: it's done quickly, you don't see any changes to the page. Cons: any time you have an image (e.g. an avatar!!) in your post, the proper height is incorrect. So you get the action bar halfway between the bottom of your body, and the bottom of the post. Meh... :-/
- Just do it on Load. Pro: it's accurate. The results are the same as with display: flex, and they work across ALL browsers. Cons: on posts with short messages, i.e. where the function will take full effect, you can clearly see the action bar move to the bottom once the page is loaded. Of course how long it takes depends on the number of images in the page... Wedge has less issues than SMF with that, for instance. But it still needs to load avatars...
- Do it in both places. Pro: it's accurate, and the action bar displacement is less visible. The height of the move roughly matches the height of the current avatar. Con: well, you still get the glitch. Also, it takes 6 more bytes than the Load-only solution.
- Do it nowhere... To hell with action bars in the bottom? (Let's just say, I'm... not a fan of that solution.)
- Do it nowhere, keep doing the flexbox model, and pray that all browsers will end up fixing the ton of bugs they have with it.
- Do it nowhere, and use <table> tags for posts. (Right now, if using the JavaScript solution, Wedge uses display:table, which is supposed to be the same as <table>, but isn't exactly -- display:table doesn't support colspan/rowspan, making it impossible to have a flexible height post body, only the last row is flexible.)
Any comments...?
PS: I'm installing the JS hack on Wedge.org, so you can see in action the effect of the "Do it in both places" solution. Also, executing the function on a full topic page takes about 20 to 50ms, multiply that by two if calling twice, although doing it on .load() will have little to no impact on performance.
Posted: April 4th, 2013, 06:16 PM
(And, of COURSE, it isn't working properly in here... -_- Oh, frak. I'm leaving it as is for now.)
3267
Archived fixes / Re: Wedge.org today
« on April 4th, 2013, 04:53 PM »
I don't use Firefox stable, but in Aurora (running v21a1, then updated to v21a2), it's working 'as expected'.
However, there IS an issue, but in another topic, but some text overlap. Not related to this one though...
I'm thinking, the world isn't ready for flex yet. I'll just disable it everywhere... <sigh>
I've written an alternative JavaScript function (~60 bytes) that does exactly the same, though. And it works :lol:
It's probably best to use that, instead of wasting my time fighting against windmills.
However, there IS an issue, but in another topic, but some text overlap. Not related to this one though...
I'm thinking, the world isn't ready for flex yet. I'll just disable it everywhere... <sigh>
I've written an alternative JavaScript function (~60 bytes) that does exactly the same, though. And it works :lol:
It's probably best to use that, instead of wasting my time fighting against windmills.
3268
Off-topic / Re: Doctor Who
« on April 4th, 2013, 12:55 PM »
Technically, that was only 3 months ago, so I'm hoping that Kindred at least remembered this one ;)
Pete, you're talking about my favorite doctor!! :P
Pete, you're talking about my favorite doctor!! :P
3269
Features / Re: New revs
« on April 4th, 2013, 12:48 PM »
rev 2045 -- this one is mainly for you to evaluate, Pete. Many changes in areas I'm not very comfortable.
(7 files, 6kb)
+ Added a 'feed' hook for plugins to insert their own feed sub-actions. (Feed.php, ManagePlugins.php)
* Moved 'determine_location' hook out of pretty URLs code, to make it a more generic URL manipulation hook. Also made $full_request subject to modifications. If I'm not mistaken..? (QueryString.php)
* Renamed action=media;sa=feed to action=feed;sa=media for consistency (and to prevent them from being logged in Who's Online). Added a hack to redirect them to Aeva-Foxy anyway, because... Well... It's complicated. (Feed.php, Media.template.php)
! $context['subaction'] should be built from $_GET specifically, not $_REQUEST. Not that we use that variable anyway, but... (index.php)
- Removed fallback URL for old SMF feed URLs and SMF Media Gallery URLs. I've built a plugin to account for these, if you're interested in supporting these URLs. Will probably be two plugins actually. One for SMF, one for SMG/AeMe. (QueryString.php, Aeva-Gallery.php)
- Removed two unused globals. (Errors.php, QueryString.php)
(7 files, 6kb)
+ Added a 'feed' hook for plugins to insert their own feed sub-actions. (Feed.php, ManagePlugins.php)
* Moved 'determine_location' hook out of pretty URLs code, to make it a more generic URL manipulation hook. Also made $full_request subject to modifications. If I'm not mistaken..? (QueryString.php)
* Renamed action=media;sa=feed to action=feed;sa=media for consistency (and to prevent them from being logged in Who's Online). Added a hack to redirect them to Aeva-Foxy anyway, because... Well... It's complicated. (Feed.php, Media.template.php)
! $context['subaction'] should be built from $_GET specifically, not $_REQUEST. Not that we use that variable anyway, but... (index.php)
- Removed fallback URL for old SMF feed URLs and SMF Media Gallery URLs. I've built a plugin to account for these, if you're interested in supporting these URLs. Will probably be two plugins actually. One for SMF, one for SMG/AeMe. (QueryString.php, Aeva-Gallery.php)
- Removed two unused globals. (Errors.php, QueryString.php)
3270
Plugins / [Plugin] Re: User Mentions v1.0 (9th March 2013)
« on April 4th, 2013, 12:14 PM »
Err... I don't remember exactly... Not that many, though..?
I mostly tore the JS apart and added the avatar stuff.
And mark read is disabled, yes. On wedge.org only though. For tests.
I mostly tore the JS apart and added the avatar stuff.
And mark read is disabled, yes. On wedge.org only though. For tests.