Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 16:34

    roberthusak on semantic-transformations

    Add transformation of empty($x)… (compare)

  • 15:42
    jakubmisek commented #565
  • 13:57
    liesauer commented #565
  • 13:22
    jakubmisek commented #565
  • 13:22
    jakubmisek reopened #565
  • 13:22
    jakubmisek closed #565
  • 13:22

    jakubmisek on master

    conversion value -> binary fix… (compare)

  • 13:16
    liesauer commented #565
  • 10:17

    roberthusak on semantic-transformations

    Add transformation of multiplyi… (compare)

  • 05:10
  • 05:08
  • Nov 21 17:54
    OsaPL edited #590
  • Nov 21 17:53
    OsaPL edited #590
  • Nov 21 17:52
    OsaPL opened #590
  • Nov 21 14:48

    jakubmisek on master

    minor cleanup (compare)

  • Nov 21 12:34

    jakubmisek on master

    enabled IHttpBodyControlFeature… (compare)

  • Nov 21 12:23
    jakubmisek closed #589
  • Nov 21 12:23

    jakubmisek on master

    unset() on typed string variabl… (compare)

  • Nov 21 12:20
    jakubmisek assigned #589
  • Nov 21 12:19
    jakubmisek labeled #589
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

Jakub Míšek
@jakubmisek
that makes sense ... currently I have no idea how to "workaround" it, probably we should not create the Finalizer at all, only the IDisposable and implement something that would wrap the use of a local variable within a using block
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)
Calvin Baart
@calvinbaart
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)
Jakub Míšek
@jakubmisek
Seems correct, we can keep track of a few simple cases and call __destruct() (or Dispose in our case) like PHP does. Then we'd add some assertions so we'll be notified if __destruct was not called so implementor (you and us) would know there might be an issue.
latest commit disables finalizers
Daniel Llewellyn
@diddledan
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