hxcpp code gen fix..

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

hxcpp code gen fix..

sledorze
..Imagine someone's willing to fix some code in the cpp backend.. (U know, I have a friend of a friend..)
What would be the best guidance to help him be up to speed as quickly as possible?
Thanks,
Stephane
Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Tony Polinelli
it probably depends what this 'friend' needs to fix.

in general, he will want to learn how to compile haxe & the hxcpp lib. He should probably search this list for this, as there are a few recent topics about compiling hxcpp - and look on haxe.org for compiling from source for the main haxe compiler. It depends on what your changing as to which needs compiling (i think)

On Tue, Mar 22, 2011 at 9:59 AM, sledorze <[hidden email]> wrote:
..Imagine someone's willing to fix some code in the cpp backend.. (U know, I
have a friend of a friend..)
What would be the best guidance to help him be up to speed as quickly as
possible?
Thanks,
Stephane


--
View this message in context: http://haxe.1354130.n2.nabble.com/hxcpp-code-gen-fix-tp6194311p6194311.html
Sent from the Haxe mailing list archive at Nabble.com.

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



--
Tony Polinelli
http://touchmypixel.com

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

Re: hxcpp code gen fix..

sledorze
It's mainly about the cpp code generation.
Let's say:
http://code.google.com/p/hxcpp/issues/detail?id=111
http://code.google.com/p/hxcpp/issues/detail?id=110
http://code.google.com/p/hxcpp/issues/detail?id=107
http://code.google.com/p/hxcpp/issues/detail?id=106
http://code.google.com/p/hxcpp/issues/detail?id=105
..at least.

Compilation just works, editing using Emacs mode Tuareg (OcaIde simply did some weird errors in Eclipse).
What's needed is more guidance in the gencpp.ml
Some first toying is requiered but any pointer would be appreciated.

Stephane




Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Nicolas Cannasse
Le 22/03/2011 08:46, sledorze a écrit :

> It's mainly about the cpp code generation.
> Let's say:
> http://code.google.com/p/hxcpp/issues/detail?id=111
> http://code.google.com/p/hxcpp/issues/detail?id=110
> http://code.google.com/p/hxcpp/issues/detail?id=107
> http://code.google.com/p/hxcpp/issues/detail?id=106
> http://code.google.com/p/hxcpp/issues/detail?id=105
> ..at least.
>
> Compilation just works, editing using Emacs mode Tuareg (OcaIde simply did
> some weird errors in Eclipse).
> What's needed is more guidance in the gencpp.ml
> Some first toying is requiered but any pointer would be appreciated.

I guess that reading http://haxe.org/doc/advanced/code_generators would
help, and maybe also reading genjs.ml for a simple reference of how the
AST is generated. The full AST/types informations that are accessible by
the code generator are in type.ml

Then diving into gencpp.ml will be necessary, it does much more things
than genjs.ml because of the typed nature of the target.

Best,
Nicolas

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

Re: hxcpp code gen fix..

sledorze
Thanks for pointing this out :)


On Tue, Mar 22, 2011 at 10:25 AM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 22/03/2011 08:46, sledorze a écrit :

> It's mainly about the cpp code generation.
> Let's say:
> http://code.google.com/p/hxcpp/issues/detail?id=111
> http://code.google.com/p/hxcpp/issues/detail?id=110
> http://code.google.com/p/hxcpp/issues/detail?id=107
> http://code.google.com/p/hxcpp/issues/detail?id=106
> http://code.google.com/p/hxcpp/issues/detail?id=105
> ..at least.
>
> Compilation just works, editing using Emacs mode Tuareg (OcaIde simply did
> some weird errors in Eclipse).
> What's needed is more guidance in the gencpp.ml
> Some first toying is requiered but any pointer would be appreciated.

I guess that reading http://haxe.org/doc/advanced/code_generators would
help, and maybe also reading genjs.ml for a simple reference of how the
AST is generated. The full AST/types informations that are accessible by
the code generator are in type.ml

