Lime 2.8.0 & Openfl 3.5.0 (overriden getter/setter)

Stephane · December 9, 2015, 11:59pm

Good evening,
Before the last haxelib upgrade, I was used to override getter/setter like that :

    #if flash @:getter(x) #end public #if !flash override #end function get_x():Float
    {
        // invalidation system...
        return #if flash super.x; #else super.get_x(); #end
    }
    #if flash @:setter(x) #end public #if !flash override #end function set_x(_f:Float): #if flash Void #else Float #end
    {
        #if EComponent trace("EComponent.set_x( " + _f + " )"); #end
        if // invalidation system...
        else
            #if flash
                super.x = _f;
            #else
                super.set_x(_f);
            #end
        #if !flash
            return _f;
        #end
    }

With such a way, I have now that compiler errors "Normal variables can not be accessed with ‘super’, use ‘this’ instead."
Using this, does not allow me to override flash getter/setter, it brings me “infinite loop”…
Any hint to retrieve the desired behavior ?
Thanks.
Stéphane.

singmajesty · December 10, 2015, 12:03am

Would you mind trying to edit “openfl/display/DisplayObject.hx” in your install?

github.com

openfl/openfl/blob/master/openfl/display/DisplayObject.hx#L2221-L2224


package openfl.display;




import lime.graphics.cairo.Cairo;
import lime.ui.MouseCursor;
import lime.utils.ObjectPool;
import openfl._internal.renderer.cairo.CairoBitmap;
import openfl._internal.renderer.cairo.CairoDisplayObject;
import openfl._internal.renderer.cairo.CairoGraphics;
import openfl._internal.renderer.canvas.CanvasBitmap;
import openfl._internal.renderer.canvas.CanvasDisplayObject;
import openfl._internal.renderer.canvas.CanvasGraphics;
import openfl._internal.renderer.dom.DOMBitmap;
import openfl._internal.renderer.dom.DOMDisplayObject;
import openfl._internal.renderer.opengl.GLBitmap;
import openfl._internal.renderer.opengl.GLDisplayObject;
import openfl._internal.renderer.opengl.GLRenderer;
import openfl._internal.renderer.RenderSession;
import openfl.display.Stage;
import openfl.errors.TypeError;

This file has been truncated. show original

Perhaps changing #if (flash && !display) here could be #if (flash && !doc_gen), which may fix your issue?

Stephane · December 10, 2015, 12:12am

Thanks to your quick answer, I tried it but it doesn’t fix anything.
I don’t even realise what !doc_gen is meant to.

singmajesty · December 10, 2015, 12:17am

Okay, then it’s not related to code completion. “display” is defined when Haxe is performing code completion, or in our case, when we generate our documentation. The Haxe core code uses “doc_gen” as a define only for when generating documentation. There are cases where we blur the lines a little for documentation, since things need to match up exactly (like in this case, is it a property, or a getter/setter?)

Is this really related to Lime and OpenFL being updated? Did you update your Haxe install? I thought it was not possible to call super.x like this, I seem to recall trying to do something similar (and hitting a similar infinite loop on Flash) and having to give up

Stephane · December 10, 2015, 12:23am

I have fought a whole mess for that, I admit, but it finally worked that way.
The haxelib upgrade seems to have updated that day…
• openfl 3.4.0 > 3.5.0
• lime 2.7.0 > 2.8.0
• swf 2.1.3 > 2.1.4

Stephane · December 10, 2015, 12:28am

Even stranger ! Downgrading back to the previous versions brings me now the compiler error :

C:/HaxeToolkit/haxe/lib/openfl/3,4,0/openfl/display/GradientType.hx:26 characters 0-22 : Recursive typedef is not allowed.

I will try to locate the windows/html5 new issues with openfl 3.5.0/lime 2.8.0 tomorrow.
Anyway, It will be hard. Windows crash after an invalid cast popup, and I did forget how to trace() in HTML.

singmajesty · December 10, 2015, 12:50am

If you roll back to OpenFL 3.4 and Lime 2.7, be sure to do a -clean Flash build:

openfl test flash -clean

That will fix “recursive typedef” errors after downgrading. For HTML5, trace should work, but you need to open a debugger/inspector (usually Ctrl+Shift+I on Windows browsers) then hit the “console” tab

I believe the “use ‘this’ instead” error is Haxe related, not OpenFL related, but compare and lets see what happens

singmajesty · December 10, 2015, 12:52am

Oh, great

github.com

HaxeFoundation/haxe/blob/623a24f309c9e6918ec035760964109bb98a66cd/typer.ml#L1493-L1498


				| MSet,Var _ when (match c2 with Some ({ cl_extern = true; cl_path = ("flash" :: _,_) }, _) -> true | _ -> false) ->
					()
				| _, Method _ ->
					display_error ctx "Cannot create closure on super method" p
				| _ ->
					display_error ctx "Normal variables cannot be accessed with 'super', use 'this' instead" p);

there’s a “flash” package exception hard-coded in the compiler. We’re using “openfl”

Stephane · December 10, 2015, 1:04am

OMG.
The -clean has cleaned all my exported assets and previous/various compiled swf…

Sorry it sounds bad for you too.
Anyway, I still can override back my native flash getter/setter with openfl3.4.0/lime2.7.0/swf2.2

