« Password Hashing
Template skeleton!
Zencart and a forum »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #105, 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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #106, on October 13th, 2011, 04:35 PM »
There's no real hurry, just that it's something that needs to be fixed prior to release.
Quote
Isn't there any other 'realistic' character that gets turned into entities inside posts
The only guaranteed ones are <, > and & - plus apostrophes and quote marks if we leave ENT_QUOTES in (as opposed to ENT_COMPAT)

It is a bit ugly, but I don't really see an alternative, other than leaving everything how it is currently.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #107, 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...)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #108, on October 13th, 2011, 09:00 PM »
Anything like that will work and yes, it would be better than using <we:*> for that. But I suggest not using <script> for the obvious confusion reason...

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #109, 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...
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...)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #112, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #113, on October 13th, 2011, 11:42 PM »
I'll test it shortly, but now you got me curious as to why.

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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #114, on October 13th, 2011, 11:52 PM »
Quote from Arantor on October 13th, 2011, 11:42 PM
I'll test it shortly, but now you got me curious as to why.
I fixed it 'quickly' because I'd already tried and failed to fix the same problem last week or so, when I'd mistakenly removed an ampersand from within reindex_recursive() (in the foreach). Turned out that ampersand was vital... :P
Anyway, if you find a faster solution, please be my guest! But don't waste too much time on it...
Quote
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.
Have no idea what you're talking about...... :whistle:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #115, on October 14th, 2011, 12:05 AM »
Quote
Have no idea what you're talking about......
foreach ($array as $k => &$v)

$k and $v are still set after the loop finishes, and $v is still a reference. Normally it isn't too much of a problem because it's within only the scope of the current function, which means at the end of the function, it's going to fall out of scope and becomes available for the garbage collector to free up.

If $v happens to be a reference to something that might remain in scope after the function ends, it might still be GC'd, but then you garbage collect something that wasn't supposed to be, and boom, segfault.

References are voodoo when you put then inside recursion. They're powerful but dangerous if you're not careful.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Template skeleton!
« Reply #116, on October 14th, 2011, 12:35 AM »
If it throws away a reference it shouldn't be throwing way the original. Unset isn't the same as setting the reference to zero pr something. That'd be a php bug.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Template skeleton!
« Reply #117, on October 14th, 2011, 12:41 AM »
I know, but there are times the GC is a little enthusiastic about housekeeping of references.
Re: Template skeleton!
« Reply #118, on October 14th, 2011, 11:48 AM »
Confirmed the bug is fixed, I can now add template blocks before others as expected :)
Re: Template skeleton!
« Reply #119, on November 3rd, 2011, 01:51 AM »
Hmm, I think I found another bug, this time in wetem::layer. Just want to confirm I'm using it correctly or not as the case may be.

This one's from WedgeDesk.

Code: [Select]
wetem::load(
array(
'shd_post_nojs',
'post_navigation',
'preview',
'ticket_info',
'ticket_subjectbox',
'ticket_meta',
'ticket_postbox',
'ticket_footer',
'ticket_pageend',
'ticket_proxy_js',
),
'default',
'replace'
);

if (!empty($context['ticket_form']['do_replies']))
{
wetem::layer('ticket_replies', 'ticket_pageend', 'before');
wetem::load('ticket_do_replies', 'ticket_replies', 'add');
}

It's a long story as to why that's a replace up in the first load call, but that's what it has to be for the time being until I fix other things. This is based against r1142, but I have something to add in a moment about r1143.

Anyway, my understanding is that I can dynamically create a layer through wetem::layer and have it positioned where I want in the list, and I want to add it dynamically based on a variable that I know to exist and be set correctly. Except that although the if() is executed, wetem::layer never adds ticket_replies as a layer before ticket_pageend, and do-replies is never added to the list.

I know I can work around it by declaring the layer up front in the main load call and then dynamically removing it if the relevant variable is empty, but that seems clumsy to me.

Also, r1143 will break any instance of array_insert; all places it was called (e.g. the template skeleton) relied on it modifying $array by reference but now it's returning a value - and wetem (amongst other places) isn't picking that up. I'll fix it tomorrow if you don't get to it first.
« Password Hashing
Zencart and a forum »