Then diving into gencpp.ml will be necessary, it does much more things
than genjs.ml because of the typed nature of the target.

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/hxcpp-code-gen-fix-tp6194311p6195497.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
In reply to this post by Nicolas Cannasse
Hmmm..
Looks like the 2 secs  incremental compilation mentionned here:
http://haxe.org/doc/advanced/code_generators/environment

is no more accessible.
Can anyone point out to somewhere I can find / understand what to do?
Thanks!
Stephane

P.S.: OcaIde finally rocks :)

On Tue, Mar 22, 2011 at 11:03 AM, Stephane Le Dorze <[hidden email]> wrote:
Thanks for pointing this out :)



On Tue, Mar 22, 2011 at 10:25 AM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 22/03/2011 08:46, sledorze a écrit :

> It's mainly about the cpp code generation.
> Let's say:
> http://code.google.com/p/hxcpp/issues/detail?id=111
> http://code.google.com/p/hxcpp/issues/detail?id=110
> http://code.google.com/p/hxcpp/issues/detail?id=107
> http://code.google.com/p/hxcpp/issues/detail?id=106
> http://code.google.com/p/hxcpp/issues/detail?id=105
> ..at least.
>
> Compilation just works, editing using Emacs mode Tuareg (OcaIde simply did
> some weird errors in Eclipse).
> What's needed is more guidance in the gencpp.ml
> Some first toying is requiered but any pointer would be appreciated.

I guess that reading http://haxe.org/doc/advanced/code_generators would
help, and maybe also reading genjs.ml for a simple reference of how the
AST is generated. The full AST/types informations that are accessible by
the code generator are in type.ml

Then diving into gencpp.ml will be necessary, it does much more things
than genjs.ml because of the typed nature of the target.

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/hxcpp-code-gen-fix-tp6194311p6195497.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
Ok, so I'm making progress on the issue where two nested switchs does not compile on cpp.
It appears to be a problem with finding undeclared variables (shadowing).

I am now wondering how I can debug that knowing:

I have not found a way to make a 'print' inside the compilation process in order to follow what's happening.
Compiling haxe and then executing the test takes ages (>40 secs).
I dunno/can't know(or don't know how) I can figure out how cases inside switch is expanded.
Indeed, I need to traverse the switch and declare the variables bound inside the case matchings before processing their inner expression.

Any pointer accepted (I need to go fast as I have no time left (have to port this app on IPad!!) )

Thanks,
Stephane
 
 

Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Gamehaxe
Hi,

So the debugging goes like this (bug 110).

You can use the command line arg "-D dump" to generate a dump file with  
the AST in it.

It appears the c++ code thinks the switch statement needs v2, which  
clearly is does not.
Since I am familiar with the code, I guess this is a failure in  
"find_undeclared_variables".

The switch-on-enum is the "TMatch" construct - so this is the place to  
start.
The variable is considered undefined when A "TLocal" is found, and the  
variable
in not found in the declared map.

So you can chuck a bunch if "print_endline" in the TMatch and TLocal cases  
of find_undeclared_variables.
See apendix A.

The debug goes....

search condition...
Need local var :a
end search condition
Case: local var :v1
search case...
Need local var :a
Need local var :v2
Need local var :v2 Undeclared !

...

It has already gone wrong - the case does not seem to recurse into the  
inner case when looking for declared variables.

