New @:build system

[Nicolas Cannasse]

Hi,

I've changed some things in the macros Expr and modified the way @:build
work : before, @:build was generating additional class/enum fields. Now,
@:build take as parameter the user-declared fields and can return more
fields and modify the existing fields before they get typed.

See http://haxe.org/manual/macros/build for (short) documentation.

Best,
Nicolas

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

[Heinz Hölzer-2]

Am 17.05.2011 11:24, schrieb Nicolas Cannasse:

Hi,

I've changed some things in the macros Expr and modified the way @:build work : before, @:build was generating additional class/enum fields. Now, @:build take as parameter the user-declared fields and can return more fields and modify the existing fields before they get typed.

See http://haxe.org/manual/macros/build for (short) documentation.

Best,
Nicolas

thx, awesome feature :)

I did a small test and found out that Completion for returned fields is somewhat broken now.

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

// the classMacro returns a static field foo, which compiles and runs fine
@:build(ClassMacro.build()) class C {}

class Main
{
    static function main()
    {
        C. // completion error: File "typer.ml", line 1970, characters 10-16 Assertion failed (display D:\....\Main.hx@120
    }
}

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

[Dion Whitehead Amago]

After wrestling with the new version today, I think the new build
method is much more complicated to use.

Previously, to build class members, you add all the built class member
Expr blocks in an EBlock array.  That was fairly straightforward.

Now, you have to place the new members in an obscure, sub-sub-sub
field of an already complicated, difficult to understand data
structure.  And a problem I've encountered with macros is that the
complicated data structures needed for building class members can be
difficult to debug.

I understand that the data structures *have* to be complicated, since
code trees are represented symbolically, but it would be nice if the
common uses (building classes judging from the mailing list) were made
straightforward.

BTW, macros are great.  I've just built an AsyncProxy that's
asynchronous at both ends (flash and js), rather than asynchronous
only on the client (as it is currently with AsyncProxy).  Macros and
autoBuild are great for making complicated processes simple and type
safe.

Dion

On Tue, May 17, 2011 at 4:24 AM, Nicolas Cannasse
<[hidden email]> wrote:

> Hi,
>
> I've changed some things in the macros Expr and modified the way @:build
> work : before, @:build was generating additional class/enum fields. Now,
> @:build take as parameter the user-declared fields and can return more
> fields and modify the existing fields before they get typed.
>
> See http://haxe.org/manual/macros/build for (short) documentation.
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

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

[Nemea Lion]

