test case, pretty simple:
class X {
function __construct(int ...$args) {
//print_r( $args );
}
}
This message was deleted
@diddledan thanks! what is the last override? that
PEAR_Error ?
Ah debug build....: https://travis-ci.com/calvinbaart/laravel-peachpie-sample
I'll try building in Release...
I'll try building in Release...
seems this is not an assertion btw
@jakubmisek I linked the wrong one, this was the build with the failing assertion: https://travis-ci.com/calvinbaart/laravel-peachpie-sample/builds/128209553
@jakubmisek Yea, I think its happening because the
__destruct is not called deterministically. I think the destruct is called after laravel resets itself for the next test and then fails because its not in the state the original test expected, I'll keep looking into this to see if this is actually the case though (I can't really reproduce this easily, I'll probably disable the __destruct for now)
New assertion! https://travis-ci.com/calvinbaart/laravel-peachpie-sample/builds/128627715 Debug mode is a goldmine I guess.... :)
I'm not really sure how to report these since I can't get any of them to reproduce reliably outside of the unit test
I'm not really sure how to report these since I can't get any of them to reproduce reliably outside of the unit test
is ini_set('include_path', ...) working?
do I have to tell peachpie the root path?
do we need to set the working directory in order to require_once() to work?
@jakubmisek any hint?
it seems like we should always use relative paths
it seems like this is not supported
@kripper yes the root path is crucial, see PhpRequestOptions, if not set, current working directory is used which works in most cases
I don't think it has been called from the code before. I placed a log inside the destruct and its only called once (after the finalizer). I think it only causes stability issues in unit test scenarios because the test scope is pretty important for that (For example Laravel tends to destroy and completely rebuild the application after every test case to make sure the tests begin clean, I can imagine this causes issues with __destruct not being called deterministically)
unit test-like scenarios*
The following psuedo-code is what happens as far as I can tell:
SetupLaravelApplication();
{ // create new scope
$obj = new Command();
}
DestroyLaravelApplication();In PHP $obj is destroyed at the end of the scope, in C# its destroyed whenever (and from another thread (the finalizer thread)?) so that causes some problems
so in the example above, we would actually emit a code similar to this:
SetupLaravelApplication();
try { obj = new Command(); }
finally { obj?.Dispose(); }
DestroyLaravelApplication();
BTW sadly, PHP does not have code scopes, only local and global. So it destroys its local variables on the very end of the function block (as I remember)
Just wrote some test code and
BTW sadly, PHP does not have code scopes, only local and global. So it destroys its local variables on the very end of the function block (as I remember) seems to be correct. It only calls destruct at the end of the function (or when I dereference the last value, for example $obj = new TestClass(); $obj = new TestClass2();, TestClass destruct will be called here)
latest commit disables finalizers
You may remember ages back I mentioned that adding the code-based AppInsights thing from azure to a wpdotnet was causing exceptions to fire. I finally took some time to figure it out - it's in the WPdotnet cache mechanism which saves the headers of the response when adding to the cache and then tries to re-add those headers in a cached response. The response therefore tries to add a second
Request-Context header because AppInsights adds one to every response before wpdotnet then adds the one from the original caching request
I worked around it by adding an
if (header.Key != "Request-Context") {} around the re-adding mechanism when serving a cached response
it might be better to not cache the header in the first place rather than avoiding it when emitting the cached responses