Checking the recursion,
Type.iter (find_undeclared_variables .....   cexpr; // cexpr renamed in  
appendix

And therein lies the problem.  Type.iter, for a tmatch does:

| TMatch (e,_,cases,def) ->
     f e;
     List.iter (fun (_,_,e) -> f e) cases;
    (match def with None -> () | Some e -> f e)

Which does not visit the case names.

So the bug fix is to not use Type.iter to visit the case statements -  
instead use find_undeclared_variables directly.
ie,
find_undeclared_variables undeclared declarations this_suffix allow_this  
cexpr;

Which is actually simpler and better, and you just feel it is a "good" fix.

While I'm there, I'll also check for similar patterns (Type.iter used when  
it shouldn't be)
and there it is in the default bit too.

So the fix ends up being very simple, but I pity the fool who tries to do  
this cold.

Also, compiling on my windows box is faster than my old mac.
Since the backend is pretty much the same for all targets, it is
faster for me to dev on windows.

Hope this gives some insight into debugging.

Hugh





Appendix a: Debug

                | TLocal local_name ->
          let name = keyword_remap local_name in
                        print_endline ("Need local var :" ^ name );
                        if  not (Hashtbl.mem declarations name) then
                        begin
                        print_endline ("Need local var :" ^ name ^ " Undeclared !" );
                                Hashtbl.replace undeclared name (type_string expression.etype)
                        end
                | TMatch (condition, enum, cases, default) ->
                        print_endline ("search condition...");
                        find_undeclared_variables undeclared declarations this_suffix  
allow_this condition;
                        print_endline ("end search condition");
                        List.iter (fun (case_ids,params,cexpr) ->
                                let old_decs = Hashtbl.copy declarations in
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );
                           print_endline ("search case...");
                                Type.iter (find_undeclared_variables undeclared declarations  
this_suffix allow_this) cexpr;
                           print_endline ("searched case");
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: remove local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );

                                Hashtbl.clear declarations;
                                Hashtbl.iter ( Hashtbl.add declarations ) old_decs
                                ) cases;






> Ok, so I'm making progress on the issue where two nested switchs does not
> compile on cpp.
> It appears to be a problem with finding undeclared variables (shadowing).
>
> I am now wondering how I can debug that knowing:
>
> I have not found a way to make a 'print' inside the compilation process  
> in
> order to follow what's happening.
> Compiling haxe and then executing the test takes ages (>40 secs).
> I dunno/can't know(or don't know how) I can figure out how cases inside
> switch is expanded.
> Indeed, I need to traverse the switch and declare the variables bound  
> inside
> the case matchings before processing their inner expression.
>
> Any pointer accepted (I need to go fast as I have no time left (have to  
> port
> this app on IPad!!) )
>
> Thanks,
> Stephane
>
>
>
> --
> View this message in context:  
> http://haxe.1354130.n2.nabble.com/hxcpp-code-gen-fix-tp6194311p6195967.html
> Sent from the Haxe mailing list archive at Nabble.com.

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

Re: hxcpp code gen fix..

Nicolas Cannasse
Le 22/03/2011 16:49, Hugh Sanderson a écrit :
> Hi,
>
> So the debugging goes like this (bug 110).

What about bug 111 then ?

:-D

Nicolas

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

Re: hxcpp code gen fix..

sledorze
In reply to this post by Gamehaxe
Lol,
I was figuring out that it was on TMach and got a basic output using

print_endline (Type.s_expr (type_string) expression);

I also saw the problem with the iter with TMatch but though that as it was pattern matched in find_undeclared_variables that it was not the source of the pb.

I'll try your proposition ti validate :)



On Tue, Mar 22, 2011 at 4:52 PM, Hugh Sanderson [via Haxe] <[hidden email]> wrote:
Hi,

So the debugging goes like this (bug 110).

You can use the command line arg "-D dump" to generate a dump file with  
the AST in it.

It appears the c++ code thinks the switch statement needs v2, which  
clearly is does not.
Since I am familiar with the code, I guess this is a failure in  
"find_undeclared_variables".

The switch-on-enum is the "TMatch" construct - so this is the place to  
start.
The variable is considered undefined when A "TLocal" is found, and the  
variable
in not found in the declared map.

So you can chuck a bunch if "print_endline" in the TMatch and TLocal cases  
of find_undeclared_variables.
See apendix A.

The debug goes....

search condition...
Need local var :a
end search condition
Case: local var :v1
search case...
Need local var :a
Need local var :v2
Need local var :v2 Undeclared !

...

It has already gone wrong - the case does not seem to recurse into the  
inner case when looking for declared variables.

