EReg issue (and fix).

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

EReg issue (and fix).

sledorze
While applying a template with Erazor during a requestAnimFrame (called by the browser).
Got an issue with chrome and a bug related to globals and RegExp.

from EReg:
        public function match( s : String ) : Bool {
                r.m = r.exec(s);
                r.s = s;
                r.l = untyped __js__("RegExp.leftContext");
                r.r = untyped __js__("RegExp.rightContext"); <<< here got an illegal access
                return (r.m != null);
        }

Dunno much about this api but looks like this patch expose a solution to a similar problem.
https://gist.github.com/474471

So, I've made a quick patch for EReg (js target) and it looks like it fixes this issue.
       
        public function match( s : String ) : Bool {
                r.m = r.exec(s);
                r.s = s;
                r.l = if (this.r.m!=null) untyped __js__("s.slice(0, this.r.m.index)") else null;
                r.r = if (this.r.m!=null) untyped __js__("s.slice(this.r.m.index)") else null;
                return (r.m != null);
        }

Can one integrate it?

Thanks!
Stephane
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

Nicolas Cannasse
Le 30/05/2011 11:32, sledorze a écrit :

> While applying a template with Erazor during a requestAnimFrame (called by
> the browser).
> Got an issue with chrome and a bug related to globals and RegExp.
>
> from EReg:
> public function match( s : String ) : Bool {
> r.m = r.exec(s);
> r.s = s;
> r.l = untyped __js__("RegExp.leftContext");
> r.r = untyped __js__("RegExp.rightContext");<<<  here got an illegal
> access
> return (r.m != null);
> }

Could you detail in which cases Regexp statics are not valid ? We've
been using this EReg impl for a long time without any issue - including
on Chrome ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

sledorze
It produces only an error if called from several contexts concurrently.
One call is issued from the main thread of execution (from the main body) the other from requestAnimFrame, which its aiming at providing a callback the browser will call when a screen render has to be done.
I'm using current Chrome (11.0.696.71).


Here's requestAnimFrame definition:

var requestAnimFrame = untyped __js__(
" (function(){
      return  window.requestAnimationFrame       || 
              window.webkitRequestAnimationFrame || 
              window.mozRequestAnimationFrame    || 
              window.oRequestAnimationFrame      || 
              window.msRequestAnimationFrame     || 
              function(/* function */ callback, /* DOMElement */ element){
window.setTimeout(callback, 1000 / 60);
              };
    })(); "
);

I Hope it helps,
Stephane


On Mon, May 30, 2011 at 11:45 AM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 30/05/2011 11:32, sledorze a écrit :

> While applying a template with Erazor during a requestAnimFrame (called by
> the browser).
> Got an issue with chrome and a bug related to globals and RegExp.
>
> from EReg:
> public function match( s : String ) : Bool {
> r.m = r.exec(s);
> r.s = s;
> r.l = untyped __js__("RegExp.leftContext");
> r.r = untyped __js__("RegExp.rightContext");<<<  here got an illegal
> access
> return (r.m != null);
> }
Could you detail in which cases Regexp statics are not valid ? We've
been using this EReg impl for a long time without any issue - including
on Chrome ;)

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/EReg-issue-and-fix-tp6418391p6418413.html
To unsubscribe from EReg issue (and fix)., click here.



--
Stéphane Le Dorze

Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

sledorze
In reply to this post by sledorze
Just wanted to let know that this bug remains..
I still have to apply this email patch when upgrading haxe lib and exe.

Stephane
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

Nicolas Cannasse
Le 18/08/2011 14:52, sledorze a écrit :
> Just wanted to let know that this bug remains..
> I still have to apply this email patch when upgrading haxe lib and exe.

Gabor Molnar posted a similar issue 4 days ago.

Looking at matchedLeft/matchedRight implementation, it seems we already
have a fallback implementation in case r.l/r.r are null.

Should we not remove r.l/r.r directly ? I'm not sure if that would cause
an issue or not.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

Justin Donaldson-3
I wanted to dig up this undead issue
http://code.google.com/p/haxe/issues/detail?id=541

The problem is that matchedRight will return an error, not null in Chrome.

I'm having better luck with the patch proposed by Gabor (which I think is the same as proposed by Yanis in this issue).

Of course, why not streamline it a bit more:

    public function match( s : String ) : Bool {
        r.m = r.exec(s);
        r.s = s;

        r.l = untyped __js__("RegExp.leftContext");
        r.r = untyped __js__("RegExp.rightContext");
        return (r.m != null);
    }






On Thu, Aug 18, 2011 at 7:48 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 18/08/2011 14:52, sledorze a écrit :

Just wanted to let know that this bug remains..
I still have to apply this email patch when upgrading haxe lib and exe.

Gabor Molnar posted a similar issue 4 days ago.

Looking at matchedLeft/matchedRight implementation, it seems we already have a fallback implementation in case r.l/r.r are null.

Should we not remove r.l/r.r directly ? I'm not sure if that would cause an issue or not.

Nicolas


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

Justin Donaldson-3
whoops, haunted keyboard, here was my suggestion:

    public function match( s : String ) : Bool {
        r.m = r.exec(s);
        r.s = s;
        if (r.m != null){
            r.l = untyped __js__("RegExp.leftContext");
            r.r = untyped __js__("RegExp.rightContext");
            return true;
        }
        else return false;
    }


Best,
-Justin

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

sledorze
In reply to this post by Nicolas Cannasse
Removing those while keeping the same functionnality would be fine for me.
If the issue is additional (split) computation then, a lazy implementation would be good.

Reply | Threaded
Open this post in threaded view
|

Re: EReg issue (and fix).

Nicolas Cannasse
Le 29/10/2011 09:30, sledorze a écrit :
> Removing those while keeping the same functionnality would be fine for me.
> If the issue is additional (split) computation then, a lazy implementation
> would be good.

I made a change which completely remove access to these statics.

Best,
Nicolas


--
haXe - an open source web programming language
http://haxe.org