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.
7411
Features / Re: Template skeleton!
« on October 13th, 2011, 11:52 PM »I'll test it shortly, but now you got me curious as to why.
Anyway, if you find a faster solution, please be my guest! But don't waste too much time on it...
Remember though that iterating a loop will the key iterator and last value hanging around until it falls out of scope at which point it's GC'd. Smells like one of those references is lingering.
7412
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 13th, 2011, 11:27 PM »
Technically, I'm surprised that so much data & code was linked to the birthday feature... Really. I thought it'd make for a sub-2KB plugin but now I suspect it'll be at least 10KB...
7413
Plugins / Re: Plugin servers / getting plugins to a system
« on October 13th, 2011, 11:26 PM »I use the gzipped tars because SMF randomly has problems with ZIPs.Quote Do we really need to support both .zip and .tar.gz? Gut instinct says no, just zip will cover the bulk of what's actually needed?
7414
Features / Re: Template skeleton!
« on October 13th, 2011, 11:23 PM »
So... The problem was within reindex(), more specifically self::$layers = array() was actually emptying self::$skeleton in the process.
This should NOT, I repeat this should NOT have happened, ever... Because an array of references, when erased, will not erase its referenced data, only the 'link' to the referenced data. (An easy way to create a memory hole since if you have no other reference to it, it's lost and not regained...)
I tried many solutions, I tried unsetting the data part by part, at best it didn't work, at worst (90% of the time) it actually crashed my server...
So I decided to let it do it, and simply save self::$skeleton ($transit = self::$skeleton) and reset it right after erasing the layer list.
And... It didn't work either (i.e. the $transit variable was also emptied after the self::$layers line). I was starting to go crazy because self::$skeleton is just a plain regular array, not an array of references, but I tried to 'simply' get it as raw data (through unserialize(serialize())), and this time it worked. :)
Really... I don't wanna know why it works this way.
Heck, yeah I'd love to know... But I already wasted a lot of time on this, and I suspect investigating would only waste even more time. And I'd rather waste my time playing RPGs than determining why PHP is buggy... :P
Please confirm that it's fixed on your side.
This should NOT, I repeat this should NOT have happened, ever... Because an array of references, when erased, will not erase its referenced data, only the 'link' to the referenced data. (An easy way to create a memory hole since if you have no other reference to it, it's lost and not regained...)
I tried many solutions, I tried unsetting the data part by part, at best it didn't work, at worst (90% of the time) it actually crashed my server...
So I decided to let it do it, and simply save self::$skeleton ($transit = self::$skeleton) and reset it right after erasing the layer list.
And... It didn't work either (i.e. the $transit variable was also emptied after the self::$layers line). I was starting to go crazy because self::$skeleton is just a plain regular array, not an array of references, but I tried to 'simply' get it as raw data (through unserialize(serialize())), and this time it worked. :)
Really... I don't wanna know why it works this way.
Heck, yeah I'd love to know... But I already wasted a lot of time on this, and I suspect investigating would only waste even more time. And I'd rather waste my time playing RPGs than determining why PHP is buggy... :P
Please confirm that it's fixed on your side.
7415
Features / Re: New revs
« on October 13th, 2011, 11:17 PM »
rev 1108
(13 files, 18kb)
! Fixed a very odd skeleton bug where the skeleton would be emptied after reindexing it for the Nth time. I think my... solution to the problem is even weirder than the bug itself. (Subs-Template.php)
* Renamed <we:scripturl> to <URL>, because we can. And to fix a conflict with macros. (other/install.sql, Subs-Template.php, index.template.php, Warm/skin.xml, LANGUAGES: Admin, index, ModerationCenter, Who)
- Useless $scripturl. (Subs-BBC.php)
(13 files, 18kb)
! Fixed a very odd skeleton bug where the skeleton would be emptied after reindexing it for the Nth time. I think my... solution to the problem is even weirder than the bug itself. (Subs-Template.php)
* Renamed <we:scripturl> to <URL>, because we can. And to fix a conflict with macros. (other/install.sql, Subs-Template.php, index.template.php, Warm/skin.xml, LANGUAGES: Admin, index, ModerationCenter, Who)
- Useless $scripturl. (Subs-BBC.php)
7417
Features / Re: Template skeleton!
« on October 13th, 2011, 09:30 PM »
Well, obviously yes :P Although it would never come to mind (mine at least) to use uppercase in HTML... :lol:
Hmm... Why not simply <URL>? It's an acronym so it 'makes sense' in uppercase. And I don't believe we need to have $boardurl much, so it's unlikely we'll be having a <URL> for $boardurl in the future...
Oops, latest we:scripturl commits breaks Wedge... Sorry, didn't test earlier ;)
It's due to the way macros are parsed. I'll have to fix that, too, in addition to the other bugs you mentioned...
(This is fixed by just using anything non-<we:>, BTW...)
Hmm... Why not simply <URL>? It's an acronym so it 'makes sense' in uppercase. And I don't believe we need to have $boardurl much, so it's unlikely we'll be having a <URL> for $boardurl in the future...
Posted: October 13th, 2011, 09:23 PM
Oops, latest we:scripturl commits breaks Wedge... Sorry, didn't test earlier ;)
It's due to the way macros are parsed. I'll have to fix that, too, in addition to the other bugs you mentioned...
Posted: October 13th, 2011, 09:27 PM
(This is fixed by just using anything non-<we:>, BTW...)
7418
Features / Re: New revs
« on October 13th, 2011, 09:21 PM »
rev 1107
(8 files, 9kb)
- Removed a non-existent birthday function call. (other/ssi_examples.shtml)
! French translation fixes. (EmailTemplates.french.php, Help.french.php, index.french.php, ManagePermissions.french.php, Profile.french.php)
* Minor tidbits and unused strings. (index.english.php, Profile.english.php, Profile.french.php)
(8 files, 9kb)
- Removed a non-existent birthday function call. (other/ssi_examples.shtml)
! French translation fixes. (EmailTemplates.french.php, Help.french.php, index.french.php, ManagePermissions.french.php, Profile.french.php)
* Minor tidbits and unused strings. (index.english.php, Profile.english.php, Profile.french.php)
7419
Features / Re: Birthday, calendar, plugin, core [VOTE NOW!]
« on October 13th, 2011, 08:57 PM »
A note on the latest commits: it seems like a few 'bday' strings are left in the codebase. They're usually linked to the 'birth date', but since 'cal_showbdays' was removed from the options, it should logically be removed from install.sql and upgrade.sql, I suppose.
I'm not doing it myself because it all has to end up in the various plugins... ;)
I'm not doing it myself because it all has to end up in the various plugins... ;)
7420
Features / Re: New revs
« on October 13th, 2011, 08:30 PM »
rev 1106
(15 files, 21kb)
* Moved URL replacements to the very end, to avoid URLs not being transformed in some situations. (Subs-Template.php)
* Renamed {scripturl} to <we:scripturl> to avoid literal uses of {scripturl} in user posts to be converted on the fly. Also converted the quote tag entry and removed a few str_replace calls that were now useless. (other/install.sql, Subs-BBC.php, Subs-Template.php, SSI.php, index.template.php, Warm/skin.xml, LANGUAGES: Admin, index, ModerationCenter, Who)
! $context needed to be globalized. (Who.php)
(15 files, 21kb)
* Moved URL replacements to the very end, to avoid URLs not being transformed in some situations. (Subs-Template.php)
* Renamed {scripturl} to <we:scripturl> to avoid literal uses of {scripturl} in user posts to be converted on the fly. Also converted the quote tag entry and removed a few str_replace calls that were now useless. (other/install.sql, Subs-BBC.php, Subs-Template.php, SSI.php, index.template.php, Warm/skin.xml, LANGUAGES: Admin, index, ModerationCenter, Who)
! $context needed to be globalized. (Who.php)
7421
Features / Re: Template skeleton!
« on October 13th, 2011, 08:22 PM »
Hmm yeah, <> remains best here...
How about something like <SCRIPT>? In uppercase... It's likelier to be sent as a placeholder tag, than a <we:> which is mainly for themers (being used in macros and all...)
How about something like <SCRIPT>? In uppercase... It's likelier to be sent as a placeholder tag, than a <we:> which is mainly for themers (being used in macros and all...)
7422
The Pub / [Archive] Re: Logo Madness
« on October 13th, 2011, 04:53 PM »
What's wrong with that logo, globally?
7423
Features / Re: Template skeleton!
« on October 13th, 2011, 04:30 PM »
I'll look into it... I'm busy IRL and I have a commit coming up once I have time to deal with it (the <we:scripturl> changes.)
BTW, I'm not thrilled having <we:scripturl> inside tags. Like <a href="<we:scripturl>">, I find that ugly... Isn't there any other 'realistic' character that gets turned into entities inside posts? Can't think of anything for now...
BTW, I'm not thrilled having <we:scripturl> inside tags. Like <a href="<we:scripturl>">, I find that ugly... Isn't there any other 'realistic' character that gets turned into entities inside posts? Can't think of anything for now...
7424
The Pub / [Archive] Re: Logo Madness
« on October 13th, 2011, 12:47 PM »
So... Maybe with another font and different colors...?
7425
The Pub / Re: English British support
« on October 13th, 2011, 07:32 AM »
- I meant array_merge of course.
- sounds good. Is it what smf used to update tier changelog number? ;)
- sounds good. Is it what smf used to update tier changelog number? ;)