Checking the recursion,
Type.iter (find_undeclared_variables .....   cexpr; // cexpr renamed in  
appendix

And therein lies the problem.  Type.iter, for a tmatch does:

| TMatch (e,_,cases,def) ->
     f e;
     List.iter (fun (_,_,e) -> f e) cases;
    (match def with None -> () | Some e -> f e)

Which does not visit the case names.

So the bug fix is to not use Type.iter to visit the case statements -  
instead use find_undeclared_variables directly.
ie,
find_undeclared_variables undeclared declarations this_suffix allow_this  
cexpr;

Which is actually simpler and better, and you just feel it is a "good" fix.

While I'm there, I'll also check for similar patterns (Type.iter used when  
it shouldn't be)
and there it is in the default bit too.

So the fix ends up being very simple, but I pity the fool who tries to do  
this cold.

Also, compiling on my windows box is faster than my old mac.
Since the backend is pretty much the same for all targets, it is
faster for me to dev on windows.

Hope this gives some insight into debugging.

Hugh





Appendix a: Debug

                | TLocal local_name ->
          let name = keyword_remap local_name in
                        print_endline ("Need local var :" ^ name );
                        if  not (Hashtbl.mem declarations name) then
                        begin
                        print_endline ("Need local var :" ^ name ^ " Undeclared !" );
                                Hashtbl.replace undeclared name (type_string expression.etype)
                        end
                | TMatch (condition, enum, cases, default) ->
                        print_endline ("search condition...");
                        find_undeclared_variables undeclared declarations this_suffix  
allow_this condition;
                        print_endline ("end search condition");
                        List.iter (fun (case_ids,params,cexpr) ->
                                let old_decs = Hashtbl.copy declarations in
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );
                           print_endline ("search case...");
                                Type.iter (find_undeclared_variables undeclared declarations  
this_suffix allow_this) cexpr;
                           print_endline ("searched case");
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: remove local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );

                                Hashtbl.clear declarations;
                                Hashtbl.iter ( Hashtbl.add declarations ) old_decs
                                ) cases;






> Ok, so I'm making progress on the issue where two nested switchs does not
> compile on cpp.
> It appears to be a problem with finding undeclared variables (shadowing).
>
> I am now wondering how I can debug that knowing:
>
> I have not found a way to make a 'print' inside the compilation process  
> in
> order to follow what's happening.
> Compiling haxe and then executing the test takes ages (>40 secs).
> I dunno/can't know(or don't know how) I can figure out how cases inside
> switch is expanded.
> Indeed, I need to traverse the switch and declare the variables bound  
> inside
> the case matchings before processing their inner expression.
>
> Any pointer accepted (I need to go fast as I have no time left (have to  
> port
> this app on IPad!!) )
>
> Thanks,
> Stephane
>
>
>
> --
> View this message in context:  
> Sent from the Haxe mailing list archive at Nabble.com.

--
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/hxcpp-code-gen-fix-tp6194311p6196863.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
In reply to this post by Gamehaxe
It works :)
Anyway, that was not a lost day.
I had the opportunity to work with VMWare on Linux using OcaIde, do some ocaml and learn a bit more about Haxe.
And one bug (and possibly others) are gone! :) (even if it was not my fix)

From that I think it would be nice to update the information on the wiki about how one can enable incremental compilation.
It's very annoying and I was not able to find how to myself.

Hugh, will you push these fixes?? (I can do it if one gimme access)

Good day :)
Stephane

On Tue, Mar 22, 2011 at 5:27 PM, Stephane Le Dorze <[hidden email]> wrote:
Lol,
I was figuring out that it was on TMach and got a basic output using

print_endline (Type.s_expr (type_string) expression);

I also saw the problem with the iter with TMatch but though that as it was pattern matched in find_undeclared_variables that it was not the source of the pb.

I'll try your proposition ti validate :)




On Tue, Mar 22, 2011 at 4:52 PM, Hugh Sanderson [via Haxe] <[hidden email]> wrote:
Hi,

So the debugging goes like this (bug 110).

You can use the command line arg "-D dump" to generate a dump file with  
the AST in it.

It appears the c++ code thinks the switch statement needs v2, which  
clearly is does not.
Since I am familiar with the code, I guess this is a failure in  
"find_undeclared_variables".

