@Musti132 no news
Contains a type-hinted vararg constructor aswell
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