Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:07
    calvinbaart opened #566
  • 15:25

    jakubmisek on v0.9.500

    (compare)

  • 12:13
    jakubmisek commented #565
  • 12:11

    jakubmisek on master

    (binary) cast operator to cast… (compare)

  • 11:22
    jan-ai commented #565
  • 11:05
    jakubmisek commented #565
  • 10:57
    jan-ai opened #565
  • 09:09

    jakubmisek on master

    test case for https://github.co… (compare)

  • 09:05
    jakubmisek commented #555
  • 09:04

    jakubmisek on master

    comment (compare)

  • 09:03
    jakubmisek closed #564
  • 09:03

    jakubmisek on master

    workaround for Laravel making a… (compare)

  • 09:02
    jakubmisek commented #564
  • 09:02
    jakubmisek commented #564
  • 09:02
    menturion commented #555
  • 09:00
    jakubmisek commented #564
  • 08:56
    jakubmisek commented #564
  • 08:55
    jakubmisek edited #252
  • 08:55
    jakubmisek edited #252
  • 08:54
    jakubmisek edited #252
Jakub Míšek
@jakubmisek
@calvinbaart let me add some more debug information
@smx-smx thanks!
@Musti132 no news
Calvin Baart
@calvinbaart
@jakubmisek Retriggered the build, this is the assertion message: Argument for params is expected to be of type PhpValue[], at Headers::__construct(). It looks like a PHP error so I'll look into it when I'm home
Jakub Míšek
@jakubmisek
thanks, seems a __construct() vararg argument might be type-hinted?
Calvin Baart
@calvinbaart
Yea, I'll need to find that class to see whats going wrong. Thanks for adding the debug messages, that atleast gives me some clue :)
Jakub Míšek
@jakubmisek
looking for the class as well :)
Contains a type-hinted vararg constructor aswell
Jakub Míšek
@jakubmisek
yes (HeaderInterface ...$headers) thanks!
test case, pretty simple:
class X {
    function __construct(int ...$args) {
        //print_r( $args );
    }
}
Jakub Míšek
@jakubmisek
fixed, thanks @calvinbaart :)
Calvin Baart
@calvinbaart
Great thanks, I'll trigger the build again
Jakub Míšek
@jakubmisek
I guess you have enabled debug build :)
Calvin Baart
@calvinbaart
Yea....I should probably have enabled it sooner (because of all the assertions I should have hit)
Daniel Llewellyn
@diddledan
only one override in WordPress now! iolevel/wpdotnet-sdk#45
Jakub Míšek
@jakubmisek
@calvinbaart should be fixed in latest commit
This message was deleted
@diddledan thanks! what is the last override? that PEAR_Error ?
Calvin Baart
@calvinbaart
Ah debug build....: https://travis-ci.com/calvinbaart/laravel-peachpie-sample
I'll try building in Release...
Jakub Míšek
@jakubmisek
well the debug build should pass as well :) so feel free to keep it, we have to fix all the assertions anyway
seems this is not an assertion btw
Jakub Míšek
@jakubmisek
looks like eval() created the same class twice
Daniel Llewellyn
@diddledan
@jakubmisek yeah, the last one is an
if (class_exists('PEAR_Error')) {
    class foo extends PEAR_Error {}
}
Calvin Baart
@calvinbaart
@jakubmisek I linked the wrong one, this was the build with the failing assertion: https://travis-ci.com/calvinbaart/laravel-peachpie-sample/builds/128209553
Jakub Míšek
@jakubmisek
@calvinbaart thanks! working on it
Jakub Míšek
@jakubmisek
@calvinbaart as I see the most recent issue is the __destruct() being called (in .NET by the Garbage Collection) and crashes
Calvin Baart
@calvinbaart
@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)
Calvin Baart
@calvinbaart
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
Christopher Pereira
@kripper
Hi, how can I set global PHP variables for my web app from .cs ?
Christopher Pereira
@kripper
I found something about 'BeforeRequest'...will try
Christopher Pereira
@kripper
got it working
Christopher Pereira
@kripper
Hi, I'm stuck: require_once() is not working, altough the file was compiled
is ini_set('include_path', ...) working?
do I have to tell peachpie the root path?
Christopher Pereira
@kripper
The error says: working directory is ''
do we need to set the working directory in order to require_once() to work?
@jakubmisek any hint?
Christopher Pereira
@kripper
I think I found out how peachpie looks for the files to be included
it seems like we should always use relative paths
Christopher Pereira
@kripper
I compiled a file with <Compile Include="../modules/...
it seems like this is not supported
Jakub Míšek
@jakubmisek
@calvinbaart the assertion is a good one, will take a look. Caused by setting a value which was not de-referended by the compiler
@kripper yes the root path is crucial, see PhpRequestOptions, if not set, current working directory is used which works in most cases
Jakub Míšek
@jakubmisek

For a reference,

<Compile Include="../modules/...

is handled by MSBuild. both relative paths and absolute paths are supported. Note you can only compile files within your project folder.

Jakub Míšek
@jakubmisek
@calvinbaart the __destruct() thing - maybe we should not call it if __destruct() was already called from within the code? we might also temporarily disable the destructors if it causes compatibility issues
Calvin Baart
@calvinbaart
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