The switch-on-enum is the "TMatch" construct - so this is the place to  
start.
The variable is considered undefined when A "TLocal" is found, and the  
variable
in not found in the declared map.

So you can chuck a bunch if "print_endline" in the TMatch and TLocal cases  
of find_undeclared_variables.
See apendix A.

The debug goes....

search condition...
Need local var :a
end search condition
Case: local var :v1
search case...
Need local var :a
Need local var :v2
Need local var :v2 Undeclared !

...

It has already gone wrong - the case does not seem to recurse into the  
inner case when looking for declared variables.

Checking the recursion,
Type.iter (find_undeclared_variables .....   cexpr; // cexpr renamed in  
appendix

And therein lies the problem.  Type.iter, for a tmatch does:

| TMatch (e,_,cases,def) ->
     f e;
     List.iter (fun (_,_,e) -> f e) cases;
    (match def with None -> () | Some e -> f e)

Which does not visit the case names.

So the bug fix is to not use Type.iter to visit the case statements -  
instead use find_undeclared_variables directly.
ie,
find_undeclared_variables undeclared declarations this_suffix allow_this  
cexpr;

Which is actually simpler and better, and you just feel it is a "good" fix.

While I'm there, I'll also check for similar patterns (Type.iter used when  
it shouldn't be)
and there it is in the default bit too.

So the fix ends up being very simple, but I pity the fool who tries to do  
this cold.

Also, compiling on my windows box is faster than my old mac.
Since the backend is pretty much the same for all targets, it is
faster for me to dev on windows.

Hope this gives some insight into debugging.

Hugh





Appendix a: Debug

                | TLocal local_name ->
          let name = keyword_remap local_name in
                        print_endline ("Need local var :" ^ name );
                        if  not (Hashtbl.mem declarations name) then
                        begin
                        print_endline ("Need local var :" ^ name ^ " Undeclared !" );
                                Hashtbl.replace undeclared name (type_string expression.etype)
                        end
                | TMatch (condition, enum, cases, default) ->
                        print_endline ("search condition...");
                        find_undeclared_variables undeclared declarations this_suffix  
allow_this condition;
                        print_endline ("end search condition");
                        List.iter (fun (case_ids,params,cexpr) ->
                                let old_decs = Hashtbl.copy declarations in
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );
                           print_endline ("search case...");
                                Type.iter (find_undeclared_variables undeclared declarations  
this_suffix allow_this) cexpr;
                           print_endline ("searched case");
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: remove local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );

                                Hashtbl.clear declarations;
                                Hashtbl.iter ( Hashtbl.add declarations ) old_decs
                                ) cases;






> Ok, so I'm making progress on the issue where two nested switchs does not
> compile on cpp.
> It appears to be a problem with finding undeclared variables (shadowing).
>
> I am now wondering how I can debug that knowing:
>
> I have not found a way to make a 'print' inside the compilation process  
> in
> order to follow what's happening.
> Compiling haxe and then executing the test takes ages (>40 secs).
> I dunno/can't know(or don't know how) I can figure out how cases inside
> switch is expanded.
> Indeed, I need to traverse the switch and declare the variables bound  
> inside
> the case matchings before processing their inner expression.
>
> Any pointer accepted (I need to go fast as I have no time left (have to  
> port
> this app on IPad!!) )
>
> Thanks,
> Stephane
>
>
>
> --
> View this message in context:  
> Sent from the Haxe mailing list archive at Nabble.com.

--
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/hxcpp-code-gen-fix-tp6194311p6196863.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
In reply to this post by Gamehaxe
(just saw the commits)

On Tue, Mar 22, 2011 at 5:32 PM, Stephane Le Dorze <[hidden email]> wrote:
It works :)
Anyway, that was not a lost day.
I had the opportunity to work with VMWare on Linux using OcaIde, do some ocaml and learn a bit more about Haxe.
And one bug (and possibly others) are gone! :) (even if it was not my fix)

From that I think it would be nice to update the information on the wiki about how one can enable incremental compilation.
It's very annoying and I was not able to find how to myself.

Hugh, will you push these fixes?? (I can do it if one gimme access)

Good day :)
Stephane