singmajesty · December 10, 2015, 1:06am

It should only clean your Export/flash directory, not your Assets or other directories. Was there something else in there?

Stephane · December 10, 2015, 1:13am

A lot of compiled swf and various assets, dynamically imported…
A loss of time to update all previous compiled swf and to export back my externs assets I guess/hope.

Will keep you informed of the windows/html5 new issues tomorrow.
Thank for your time.

singmajesty · December 10, 2015, 5:11am

If you can, maybe you can use an assets directory with ‘embed=“false”’ so it copies to the Export directory, without putting it in your SWF. That may help with allowing clean builds and would help if you test other targets as well. I’m so sorry for the setback

I have one idea for solving the override issue, I’ll need to try it when I’m back to my desk

Stephane · December 10, 2015, 9:45am

I will definitely use that embed=“false” to avoid that in the future. Thanks.
Thanks too for the Ctrl+Shift+I too !!! Sure, It will help me a lot.

Stephane · December 10, 2015, 2:05pm

HTML5 Issue ?

(that worked with openfl 3.4.0 / lime 2.7.0 / swf 2.1.3)

URLLoader seems not to dispatch Event.COMPLETE…

function issue()
{
    var loader:URLLoader = new URLLoader();
    loader.dataFormat = URLLoaderDataFormat.BINARY;
    registerListeners(loader);
    var url:URLRequest = new URLRequest("myDirectory/myFile");    
    try
    {
        loader.load(url);
        // storing the loader in the LibraryManager occurence.
    }
    catch (_e:ArgumentError)
        trace("### ArgumentError ### " + _e.message)
    //catch (_e:MemoryError)
        //trace("### MemoryError ### " + _e.message)
    catch (_e:SecurityError)
        trace("### SecurityError ### " + _e.message)
    catch (_e:TypeError)
        trace("### TypeError ### " + _e.message);
}

    
function registerListeners(_u:URLLoader):Void
{
    #if LibraryManager trace("LibraryManager.registerListeners( " + _u + "  )"); #end
    _u.addEventListener(Event.OPEN, onOpen);
    _u.addEventListener(ProgressEvent.PROGRESS, onProgress);
    _u.addEventListener(Event.INIT, onInit);
    _u.addEventListener(Event.COMPLETE, onComplete);
    _u.addEventListener(Event.UNLOAD, onUnload);
    _u.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError);
    _u.addEventListener(HTTPStatusEvent.HTTP_STATUS, onHTTPStatus);
    _u.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
}
function onOpen(_e:Event):Void
{
    #if LibraryManager trace("LibraryManager.onOpen( " + _e.toString() + " )"); #end
}
function onProgress(_e:ProgressEvent):Void
{
    #if LibraryManager trace("LibraryManager.onProgress( " + _e.bytesLoaded + " / " + _e.bytesTotal + " )"); #end
}
function onInit(_e:Event):Void
{
    #if LibraryManager trace("LibraryManager.onInit( " + _e.toString() + " )"); #end
}
function onComplete(_e:Event):Void
{
    #if LibraryManager trace("LibraryManager.onComplete( " + _e.toString() + " )"); #end
}
function onUnload(_e:Event):Void
{
    #if LibraryManager trace("LibraryManager.onUnload( " + _e.toString() + " )"); #end
}
function onSecurityError(_e:SecurityErrorEvent):Void
{
    #if LibraryManager trace("LibraryManager.onSecurityError( " + _e.toString() + " )"); #end
}
function onHTTPStatus(_e:HTTPStatusEvent):Void
{
    #if LibraryManager trace("LibraryManager.onHTTPStatus( " + _e.toString() + " )"); #end
}
function onIOError(_e:IOErrorEvent):Void
{
    #if LibraryManager trace("LibraryManager.onIOError( " + _e.toString() + " )"); #end
}

In the console, I retrieve well the expected trace with -DLibraryManager flag.

LibraryManager.registerListeners( [object EURLLoader] ) Main.js:10307:1
LibraryManager.onOpen( [Event type=“open” bubbles=false cancelable=false] ) Main.js:10318:3
LibraryManager.onHTTPStatus( [HTTPStatusEvent type=“httpStatus” bubbles=false cancelable=false status=200 redirected=false] )

but no INIT, PROGRESS, or COMPLETE…
Can’t be sure that the HTTPStatus one is a new one…
Any advice ? A random no-cache trick with the URLRequest ?
Thanks.

singmajesty · December 10, 2015, 6:13pm

I think this should be resolved now, was specific to type BINARY on HTML5 (through a “cannot convert [ArrayBuffer] to” error at runtime)

Stephane · December 10, 2015, 6:48pm

I invalidate, it does not fire any INIT/PROGRESS/COMPLETE Event…
(with the latest haxelib upgrade : openfl 4.5.1 / lime 2.8.1)

singmajesty · December 10, 2015, 7:57pm

Oh, I meant just today

You can patch your own install to see if it fixes it for you. This will go in the next OpenFL minor release

Stephane · December 10, 2015, 8:34pm

yeah ! thank you.
no more issues on HTML5 (for me).
you’re magic.

should developp about the Windows target tomorrow.