The new system looks interesting, as you can modifify already defined field, but
i'll have to test it. Is this change definitive, or is in evaluation?, as this will break
compatibility with older build macros, or am I wrong?
(Late in night, haven't analysed the new build that well)

Carlos

2011/5/17 Nicolas Cannasse <[hidden email]>

Hi,

I've changed some things in the macros Expr and modified the way @:build work : before, @:build was generating additional class/enum fields. Now, @:build take as parameter the user-declared fields and can return more fields and modify the existing fields before they get typed.

See http://haxe.org/manual/macros/build for (short) documentation.

Best,
Nicolas

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

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

[Nicolas Cannasse]

Le 18/05/2011 01:31, Dion Amago a écrit :

> After wrestling with the new version today, I think the new build
> method is much more complicated to use.
>
> Previously, to build class members, you add all the built class member
> Expr blocks in an EBlock array.  That was fairly straightforward.
>
> Now, you have to place the new members in an obscure, sub-sub-sub
> field of an already complicated, difficult to understand data
> structure.  And a problem I've encountered with macros is that the
> complicated data structures needed for building class members can be
> difficult to debug.

I understand that and I do agree with you. One possibility would be to
change build first argument in order to directly pass an Array<Field>
instead of the current Expr. However since the whole macro system has
been built for passing/returning Expr's, that's a bit hard to fix. I'll
try however to look at it asap.

Best,
Nicolas

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

[Nicolas Cannasse]

Le 18/05/2011 05:43, Nemea Lion a écrit :
> The new system looks interesting, as you can modifify already defined
> field, but
> i'll have to test it. Is this change definitive, or is in evaluation?,
> as this will break
> compatibility with older build macros, or am I wrong?
> (Late in night, haven't analysed the new build that well)

It's still experimental since I'm not perfectly satisfied with it right
now, but the previous @:build system was also an hackish experiment, so
please consider that this feature might evolve until 2.08 release.

Nicolas

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

[Nicolas Cannasse]

> // the classMacro returns a static field foo, which compiles and runs fine
> @:build(ClassMacro.build()) class C {}
>
> class Main
> {
> static function main()
> {
> C. // completion error: File "typer.ml", line 1970, characters 10-16
> Assertion failed (display D:\....\Main.hx@120
> }
> }

Could you send me a fully reproducing sample ? (in one .hx file please)
This error indeed looks strange.

Nicolas

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

[Nicolas Cannasse]

Le 17/05/2011 11:24, Nicolas Cannasse a écrit :
> Hi,
>
> I've changed some things in the macros Expr and modified the way @:build
> work : before, @:build was generating additional class/enum fields. Now,
> @:build take as parameter the user-declared fields and can return more
> fields and modify the existing fields before they get typed.
>
> See http://haxe.org/manual/macros/build for (short) documentation.

Second take in r3817 :

- build macros should return Array<Field>
- you can call haxe.macro.Context.getBuildFields() to get the
user-declared fields list

Looks a lot better this way, maybe I'll not touch it anymore ;)

Best,
Nicolas

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

[Nemea Lion]

Problem is, nigthly build r3817 didn't have the new haxe.exe, just the std library.
(Wanted to try....)

Carlos

2011/5/18 Nicolas Cannasse <[hidden email]>

Le 17/05/2011 11:24, Nicolas Cannasse a écrit :

Hi,

I've changed some things in the macros Expr and modified the way @:build
work : before, @:build was generating additional class/enum fields. Now,
@:build take as parameter the user-declared fields and can return more
fields and modify the existing fields before they get typed.

See http://haxe.org/manual/macros/build for (short) documentation.

Second take in r3817 :

- build macros should return Array<Field>
- you can call haxe.macro.Context.getBuildFields() to get the user-declared fields list

Looks a lot better this way, maybe I'll not touch it anymore ;)

Best,
Nicolas

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

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

[laurence taylor]

Hi, don't want to impose, but could I have a look at that AsyncProxy code? 

regards,

Laurence

On Wed, May 18, 2011 at 1:31 AM, Dion Amago <[hidden email]> wrote:

After wrestling with the new version today, I think the new build
method is much more complicated to use.

Previously, to build class members, you add all the built class member
Expr blocks in an EBlock array.  That was fairly straightforward.

Now, you have to place the new members in an obscure, sub-sub-sub
field of an already complicated, difficult to understand data
structure.  And a problem I've encountered with macros is that the
complicated data structures needed for building class members can be
difficult to debug.

I understand that the data structures *have* to be complicated, since
code trees are represented symbolically, but it would be nice if the
common uses (building classes judging from the mailing list) were made
straightforward.

BTW, macros are great.  I've just built an AsyncProxy that's
asynchronous at both ends (flash and js), rather than asynchronous
only on the client (as it is currently with AsyncProxy).  Macros and
autoBuild are great for making complicated processes simple and type
safe.

Dion

On Tue, May 17, 2011 at 4:24 AM, Nicolas Cannasse
<[hidden email]> wrote:
> Hi,
>
> I've changed some things in the macros Expr and modified the way @:build
> work : before, @:build was generating additional class/enum fields. Now,
> @:build take as parameter the user-declared fields and can return more
> fields and modify the existing fields before they get typed.
>
> See http://haxe.org/manual/macros/build for (short) documentation.
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

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

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

[Dion Whitehead Amago]

I'll post in a public repo in the next couple of days and let you know.

On Wed, May 18, 2011 at 2:44 PM, laurence taylor <[hidden email]> wrote:
> Hi, don't want to impose, but could I have a look at that AsyncProxy code?
> regards,
> Laurence

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

[Ruben Weijers]

Hi,

The last 2 days I've been playing around with the new autoBuild/build feature and I'm running into some strange behaviour when it comes to generating constructors.

Testcase1:

@:build(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

@:autoBuild(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

class Test0 {}

class Test1 extends Test0

{

public var clientA : Client;

public  var clientB : Client;

}

class Test2 extends Test1

{

public var clientC : Client;

}

var a = new Test2();

trace(a.clientA); //Client

trace(a.clientB); //Client

trace(a.clientC); //Client

This works perfect.. It's generating 3 constructors which instantiate all fields of type IClient and call "super();" if the class is a subclass.

Testcase2:

@:build(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

@:autoBuild(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

class Test0 {}

class Test1 extends Test0

{

public var clientA : Client;

public  var clientB : Client;

}

class Test2 extends Test1

{

public var clientC : Client;

public function new () {}

}

var a = new Test2();

trace(a.clientA); //Client

trace(a.clientB); //Client

trace(a.clientC); //Client

this also works perfect. It's generating 2 constructors for Test0 and Test1, and it add's "clientC = new Client();" to the constructor of Test2

Testcase3:

@:build(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

@:autoBuild(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

class Test0 {}

class Test1 extends Test0

{

public var clientA : Client;

public  var clientB : Client;

public function new () {}

}

class Test2 extends Test1

{

public var clientC : Client;

}

var a = new Test2();

trace(a.clientA); //Client

trace(a.clientB); //Client

trace(a.clientC); //null

This is where my tests fails. In my console I see 2 constructors being generated, one for Test0 and one for Test2. And I see the instantiation of clientA and clientB in the constructor of test2.

When I instantiate Test2, only the constructor Test1 is called.

Testcase4:

@:build(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

@:autoBuild(primevc.utils.MacroUtils.autoInstantiate("IClient", "Client"))

class Test0 {

public function new () {}

}

class Test1 extends Test0

{

public var clientA : Client;

public  var clientB : Client;

public function new () {}

}

class Test2 extends Test1

{

public var clientC : Client;

public function new () {}

}

var a = new Test2();

trace(a.clientA); //Client

trace(a.clientB); //Client

trace(a.clientC); //Client

This works perfect again...

Is there a special way how constructors should be generated compared to generating normal methods (which do work perfect in all 4 cases)?

Thanks,

Ruben

Op 19 mei 2011, om 06:40 heeft Dion Amago het volgende geschreven:

I'll post in a public repo in the next couple of days and let you know.

On Wed, May 18, 2011 at 2:44 PM, laurence taylor <[hidden email]> wrote:

Hi, don't want to impose, but could I have a look at that AsyncProxy code?

regards,

Laurence

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

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

[Nicolas Cannasse]

Le 19/05/2011 15:12, Ruben Weijers a écrit :
> Hi,
>
> The last 2 days I've been playing around with the new autoBuild/build
> feature and I'm running into some strange behaviour when it comes to
> generating constructors.
[...]
> This works perfect again...
>
> Is there a special way how constructors should be generated compared to
> generating normal methods (which do work perfect in all 4 cases)?

There shouldn't be any specific case for constructors.
Try to reproduce with a small example and send it to me.
Also check that it's not platform-specific behavior.

Nicolas

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

[Ruben Weijers]

Hi Nicolas,

I've added a zip file with a testcase (2 files). I've tried to minify the code and tested it with neko and flash. Both give the same result.

Compiled it with:
haxe -neko MacroTests.n -debug -main MacroTests  && neko MacroTests.n
haxe -swf MacroTests.swf -debug -main MacroTests  && open MacroTests.swf

Ruben





Op 19 mei 2011, om 15:18 heeft Nicolas Cannasse het volgende geschreven:

> Le 19/05/2011 15:12, Ruben Weijers a écrit :
>> Hi,
>>
>> The last 2 days I've been playing around with the new autoBuild/build
>> feature and I'm running into some strange behaviour when it comes to
>> generating constructors.
> [...]
>> This works perfect again...
>>
>> Is there a special way how constructors should be generated compared to
>> generating normal methods (which do work perfect in all 4 cases)?
>
> There shouldn't be any specific case for constructors.
> Try to reproduce with a small example and send it to me.
> Also check that it's not platform-specific behavior.
>
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org

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

[Heinz Hölzer-2]

I checked your example and i think it's done right,

you can generate a js file with (-js test.js) to see the generated sourcecode.


Am 19.05.2011 16:14, schrieb Ruben Weijers:

Hi Nicolas,

I've added a zip file with a testcase (2 files). I've tried to minify the code and tested it with neko and flash. Both give the same result.

Compiled it with:
haxe -neko MacroTests.n -debug -main MacroTests  && neko MacroTests.n
haxe -swf MacroTests.swf -debug -main MacroTests  && open MacroTests.swf

Ruben

Op 19 mei 2011, om 15:18 heeft Nicolas Cannasse het volgende geschreven:

Le 19/05/2011 15:12, Ruben Weijers a écrit :

Hi,

The last 2 days I've been playing around with the new autoBuild/build
feature and I'm running into some strange behaviour when it comes to
generating constructors.

[...]

This works perfect again...

Is there a special way how constructors should be generated compared to
generating normal methods (which do work perfect in all 4 cases)?

There shouldn't be any specific case for constructors.
Try to reproduce with a small example and send it to me.
Also check that it's not platform-specific behavior.

Nicolas

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

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

[Ruben Weijers]

The js-file clarifies that the constructor of Test4 is called and the trace-statement in this constructor is missing.

I'm not sure why since the constructor of Test2 is created on the same way (curDef: 'null'; hasSuper: 'true' for both)..

Ruben

Op 19 mei 2011, om 19:30 heeft Heinz Hölzer het volgende geschreven:

I checked your example and i think it's done right,

you can generate a js file with (-js test.js) to see the generated sourcecode.


Am 19.05.2011 16:14, schrieb Ruben Weijers:

Hi Nicolas,

I've added a zip file with a testcase (2 files). I've tried to minify the code and tested it with neko and flash. Both give the same result.

Compiled it with:
haxe -neko MacroTests.n -debug -main MacroTests  && neko MacroTests.n
haxe -swf MacroTests.swf -debug -main MacroTests  && open MacroTests.swf

Ruben

Op 19 mei 2011, om 15:18 heeft Nicolas Cannasse het volgende geschreven:

Le 19/05/2011 15:12, Ruben Weijers a écrit :

Hi,

The last 2 days I've been playing around with the new autoBuild/build
feature and I'm running into some strange behaviour when it comes to
generating constructors.

[...]

This works perfect again...

Is there a special way how constructors should be generated compared to
generating normal methods (which do work perfect in all 4 cases)?

There shouldn't be any specific case for constructors.
Try to reproduce with a small example and send it to me.
Also check that it's not platform-specific behavior.

Nicolas

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

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

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