On Tue, Mar 22, 2011 at 5:27 PM, Stephane Le Dorze <[hidden email]> wrote:
Lol,
I was figuring out that it was on TMach and got a basic output using

print_endline (Type.s_expr (type_string) expression);

I also saw the problem with the iter with TMatch but though that as it was pattern matched in find_undeclared_variables that it was not the source of the pb.

I'll try your proposition ti validate :)




On Tue, Mar 22, 2011 at 4:52 PM, Hugh Sanderson [via Haxe] <[hidden email]> wrote:
Hi,

So the debugging goes like this (bug 110).

You can use the command line arg "-D dump" to generate a dump file with  
the AST in it.

It appears the c++ code thinks the switch statement needs v2, which  
clearly is does not.
Since I am familiar with the code, I guess this is a failure in  
"find_undeclared_variables".

The switch-on-enum is the "TMatch" construct - so this is the place to  
start.
The variable is considered undefined when A "TLocal" is found, and the  
variable
in not found in the declared map.

So you can chuck a bunch if "print_endline" in the TMatch and TLocal cases  
of find_undeclared_variables.
See apendix A.

The debug goes....

search condition...
Need local var :a
end search condition
Case: local var :v1
search case...
Need local var :a
Need local var :v2
Need local var :v2 Undeclared !

...

It has already gone wrong - the case does not seem to recurse into the  
inner case when looking for declared variables.

Checking the recursion,
Type.iter (find_undeclared_variables .....   cexpr; // cexpr renamed in  
appendix

And therein lies the problem.  Type.iter, for a tmatch does:

| TMatch (e,_,cases,def) ->
     f e;
     List.iter (fun (_,_,e) -> f e) cases;
    (match def with None -> () | Some e -> f e)

Which does not visit the case names.

So the bug fix is to not use Type.iter to visit the case statements -  
instead use find_undeclared_variables directly.
ie,
find_undeclared_variables undeclared declarations this_suffix allow_this  
cexpr;

Which is actually simpler and better, and you just feel it is a "good" fix.

While I'm there, I'll also check for similar patterns (Type.iter used when  
it shouldn't be)
and there it is in the default bit too.

So the fix ends up being very simple, but I pity the fool who tries to do  
this cold.

Also, compiling on my windows box is faster than my old mac.
Since the backend is pretty much the same for all targets, it is
faster for me to dev on windows.

Hope this gives some insight into debugging.

Hugh





Appendix a: Debug

                | TLocal local_name ->
          let name = keyword_remap local_name in
                        print_endline ("Need local var :" ^ name );
                        if  not (Hashtbl.mem declarations name) then
                        begin
                        print_endline ("Need local var :" ^ name ^ " Undeclared !" );
                                Hashtbl.replace undeclared name (type_string expression.etype)
                        end
                | TMatch (condition, enum, cases, default) ->
                        print_endline ("search condition...");
                        find_undeclared_variables undeclared declarations this_suffix  
allow_this condition;
                        print_endline ("end search condition");
                        List.iter (fun (case_ids,params,cexpr) ->
                                let old_decs = Hashtbl.copy declarations in
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );
                           print_endline ("search case...");
                                Type.iter (find_undeclared_variables undeclared declarations  
this_suffix allow_this) cexpr;
                           print_endline ("searched case");
                                (match params with
                                | None -> ()
                                | Some l -> List.iter (fun (opt_name,t) ->
                                        match opt_name with | Some name ->
                                            print_endline ("Case: remove local var :" ^ name );
                                            Hashtbl.add declarations (keyword_remap name) () | _ -> ()  ) l
                                );

                                Hashtbl.clear declarations;
                                Hashtbl.iter ( Hashtbl.add declarations ) old_decs
                                ) cases;






> Ok, so I'm making progress on the issue where two nested switchs does not
> compile on cpp.
> It appears to be a problem with finding undeclared variables (shadowing).
>
> I am now wondering how I can debug that knowing:
>
> I have not found a way to make a 'print' inside the compilation process  
> in
> order to follow what's happening.
> Compiling haxe and then executing the test takes ages (>40 secs).
> I dunno/can't know(or don't know how) I can figure out how cases inside
> switch is expanded.
> Indeed, I need to traverse the switch and declare the variables bound  
> inside
> the case matchings before processing their inner expression.
>
> Any pointer accepted (I need to go fast as I have no time left (have to  
> port
> this app on IPad!!) )
>
> Thanks,
> Stephane
>
>
>
> --
> View this message in context:  
> Sent from the Haxe mailing list archive at Nabble.com.

--
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/hxcpp-code-gen-fix-tp6194311p6196863.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15





--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
In reply to this post by Nicolas Cannasse
I understand about 111 that if could seem not very useful to fix it and that's fine.
note that closures that capture variables will also add to the function params number however..
Anyway, they are other more usefull to track down first.. :)

On Tue, Mar 22, 2011 at 4:57 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 22/03/2011 16:49, Hugh Sanderson a écrit :
> Hi,
>
> So the debugging goes like this (bug 110).

What about bug 111 then ?

:-D

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/hxcpp-code-gen-fix-tp6194311p6196889.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Gamehaxe
In reply to this post by Nicolas Cannasse
That one is left as an exercise for the reader.

Although 111 is interesting.  I have limited the arg count to 12 in hxcpp.
I can increase this, but there is a small overhead per class (not class  
instance)
for each arg.

In all my years programming, I don't think I've got above about 10.
At some point, it becomes more satisfying to bundle them into a structure.
eg:
RenderTexture( x0,y0, x1,y1,  tx0,ty0,tx1,ty1, normx0,normy0,  
normx1,normy1 )

becomes

RenderTexture(source_rect, texture_rect, norm_rect);


I could arbitrarily extend it, or implement "more than 12 is an array".
I'm not keen on either option, but I could be convinced.

Hugh


> Le 22/03/2011 16:49, Hugh Sanderson a écrit :
>> Hi,
>>
>> So the debugging goes like this (bug 110).
>
> What about bug 111 then ?
>
> :-D
>
> Nicolas

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

Re: hxcpp code gen fix..

Cauê W.
Hugh, maybe you can stuff all the args into an array if it has more than 12 args? It's not very performant but still compiles if the user really needs to use it
I'm doing this on hxcs for function objects (which is different from class functions - which don't have this limitation).

2011/3/22 Hugh Sanderson <[hidden email]>
That one is left as an exercise for the reader.

Although 111 is interesting.  I have limited the arg count to 12 in hxcpp.
I can increase this, but there is a small overhead per class (not class instance)
for each arg.

In all my years programming, I don't think I've got above about 10.
At some point, it becomes more satisfying to bundle them into a structure.
eg:
RenderTexture( x0,y0, x1,y1,  tx0,ty0,tx1,ty1, normx0,normy0, normx1,normy1 )

becomes

RenderTexture(source_rect, texture_rect, norm_rect);


I could arbitrarily extend it, or implement "more than 12 is an array".
I'm not keen on either option, but I could be convinced.

Hugh



Le 22/03/2011 16:49, Hugh Sanderson a écrit :
Hi,

So the debugging goes like this (bug 110).

What about bug 111 then ?

:-D

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: hxcpp code gen fix..

sledorze
In reply to this post by Gamehaxe
Looks like 105 & 106 are gone too! :)

On Tue, Mar 22, 2011 at 5:42 PM, Hugh Sanderson [via Haxe] <[hidden email]> wrote:
That one is left as an exercise for the reader.

Although 111 is interesting.  I have limited the arg count to 12 in hxcpp.
I can increase this, but there is a small overhead per class (not class  
instance)
for each arg.

In all my years programming, I don't think I've got above about 10.
At some point, it becomes more satisfying to bundle them into a structure.
eg:
RenderTexture( x0,y0, x1,y1,  tx0,ty0,tx1,ty1, normx0,normy0,  
normx1,normy1 )

becomes

RenderTexture(source_rect, texture_rect, norm_rect);


I could arbitrarily extend it, or implement "more than 12 is an array".
I'm not keen on either option, but I could be convinced.

Hugh


> Le 22/03/2011 16:49, Hugh Sanderson a écrit :
>> Hi,
>>
>> So the debugging goes like this (bug 110).
>
> What about bug 111 then ?
>
> :-D
>
> 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/hxcpp-code-gen-fix-tp6194311p6197090.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

sledorze
In reply to this post by Nicolas Cannasse
Nicolas,
I am printing the dump of the 107:
( http://code.google.com/p/hxcpp/issues/detail?id=107 )

and would like to be sure of haxe semantic in this case;
look at bar1 method types, I think there's an issue here..
What do you think? (below the output is the source).

class Test107{
        public bar2(inline method) : Void -> Void

         = (Function() : Void = (Block {
(Vars val : Int = (Const 0 : Int) : Void);
} : Void) : Void -> Void);

        public bar1(method) : Void -> Void

         = (Function() : Void = (Block {
(Return (Vars val : Int = (Const 0 : Int) : Void) : Dynamic);
} : Dynamic) : Void -> Void);

        static public main(method) : Void -> Void

         = (Function() : Void = (Block {
} : Void) : Void -> Void);

}

-------------------------

Source:

class Test107 {	

inline public function bar2() {
var val = 0;
}

public function bar1() {
return bar2();
}

}



On Tue, Mar 22, 2011 at 4:57 PM, Nicolas Cannasse [via Haxe] <[hidden email]> wrote:
Le 22/03/2011 16:49, Hugh Sanderson a écrit :
> Hi,
>
> So the debugging goes like this (bug 110).

What about bug 111 then ?

:-D

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/hxcpp-code-gen-fix-tp6194311p6196889.html
To unsubscribe from hxcpp code gen fix.., click here.



--
Stéphane Le Dorze

Tel: +33 (0) 6 08  76 70 15


Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Nicolas Cannasse
Le 22/03/2011 18:33, sledorze a écrit :
> Nicolas,
> I am printing the dump of the 107:
> ( http://code.google.com/p/hxcpp/issues/detail?id=107
> <http://code.google.com/p/hxcpp/issues/detail?id=107> )
>
> and would like to be sure of haxe semantic in this case;
> look at bar1 method types, I think there's an issue here..
> What do you think? (below the output is the source).

Apart from the Dynamic, which I think doesn't change much things, it
seems correct to me.

The issue here is that you're returning a Void value. That should maybe
be actually forbidden by the compiler since most language does not treat
Void as a value but mostly as the absence of value.

Nicolas

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

Re: hxcpp code gen fix..

sledorze
I think Dynamic is wrong here and it could changes things for the backends as they cannot figure what to do without much reinterpretation of the actual code.

Today this case is not handled in a target agnostic way (either issued by the haxe compiler as a wrong construct or transformed in a cleanly typed ast).

((I don't think we can blame the cpp backend for that))

I propose to re-report the bug as a haxe one (for consistency).

Agree?

Reply | Threaded
Open this post in threaded view
|

Re: hxcpp code gen fix..

Gamehaxe
Hi,
One fix I had in mind for this one was to change all things that return
Void to return "null". Or perhaps to actually make "Void"="Null".
The auto-generated functions already to this, and it seems to be what neko  
likes.
In the c++ backend, the null class has size 0, so there is no overhead
returning it.
I guess the problem with this is that the only way to generate the
problem is in-lining, because it is an error if you write it directly
like the inliner would generate.

Hugh

> I think Dynamic is wrong here and it could changes things for the  
> backends as
> they cannot figure what to do without much reinterpretation of the actual
> code.
>
> Today this case is not handled in a target agnostic way (either issued by
> the haxe compiler as a wrong construct or transformed in a cleanly typed
> ast).
>
> ((I don't think we can blame the cpp backend for that))
>
> I propose to re-report the bug as a haxe one (for consistency).
>
> Agree?
>
>
>
> --
> View this message in context:  
> http://haxe.1354130.n2.nabble.com/hxcpp-code-gen-fix-tp6194311p6197551.html
> Sent from the Haxe mailing list archive at Nabble.com.

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