JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

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

JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Elsass Philippe
Here's the haxe svn-patch: 
http://pastie.org/2581789

It was tested with 2 Jeash samples so I assume it generally works ;)

There are quite a few changes:
- rewrite of the prototypes generation (cleaner, smaller code), 
- fixes for compatibility with google closure "simple" compiler (no luck with "advanced"),
- Reflect.field/setField now recognizes getter/setters (using some new generated metadatas) with very little overhead (no prototype crawling as the metadatas use inheritance),
- Type.createEmptyInstance doesn't require the "ugly constructor hack" anymore,
- using Function.bind() instead of the string-based $closure (future-proof).

One simple sample (text+graphic) was initially 360Kb. After these changes it outputs at 344Kb (82Kb gzip -6), then after google closure minification it's down to 279Kb (70Kb gzip -6).

All this comes for free: no code change, just recompile.

I hope this sounds good to you people :)

Philippe

PS: other targets (like neko) could benefit from a similar properties-metadata generation because it's also not possible to safely discover the getter/setter functions of Dynamic objects using Reflect.


On Sat, Sep 24, 2011 at 10:32 PM, <[hidden email]> wrote:
Send Haxe mailing list submissions to
       [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.motion-twin.com/mailman/listinfo/haxe
or, via email, send a message with subject or body 'help' to
       [hidden email]

You can reach the person managing the list at
       [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haxe digest..."


Today's Topics:

  1. Re: Failed to load library: nme.ndll (Maximiliano Fern?ndez)
  2. Re: enum questions (benjamin Dubois)
  3. Re: enum questions (Cau? Waneck)
  4. Re: enum questions (benjamin Dubois)
  5. Re: Re: constraints for type parameters - usage of anonymous
     types and in functions (Nicolas Cannasse)
  6. Re: Re: Haxe JS ignores getters/setters when using
     Reflect.setField (Nicolas Cannasse)


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

Message: 1
Date: Sat, 24 Sep 2011 14:48:58 -0300
From: Maximiliano Fern?ndez <[hidden email]>
Subject: Re: [haXe] Failed to load library: nme.ndll
To: The haXe compiler list <[hidden email]>
Message-ID:
       <CADcZx6gYquJDBFt2c_MKUAnPu=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Sorry, I had to go. I use Linux, so I cannot tell you something useful to
help you. Some time ago I compiled NME from source. Was a stressful task,
but reached to my objective. I didn't have that problem you had, but had
some others. When I compiled it I done something like:

1) Get hxcpp from SVN ( http://code.google.com/p/hxcpp )
2) Cmd: haxelib dev hxcpp $path_to_hxcpp_svn_version
3) Cmd: cd $path_to_hxcpp_svn_version/runtime
4) Cmd: haxelib run hxcpp BuildLibs.xml (Also, you can put compilation flags
like -Dandroid to compile the libs for android toolchain. I compiled in that
time the Linux ones: -Dlinux)

Next...
1) Get NME from SVN ( You know where ) and sdl-static ( don't have the URL
right now ). The directory tree may look like:
 sources-dir/
  |->nekonme/
  |->sdl-static/
2) Cmd: cd $nekonme_dir/project
3) Make sure you have all enviroment vars ok: HAXE_LIBRARY_PATH, HAXE_HOME,
NEKOPATH (Perhaps I forgot some var) and the includes are also ok (Don't
have a list right now, but I remember having troubles with freetype include
files and some other)
4) Cmd: haxelib run hxcpp Build.xml (You can use compilation flags, as with
hxcpp libs)

And after make that:
1) Cmd: cd $nekonme_dir/install-tool
2) Cmd: haxe InstallTool.hx

And that's all!! I didn't understand if you had success with the
compilation. Having spaces in paths it's problematic, true. Tell me how are
you going... I'm not the right one to give you "good help", but I'm trying
to help.

Good journey into haXe! ;)

Max
0 1 0 | 0 0 1 | 1 1 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/844e88d1/attachment-0001.htm

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

Message: 2
Date: Sat, 24 Sep 2011 22:00:08 +0200
From: benjamin Dubois <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:
       <CADjd8CTvcBS2FTyCre7jSdY=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Is there an equivalent for the Neko target this hack

> enum Option {
>        auto;
>        cool;
>        hard;
> }
> This will allow you to write Option.auto which will be an Option (and not a
> string, so it can't be used as String in haXe code).
> Then since you want it to be a String _at runtime only_, you can declare
> the Option enum as "extern" and add somewhere in your code :
> __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
> This will make sure that Option.auto == "auto"


Maybe using builtins ?

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/20a99018/attachment-0001.htm

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

Message: 3
Date: Sat, 24 Sep 2011 17:08:59 -0300
From: Cau? Waneck <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:
       <CAPHLdhyRtxPLjA4A2G47CuEFcem3EGK+-4r+THVDeVWrGvR=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

you can always use @:native metadata, as previously stated. Though I don't
know if it will work on C++ because seems cpp doesn't like classes defined
as externs

2011/9/24 benjamin Dubois <[hidden email]>

> Is there an equivalent for the Neko target this hack
>
> enum Option {
>>        auto;
>>        cool;
>>        hard;
>> }
>> This will allow you to write Option.auto which will be an Option (and not
>> a string, so it can't be used as String in haXe code).
>> Then since you want it to be a String _at runtime only_, you can declare
>> the Option enum as "extern" and add somewhere in your code :
>> __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
>> This will make sure that Option.auto == "auto"
>
>
> Maybe using builtins ?
>
> Ben
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/eedfb0f9/attachment-0001.htm

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

Message: 4
Date: Sat, 24 Sep 2011 22:22:43 +0200
From: benjamin Dubois <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:
       <CADjd8CTZ3pc3YCOgB4w4BT2y0OhN6S9pC7LDpzE8eQB2-=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Sorry I'm not used to using metadata can you post an simple example please
:)

On Sat, Sep 24, 2011 at 10:08 PM, Cauê Waneck <[hidden email]> wrote:

> you can always use @:native metadata, as previously stated. Though I don't
> know if it will work on C++ because seems cpp doesn't like classes defined
> as externs
>
> 2011/9/24 benjamin Dubois <[hidden email]>
>
>> Is there an equivalent for the Neko target this hack
>>
>> enum Option {
>>>        auto;
>>>        cool;
>>>        hard;
>>> }
>>> This will allow you to write Option.auto which will be an Option (and not
>>> a string, so it can't be used as String in haXe code).
>>> Then since you want it to be a String _at runtime only_, you can declare
>>> the Option enum as "extern" and add somewhere in your code :
>>> __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
>>> This will make sure that Option.auto == "auto"
>>
>>
>> Maybe using builtins ?
>>
>> Ben
>>
>>
>> --
>>
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/e9ca6c9a/attachment-0001.htm

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

Message: 5
Date: Sat, 24 Sep 2011 22:28:50 +0200
From: Nicolas Cannasse <[hidden email]>
Subject: Re: [haXe] Re: constraints for type parameters - usage of
       anonymous       types and in functions
To: The haXe compiler list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 24/09/2011 01:29, Roger a écrit :
>
> Nicolas Cannasse wrote:
>>
>>> The first is the important one, so let's sumarize it:
>>> Allow *anonymous types* as type parameter constraints, because:
>>> 1. they are more elegant and flexible
>>> 2. they allow friend relationships
>>
>> Yes, that seems possible, I'll put that on the feature list.
>>
>>
>
> When will this be included in HaXe? I also really need this feature, and it
> was requested almost 2 years ago.

Forgot about it, now added here :
http://code.google.com/p/haxe/issues/detail?id=516

Best,
Nicolas



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

Message: 6
Date: Sat, 24 Sep 2011 22:32:13 +0200
From: Nicolas Cannasse <[hidden email]>
Subject: Re: [haXe] Re: Haxe JS ignores getters/setters when using
       Reflect.setField
To: The haXe compiler list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 23/09/2011 16:52, Elsass Philippe a écrit :
> Hello,
>
> I've been mucking around haxe JS generator and I'm fixing a few things:
> - compatibility with google closure "simple" compiler (done, outputs
> code 20% smaller) but still no luck with the "advanced" compiler,
> - using Function.bind() instead of $closure() for haxe closures (done,
> safer with code optimizers),
> - reflecting getters/setters, by automatically generating meta
> information about properties (meta generation done, now have to modify
> Reflect to use this info).
>
> I'm also going to modify the code generation to emit much more compact
> (and probably faster) prototypes declaration. This should reduce the JS
> weight by another 10-20%.

Tell me when you're done so we can see how we merge that into haXe/SVN ;)

Best,
Nicolas



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

_______________________________________________
Haxe mailing list
[hidden email]
http://lists.motion-twin.com/mailman/listinfo/haxe


End of Haxe Digest, Vol 71, Issue 152
*************************************



--
Philippe

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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

clemos
Hi,

Looks great :)
But I think the Reflect getter/setter thing should be implemented on
all platforms.
Otherwise getter/setter will become really tricky to use since they
will behave really differently across platforms.

Cheers,
Clément

On Sun, Sep 25, 2011 at 1:13 AM, Elsass Philippe
<[hidden email]> wrote:

> Here's the haxe svn-patch:
> http://pastie.org/2581789
> It was tested with 2 Jeash samples so I assume it generally works ;)
> There are quite a few changes:
> - rewrite of the prototypes generation (cleaner, smaller code),
> - fixes for compatibility with google closure "simple" compiler (no luck
> with "advanced"),
> - Reflect.field/setField now recognizes getter/setters (using some new
> generated metadatas) with very little overhead (no prototype crawling as the
> metadatas use inheritance),
> - Type.createEmptyInstance doesn't require the "ugly constructor hack"
> anymore,
> - using Function.bind() instead of the string-based $closure (future-proof).
> One simple sample (text+graphic) was initially 360Kb. After these changes it
> outputs at 344Kb (82Kb gzip -6), then after google closure minification it's
> down to 279Kb (70Kb gzip -6).
> All this comes for free: no code change, just recompile.
> I hope this sounds good to you people :)
> Philippe
> PS: other targets (like neko) could benefit from a similar
> properties-metadata generation because it's also not possible to safely
> discover the getter/setter functions of Dynamic objects using Reflect.
>
> On Sat, Sep 24, 2011 at 10:32 PM, <[hidden email]>
> wrote:
>>
>> Send Haxe mailing list submissions to
>>        [hidden email]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://lists.motion-twin.com/mailman/listinfo/haxe
>> or, via email, send a message with subject or body 'help' to
>>        [hidden email]
>>
>> You can reach the person managing the list at
>>        [hidden email]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Haxe digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Failed to load library: nme.ndll (Maximiliano Fern?ndez)
>>   2. Re: enum questions (benjamin Dubois)
>>   3. Re: enum questions (Cau? Waneck)
>>   4. Re: enum questions (benjamin Dubois)
>>   5. Re: Re: constraints for type parameters - usage of anonymous
>>      types and in functions (Nicolas Cannasse)
>>   6. Re: Re: Haxe JS ignores getters/setters when using
>>      Reflect.setField (Nicolas Cannasse)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 24 Sep 2011 14:48:58 -0300
>> From: Maximiliano Fern?ndez <[hidden email]>
>> Subject: Re: [haXe] Failed to load library: nme.ndll
>> To: The haXe compiler list <[hidden email]>
>> Message-ID:
>>
>>  <CADcZx6gYquJDBFt2c_MKUAnPu=[hidden email]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Sorry, I had to go. I use Linux, so I cannot tell you something useful to
>> help you. Some time ago I compiled NME from source. Was a stressful task,
>> but reached to my objective. I didn't have that problem you had, but had
>> some others. When I compiled it I done something like:
>>
>> 1) Get hxcpp from SVN ( http://code.google.com/p/hxcpp )
>> 2) Cmd: haxelib dev hxcpp $path_to_hxcpp_svn_version
>> 3) Cmd: cd $path_to_hxcpp_svn_version/runtime
>> 4) Cmd: haxelib run hxcpp BuildLibs.xml (Also, you can put compilation
>> flags
>> like -Dandroid to compile the libs for android toolchain. I compiled in
>> that
>> time the Linux ones: -Dlinux)
>>
>> Next...
>> 1) Get NME from SVN ( You know where ) and sdl-static ( don't have the URL
>> right now ). The directory tree may look like:
>>  sources-dir/
>>   |->nekonme/
>>   |->sdl-static/
>> 2) Cmd: cd $nekonme_dir/project
>> 3) Make sure you have all enviroment vars ok: HAXE_LIBRARY_PATH,
>> HAXE_HOME,
>> NEKOPATH (Perhaps I forgot some var) and the includes are also ok (Don't
>> have a list right now, but I remember having troubles with freetype
>> include
>> files and some other)
>> 4) Cmd: haxelib run hxcpp Build.xml (You can use compilation flags, as
>> with
>> hxcpp libs)
>>
>> And after make that:
>> 1) Cmd: cd $nekonme_dir/install-tool
>> 2) Cmd: haxe InstallTool.hx
>>
>> And that's all!! I didn't understand if you had success with the
>> compilation. Having spaces in paths it's problematic, true. Tell me how
>> are
>> you going... I'm not the right one to give you "good help", but I'm trying
>> to help.
>>
>> Good journey into haXe! ;)
>>
>> Max
>> 0 1 0 | 0 0 1 | 1 1 1
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/844e88d1/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 24 Sep 2011 22:00:08 +0200
>> From: benjamin Dubois <[hidden email]>
>> Subject: Re: [haXe] enum questions
>> To: The haXe compiler list <[hidden email]>
>> Message-ID:
>>
>>  <CADjd8CTvcBS2FTyCre7jSdY=[hidden email]>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Is there an equivalent for the Neko target this hack
>>
>> > enum Option {
>> >        auto;
>> >        cool;
>> >        hard;
>> > }
>> > This will allow you to write Option.auto which will be an Option (and
>> > not a
>> > string, so it can't be used as String in haXe code).
>> > Then since you want it to be a String _at runtime only_, you can declare
>> > the Option enum as "extern" and add somewhere in your code :
>> > __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
>> > This will make sure that Option.auto == "auto"
>>
>>
>> Maybe using builtins ?
>>
>> Ben
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/20a99018/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 24 Sep 2011 17:08:59 -0300
>> From: Cau? Waneck <[hidden email]>
>> Subject: Re: [haXe] enum questions
>> To: The haXe compiler list <[hidden email]>
>> Message-ID:
>>
>>  <CAPHLdhyRtxPLjA4A2G47CuEFcem3EGK+-4r+THVDeVWrGvR=[hidden email]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> you can always use @:native metadata, as previously stated. Though I don't
>> know if it will work on C++ because seems cpp doesn't like classes defined
>> as externs
>>
>> 2011/9/24 benjamin Dubois <[hidden email]>
>>
>> > Is there an equivalent for the Neko target this hack
>> >
>> > enum Option {
>> >>        auto;
>> >>        cool;
>> >>        hard;
>> >> }
>> >> This will allow you to write Option.auto which will be an Option (and
>> >> not
>> >> a string, so it can't be used as String in haXe code).
>> >> Then since you want it to be a String _at runtime only_, you can
>> >> declare
>> >> the Option enum as "extern" and add somewhere in your code :
>> >> __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
>> >> This will make sure that Option.auto == "auto"
>> >
>> >
>> > Maybe using builtins ?
>> >
>> > Ben
>> >
>> >
>> > --
>> > haXe - an open source web programming language
>> > http://haxe.org
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/eedfb0f9/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 24 Sep 2011 22:22:43 +0200
>> From: benjamin Dubois <[hidden email]>
>> Subject: Re: [haXe] enum questions
>> To: The haXe compiler list <[hidden email]>
>> Message-ID:
>>
>>  <CADjd8CTZ3pc3YCOgB4w4BT2y0OhN6S9pC7LDpzE8eQB2-=[hidden email]>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Sorry I'm not used to using metadata can you post an simple example please
>> :)
>>
>> On Sat, Sep 24, 2011 at 10:08 PM, Cauê Waneck <[hidden email]> wrote:
>>
>> > you can always use @:native metadata, as previously stated. Though I
>> > don't
>> > know if it will work on C++ because seems cpp doesn't like classes
>> > defined
>> > as externs
>> >
>> > 2011/9/24 benjamin Dubois <[hidden email]>
>> >
>> >> Is there an equivalent for the Neko target this hack
>> >>
>> >> enum Option {
>> >>>        auto;
>> >>>        cool;
>> >>>        hard;
>> >>> }
>> >>> This will allow you to write Option.auto which will be an Option (and
>> >>> not
>> >>> a string, so it can't be used as String in haXe code).
>> >>> Then since you want it to be a String _at runtime only_, you can
>> >>> declare
>> >>> the Option enum as "extern" and add somewhere in your code :
>> >>> __js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
>> >>> This will make sure that Option.auto == "auto"
>> >>
>> >>
>> >> Maybe using builtins ?
>> >>
>> >> Ben
>> >>
>> >>
>> >> --
>> >>
>> >> haXe - an open source web programming language
>> >> http://haxe.org
>> >>
>> >
>> >
>> > --
>> > haXe - an open source web programming language
>> > http://haxe.org
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/e9ca6c9a/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sat, 24 Sep 2011 22:28:50 +0200
>> From: Nicolas Cannasse <[hidden email]>
>> Subject: Re: [haXe] Re: constraints for type parameters - usage of
>>        anonymous       types and in functions
>> To: The haXe compiler list <[hidden email]>
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Le 24/09/2011 01:29, Roger a écrit :
>> >
>> > Nicolas Cannasse wrote:
>> >>
>> >>> The first is the important one, so let's sumarize it:
>> >>> Allow *anonymous types* as type parameter constraints, because:
>> >>> 1. they are more elegant and flexible
>> >>> 2. they allow friend relationships
>> >>
>> >> Yes, that seems possible, I'll put that on the feature list.
>> >>
>> >>
>> >
>> > When will this be included in HaXe? I also really need this feature, and
>> > it
>> > was requested almost 2 years ago.
>>
>> Forgot about it, now added here :
>> http://code.google.com/p/haxe/issues/detail?id=516
>>
>> Best,
>> Nicolas
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Sat, 24 Sep 2011 22:32:13 +0200
>> From: Nicolas Cannasse <[hidden email]>
>> Subject: Re: [haXe] Re: Haxe JS ignores getters/setters when using
>>        Reflect.setField
>> To: The haXe compiler list <[hidden email]>
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Le 23/09/2011 16:52, Elsass Philippe a écrit :
>> > Hello,
>> >
>> > I've been mucking around haxe JS generator and I'm fixing a few things:
>> > - compatibility with google closure "simple" compiler (done, outputs
>> > code 20% smaller) but still no luck with the "advanced" compiler,
>> > - using Function.bind() instead of $closure() for haxe closures (done,
>> > safer with code optimizers),
>> > - reflecting getters/setters, by automatically generating meta
>> > information about properties (meta generation done, now have to modify
>> > Reflect to use this info).
>> >
>> > I'm also going to modify the code generation to emit much more compact
>> > (and probably faster) prototypes declaration. This should reduce the JS
>> > weight by another 10-20%.
>>
>> Tell me when you're done so we can see how we merge that into haXe/SVN ;)
>>
>> Best,
>> Nicolas
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Haxe mailing list
>> [hidden email]
>> http://lists.motion-twin.com/mailman/listinfo/haxe
>>
>>
>> End of Haxe Digest, Vol 71, Issue 152
>> *************************************
>
>
>
> --
> Philippe
>
> --
> 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: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

jlm@justinfront.net
So if I apply this dif will it allow me to use feffects in javascript  
the same as in flash?

On 25 Sep 2011, at 15:26, clemos wrote:

> Hi,
>
> Looks great :)
> But I think the Reflect getter/setter thing should be implemented on
> all platforms.
> Otherwise getter/setter will become really tricky to use since they
> will behave really differently across platforms.
>
> Cheers,
> Clément
>
> On Sun, Sep 25, 2011 at 1:13 AM, Elsass Philippe
> <[hidden email]> wrote:
>> Here's the haxe svn-patch:
>> http://pastie.org/2581789
>> It was tested with 2 Jeash samples so I assume it generally works ;)
>> There are quite a few changes:
>> - rewrite of the prototypes generation (cleaner, smaller code),
>> - fixes for compatibility with google closure "simple" compiler (no  
>> luck
>> with "advanced"),
>> - Reflect.field/setField now recognizes getter/setters (using some  
>> new
>> generated metadatas) with very little overhead (no prototype  
>> crawling as the
>> metadatas use inheritance),
>> - Type.createEmptyInstance doesn't require the "ugly constructor  
>> hack"
>> anymore,
>> - using Function.bind() instead of the string-based $closure  
>> (future-proof).
>> One simple sample (text+graphic) was initially 360Kb. After these  
>> changes it
>> outputs at 344Kb (82Kb gzip -6), then after google closure  
>> minification it's
>> down to 279Kb (70Kb gzip -6).
>> All this comes for free: no code change, just recompile.
>> I hope this sounds good to you people :)
>> Philippe
>> PS: other targets (like neko) could benefit from a similar
>> properties-metadata generation because it's also not possible to  
>> safely
>> discover the getter/setter functions of Dynamic objects using  
>> Reflect.
>>
>> On Sat, Sep 24, 2011 at 10:32 PM, <[hidden email]-
>> twin.com>
>> wrote:
>>>
>>> Send Haxe mailing list submissions to
>>>        [hidden email]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>        http://lists.motion-twin.com/mailman/listinfo/haxe
>>> or, via email, send a message with subject or body 'help' to
>>>        [hidden email]
>>>
>>> You can reach the person managing the list at
>>>        [hidden email]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Haxe digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>   1. Re: Failed to load library: nme.ndll (Maximiliano Fern?ndez)
>>>   2. Re: enum questions (benjamin Dubois)
>>>   3. Re: enum questions (Cau? Waneck)
>>>   4. Re: enum questions (benjamin Dubois)
>>>   5. Re: Re: constraints for type parameters - usage of anonymous
>>>      types and in functions (Nicolas Cannasse)
>>>   6. Re: Re: Haxe JS ignores getters/setters when using
>>>      Reflect.setField (Nicolas Cannasse)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sat, 24 Sep 2011 14:48:58 -0300
>>> From: Maximiliano Fern?ndez <[hidden email]>
>>> Subject: Re: [haXe] Failed to load library: nme.ndll
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID:
>>>
>>>  <CADcZx6gYquJDBFt2c_MKUAnPu=MPS-
>>> [hidden email]>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Sorry, I had to go. I use Linux, so I cannot tell you something  
>>> useful to
>>> help you. Some time ago I compiled NME from source. Was a  
>>> stressful task,
>>> but reached to my objective. I didn't have that problem you had,  
>>> but had
>>> some others. When I compiled it I done something like:
>>>
>>> 1) Get hxcpp from SVN ( http://code.google.com/p/hxcpp )
>>> 2) Cmd: haxelib dev hxcpp $path_to_hxcpp_svn_version
>>> 3) Cmd: cd $path_to_hxcpp_svn_version/runtime
>>> 4) Cmd: haxelib run hxcpp BuildLibs.xml (Also, you can put  
>>> compilation
>>> flags
>>> like -Dandroid to compile the libs for android toolchain. I  
>>> compiled in
>>> that
>>> time the Linux ones: -Dlinux)
>>>
>>> Next...
>>> 1) Get NME from SVN ( You know where ) and sdl-static ( don't have  
>>> the URL
>>> right now ). The directory tree may look like:
>>>  sources-dir/
>>>   |->nekonme/
>>>   |->sdl-static/
>>> 2) Cmd: cd $nekonme_dir/project
>>> 3) Make sure you have all enviroment vars ok: HAXE_LIBRARY_PATH,
>>> HAXE_HOME,
>>> NEKOPATH (Perhaps I forgot some var) and the includes are also ok  
>>> (Don't
>>> have a list right now, but I remember having troubles with freetype
>>> include
>>> files and some other)
>>> 4) Cmd: haxelib run hxcpp Build.xml (You can use compilation  
>>> flags, as
>>> with
>>> hxcpp libs)
>>>
>>> And after make that:
>>> 1) Cmd: cd $nekonme_dir/install-tool
>>> 2) Cmd: haxe InstallTool.hx
>>>
>>> And that's all!! I didn't understand if you had success with the
>>> compilation. Having spaces in paths it's problematic, true. Tell  
>>> me how
>>> are
>>> you going... I'm not the right one to give you "good help", but  
>>> I'm trying
>>> to help.
>>>
>>> Good journey into haXe! ;)
>>>
>>> Max
>>> 0 1 0 | 0 0 1 | 1 1 1
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/844e88d1/attachment-0001.htm
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sat, 24 Sep 2011 22:00:08 +0200
>>> From: benjamin Dubois <[hidden email]>
>>> Subject: Re: [haXe] enum questions
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID:
>>>
>>>  
>>> <CADjd8CTvcBS2FTyCre7jSdY=[hidden email]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Is there an equivalent for the Neko target this hack
>>>
>>>> enum Option {
>>>>        auto;
>>>>        cool;
>>>>        hard;
>>>> }
>>>> This will allow you to write Option.auto which will be an Option  
>>>> (and
>>>> not a
>>>> string, so it can't be used as String in haXe code).
>>>> Then since you want it to be a String _at runtime only_, you can  
>>>> declare
>>>> the Option enum as "extern" and add somewhere in your code :
>>>> __js__('Option = { auto : "auto", cool : "cool", hard :  
>>>> "hard" };');
>>>> This will make sure that Option.auto == "auto"
>>>
>>>
>>> Maybe using builtins ?
>>>
>>> Ben
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/20a99018/attachment-0001.htm
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Sat, 24 Sep 2011 17:08:59 -0300
>>> From: Cau? Waneck <[hidden email]>
>>> Subject: Re: [haXe] enum questions
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID:
>>>
>>>  <CAPHLdhyRtxPLjA4A2G47CuEFcem3EGK+-4r
>>> +THVDeVWrGvR=[hidden email]>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> you can always use @:native metadata, as previously stated. Though  
>>> I don't
>>> know if it will work on C++ because seems cpp doesn't like classes  
>>> defined
>>> as externs
>>>
>>> 2011/9/24 benjamin Dubois <[hidden email]>
>>>
>>>> Is there an equivalent for the Neko target this hack
>>>>
>>>> enum Option {
>>>>>        auto;
>>>>>        cool;
>>>>>        hard;
>>>>> }
>>>>> This will allow you to write Option.auto which will be an Option  
>>>>> (and
>>>>> not
>>>>> a string, so it can't be used as String in haXe code).
>>>>> Then since you want it to be a String _at runtime only_, you can
>>>>> declare
>>>>> the Option enum as "extern" and add somewhere in your code :
>>>>> __js__('Option = { auto : "auto", cool : "cool", hard :  
>>>>> "hard" };');
>>>>> This will make sure that Option.auto == "auto"
>>>>
>>>>
>>>> Maybe using builtins ?
>>>>
>>>> Ben
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/eedfb0f9/attachment-0001.htm
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sat, 24 Sep 2011 22:22:43 +0200
>>> From: benjamin Dubois <[hidden email]>
>>> Subject: Re: [haXe] enum questions
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID:
>>>
>>>  <CADjd8CTZ3pc3YCOgB4w4BT2y0OhN6S9pC7LDpzE8eQB2-
>>> =[hidden email]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Sorry I'm not used to using metadata can you post an simple  
>>> example please
>>> :)
>>>
>>> On Sat, Sep 24, 2011 at 10:08 PM, Cauê Waneck <[hidden email]>  
>>> wrote:
>>>
>>>> you can always use @:native metadata, as previously stated.  
>>>> Though I
>>>> don't
>>>> know if it will work on C++ because seems cpp doesn't like classes
>>>> defined
>>>> as externs
>>>>
>>>> 2011/9/24 benjamin Dubois <[hidden email]>
>>>>
>>>>> Is there an equivalent for the Neko target this hack
>>>>>
>>>>> enum Option {
>>>>>>        auto;
>>>>>>        cool;
>>>>>>        hard;
>>>>>> }
>>>>>> This will allow you to write Option.auto which will be an  
>>>>>> Option (and
>>>>>> not
>>>>>> a string, so it can't be used as String in haXe code).
>>>>>> Then since you want it to be a String _at runtime only_, you can
>>>>>> declare
>>>>>> the Option enum as "extern" and add somewhere in your code :
>>>>>> __js__('Option = { auto : "auto", cool : "cool", hard :  
>>>>>> "hard" };');
>>>>>> This will make sure that Option.auto == "auto"
>>>>>
>>>>>
>>>>> Maybe using builtins ?
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>>
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/e9ca6c9a/attachment-0001.htm
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Sat, 24 Sep 2011 22:28:50 +0200
>>> From: Nicolas Cannasse <[hidden email]>
>>> Subject: Re: [haXe] Re: constraints for type parameters - usage of
>>>        anonymous       types and in functions
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID: <[hidden email]>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> Le 24/09/2011 01:29, Roger a écrit :
>>>>
>>>> Nicolas Cannasse wrote:
>>>>>
>>>>>> The first is the important one, so let's sumarize it:
>>>>>> Allow *anonymous types* as type parameter constraints, because:
>>>>>> 1. they are more elegant and flexible
>>>>>> 2. they allow friend relationships
>>>>>
>>>>> Yes, that seems possible, I'll put that on the feature list.
>>>>>
>>>>>
>>>>
>>>> When will this be included in HaXe? I also really need this  
>>>> feature, and
>>>> it
>>>> was requested almost 2 years ago.
>>>
>>> Forgot about it, now added here :
>>> http://code.google.com/p/haxe/issues/detail?id=516
>>>
>>> Best,
>>> Nicolas
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 6
>>> Date: Sat, 24 Sep 2011 22:32:13 +0200
>>> From: Nicolas Cannasse <[hidden email]>
>>> Subject: Re: [haXe] Re: Haxe JS ignores getters/setters when using
>>>        Reflect.setField
>>> To: The haXe compiler list <[hidden email]>
>>> Message-ID: <[hidden email]>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>> Le 23/09/2011 16:52, Elsass Philippe a écrit :
>>>> Hello,
>>>>
>>>> I've been mucking around haxe JS generator and I'm fixing a few  
>>>> things:
>>>> - compatibility with google closure "simple" compiler (done,  
>>>> outputs
>>>> code 20% smaller) but still no luck with the "advanced" compiler,
>>>> - using Function.bind() instead of $closure() for haxe closures  
>>>> (done,
>>>> safer with code optimizers),
>>>> - reflecting getters/setters, by automatically generating meta
>>>> information about properties (meta generation done, now have to  
>>>> modify
>>>> Reflect to use this info).
>>>>
>>>> I'm also going to modify the code generation to emit much more  
>>>> compact
>>>> (and probably faster) prototypes declaration. This should reduce  
>>>> the JS
>>>> weight by another 10-20%.
>>>
>>> Tell me when you're done so we can see how we merge that into haXe/
>>> SVN ;)
>>>
>>> Best,
>>> Nicolas
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Haxe mailing list
>>> [hidden email]
>>> http://lists.motion-twin.com/mailman/listinfo/haxe
>>>
>>>
>>> End of Haxe Digest, Vol 71, Issue 152
>>> *************************************
>>
>>
>>
>> --
>> Philippe
>>
>> --
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Franco Ponticelli
I've tried to apply the patch ... it compiles fine and the output size is really reduced, the problem for me is that the code I wrote doesn't work anymore. IT is not easy for me to say what is going on because the current project I am working on is pretty big and the error generated was a little cryptic. As soon as I can I will try a smaller example and see if I can catch the error.

Franco

On Sun, Sep 25, 2011 at 3:37 PM, [hidden email] <[hidden email]> wrote:
So if I apply this dif will it allow me to use feffects in javascript the same as in flash?


On 25 Sep 2011, at 15:26, clemos wrote:

Hi,

Looks great :)
But I think the Reflect getter/setter thing should be implemented on
all platforms.
Otherwise getter/setter will become really tricky to use since they
will behave really differently across platforms.

Cheers,
Clément

On Sun, Sep 25, 2011 at 1:13 AM, Elsass Philippe
<[hidden email]> wrote:
Here's the haxe svn-patch:
http://pastie.org/2581789
It was tested with 2 Jeash samples so I assume it generally works ;)
There are quite a few changes:
- rewrite of the prototypes generation (cleaner, smaller code),
- fixes for compatibility with google closure "simple" compiler (no luck
with "advanced"),
- Reflect.field/setField now recognizes getter/setters (using some new
generated metadatas) with very little overhead (no prototype crawling as the
metadatas use inheritance),
- Type.createEmptyInstance doesn't require the "ugly constructor hack"
anymore,
- using Function.bind() instead of the string-based $closure (future-proof).
One simple sample (text+graphic) was initially 360Kb. After these changes it
outputs at 344Kb (82Kb gzip -6), then after google closure minification it's
down to 279Kb (70Kb gzip -6).
All this comes for free: no code change, just recompile.
I hope this sounds good to you people :)
Philippe
PS: other targets (like neko) could benefit from a similar
properties-metadata generation because it's also not possible to safely
discover the getter/setter functions of Dynamic objects using Reflect.

On Sat, Sep 24, 2011 at 10:32 PM, <[hidden email]>
wrote:

Send Haxe mailing list submissions to
      [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
      http://lists.motion-twin.com/mailman/listinfo/haxe
or, via email, send a message with subject or body 'help' to
      [hidden email]

You can reach the person managing the list at
      [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haxe digest..."


Today's Topics:

 1. Re: Failed to load library: nme.ndll (Maximiliano Fern?ndez)
 2. Re: enum questions (benjamin Dubois)
 3. Re: enum questions (Cau? Waneck)
 4. Re: enum questions (benjamin Dubois)
 5. Re: Re: constraints for type parameters - usage of anonymous
    types and in functions (Nicolas Cannasse)
 6. Re: Re: Haxe JS ignores getters/setters when using
    Reflect.setField (Nicolas Cannasse)


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

Message: 1
Date: Sat, 24 Sep 2011 14:48:58 -0300
From: Maximiliano Fern?ndez <[hidden email]>
Subject: Re: [haXe] Failed to load library: nme.ndll
To: The haXe compiler list <[hidden email]>
Message-ID:

 <CADcZx6gYquJDBFt2c_MKUAnPu=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Sorry, I had to go. I use Linux, so I cannot tell you something useful to
help you. Some time ago I compiled NME from source. Was a stressful task,
but reached to my objective. I didn't have that problem you had, but had
some others. When I compiled it I done something like:

1) Get hxcpp from SVN ( http://code.google.com/p/hxcpp )
2) Cmd: haxelib dev hxcpp $path_to_hxcpp_svn_version
3) Cmd: cd $path_to_hxcpp_svn_version/runtime
4) Cmd: haxelib run hxcpp BuildLibs.xml (Also, you can put compilation
flags
like -Dandroid to compile the libs for android toolchain. I compiled in
that
time the Linux ones: -Dlinux)

Next...
1) Get NME from SVN ( You know where ) and sdl-static ( don't have the URL
right now ). The directory tree may look like:
 sources-dir/
 |->nekonme/
 |->sdl-static/
2) Cmd: cd $nekonme_dir/project
3) Make sure you have all enviroment vars ok: HAXE_LIBRARY_PATH,
HAXE_HOME,
NEKOPATH (Perhaps I forgot some var) and the includes are also ok (Don't
have a list right now, but I remember having troubles with freetype
include
files and some other)
4) Cmd: haxelib run hxcpp Build.xml (You can use compilation flags, as
with
hxcpp libs)

And after make that:
1) Cmd: cd $nekonme_dir/install-tool
2) Cmd: haxe InstallTool.hx

And that's all!! I didn't understand if you had success with the
compilation. Having spaces in paths it's problematic, true. Tell me how
are
you going... I'm not the right one to give you "good help", but I'm trying
to help.

Good journey into haXe! ;)

Max
0 1 0 | 0 0 1 | 1 1 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/844e88d1/attachment-0001.htm

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

Message: 2
Date: Sat, 24 Sep 2011 22:00:08 +0200
From: benjamin Dubois <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:

 <CADjd8CTvcBS2FTyCre7jSdY=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Is there an equivalent for the Neko target this hack

enum Option {
      auto;
      cool;
      hard;
}
This will allow you to write Option.auto which will be an Option (and
not a
string, so it can't be used as String in haXe code).
Then since you want it to be a String _at runtime only_, you can declare
the Option enum as "extern" and add somewhere in your code :
__js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
This will make sure that Option.auto == "auto"


Maybe using builtins ?

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/20a99018/attachment-0001.htm

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

Message: 3
Date: Sat, 24 Sep 2011 17:08:59 -0300
From: Cau? Waneck <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:

 <CAPHLdhyRtxPLjA4A2G47CuEFcem3EGK+-4r+THVDeVWrGvR=[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

you can always use @:native metadata, as previously stated. Though I don't
know if it will work on C++ because seems cpp doesn't like classes defined
as externs

2011/9/24 benjamin Dubois <[hidden email]>

Is there an equivalent for the Neko target this hack

enum Option {
      auto;
      cool;
      hard;
}
This will allow you to write Option.auto which will be an Option (and
not
a string, so it can't be used as String in haXe code).
Then since you want it to be a String _at runtime only_, you can
declare
the Option enum as "extern" and add somewhere in your code :
__js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
This will make sure that Option.auto == "auto"


Maybe using builtins ?

Ben


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/eedfb0f9/attachment-0001.htm

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

Message: 4
Date: Sat, 24 Sep 2011 22:22:43 +0200
From: benjamin Dubois <[hidden email]>
Subject: Re: [haXe] enum questions
To: The haXe compiler list <[hidden email]>
Message-ID:

 <CADjd8CTZ3pc3YCOgB4w4BT2y0OhN6S9pC7LDpzE8eQB2-=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Sorry I'm not used to using metadata can you post an simple example please
:)

On Sat, Sep 24, 2011 at 10:08 PM, Cauê Waneck <[hidden email]> wrote:

you can always use @:native metadata, as previously stated. Though I
don't
know if it will work on C++ because seems cpp doesn't like classes
defined
as externs

2011/9/24 benjamin Dubois <[hidden email]>

Is there an equivalent for the Neko target this hack

enum Option {
      auto;
      cool;
      hard;
}
This will allow you to write Option.auto which will be an Option (and
not
a string, so it can't be used as String in haXe code).
Then since you want it to be a String _at runtime only_, you can
declare
the Option enum as "extern" and add somewhere in your code :
__js__('Option = { auto : "auto", cool : "cool", hard : "hard" };');
This will make sure that Option.auto == "auto"


Maybe using builtins ?

Ben


--

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



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20110924/e9ca6c9a/attachment-0001.htm

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

Message: 5
Date: Sat, 24 Sep 2011 22:28:50 +0200
From: Nicolas Cannasse <[hidden email]>
Subject: Re: [haXe] Re: constraints for type parameters - usage of
      anonymous       types and in functions
To: The haXe compiler list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 24/09/2011 01:29, Roger a écrit :

Nicolas Cannasse wrote:

The first is the important one, so let's sumarize it:
Allow *anonymous types* as type parameter constraints, because:
1. they are more elegant and flexible
2. they allow friend relationships

Yes, that seems possible, I'll put that on the feature list.



When will this be included in HaXe? I also really need this feature, and
it
was requested almost 2 years ago.

Forgot about it, now added here :
http://code.google.com/p/haxe/issues/detail?id=516

Best,
Nicolas



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

Message: 6
Date: Sat, 24 Sep 2011 22:32:13 +0200
From: Nicolas Cannasse <[hidden email]>
Subject: Re: [haXe] Re: Haxe JS ignores getters/setters when using
      Reflect.setField
To: The haXe compiler list <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Le 23/09/2011 16:52, Elsass Philippe a écrit :
Hello,

I've been mucking around haxe JS generator and I'm fixing a few things:
- compatibility with google closure "simple" compiler (done, outputs
code 20% smaller) but still no luck with the "advanced" compiler,
- using Function.bind() instead of $closure() for haxe closures (done,
safer with code optimizers),
- reflecting getters/setters, by automatically generating meta
information about properties (meta generation done, now have to modify
Reflect to use this info).

I'm also going to modify the code generation to emit much more compact
(and probably faster) prototypes declaration. This should reduce the JS
weight by another 10-20%.

Tell me when you're done so we can see how we merge that into haXe/SVN ;)

Best,
Nicolas



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

_______________________________________________
Haxe mailing list
[hidden email]
http://lists.motion-twin.com/mailman/listinfo/haxe


End of Haxe Digest, Vol 71, Issue 152
*************************************



--
Philippe

--
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


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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Franco Ponticelli
Also I am not a big fan of assuming that getters should be in the get_x form ... I for example use getX.

Franco

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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Franco Ponticelli
I think this last comment doesn't apply :)

On Tue, Sep 27, 2011 at 9:46 AM, Franco Ponticelli <[hidden email]> wrote:
Also I am not a big fan of assuming that getters should be in the get_x form ... I for example use getX.

Franco


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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Elsass Philippe
In reply to this post by Elsass Philippe
@Franco I'd be happy to try debugging it too if you can share a test url.

Are you using Reflect a lot for instance?

Also of course the __properties__ are just meta information for Reflect with an easy to lookup naming convention.

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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Franco Ponticelli
Unfortunately is a closed source project :(
I'd really love to see the advanced compiler option of closure and this effort seems to be oriented that way so I am really motivated to help you out with this. That said I'll try my best to do some more examples to exploit the issue. I'am heavily relying on "thx" so maybe the offending code is there.
I am using Reflect, not sure I am using it a lot.

Franco

On Tue, Sep 27, 2011 at 3:54 PM, Elsass Philippe <[hidden email]> wrote:
@Franco I'd be happy to try debugging it too if you can share a test url.

Are you using Reflect a lot for instance?

Also of course the __properties__ are just meta information for Reflect with an easy to lookup naming convention.

--
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: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

David Peek-2
Hey Guys,

Coincidentally I tried to get one of our apps compiling with closure advanced optimisations last week. There were still a few defects, so I had to park it. But happy to share the code. Basically I was post processing to update string references to properties that had been renamed, reading in the property map file generated by closure and using RegEx to search/replace from the generated output. The main culprit was the ["com", "domain", "ClassName"] static properties, but you would have to updated any calls to reflect as well, and anywhere else where property names were referenced by string (closure leaves strings alone).

I'm not sure you could ever make it completely bullet proof (there's not much you can do if someone is using the same var name frequently and referencing by string), you might need to do some compiler changes as well.

Also, FWIW: "set_" + prop and "get_" + prop are much easier to check for than "set" + prop.charAt(0).toUpperCase() + prop.substr(1, prop.length - 1) :P

Best,
David

On 28/09/2011, at 1:26 AM, Franco Ponticelli wrote:

Unfortunately is a closed source project :(
I'd really love to see the advanced compiler option of closure and this effort seems to be oriented that way so I am really motivated to help you out with this. That said I'll try my best to do some more examples to exploit the issue. I'am heavily relying on "thx" so maybe the offending code is there.
I am using Reflect, not sure I am using it a lot.

Franco

On Tue, Sep 27, 2011 at 3:54 PM, Elsass Philippe <[hidden email]> wrote:
@Franco I'd be happy to try debugging it too if you can share a test url.

Are you using Reflect a lot for instance?

Also of course the __properties__ are just meta information for Reflect with an easy to lookup naming convention.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Niel Drummond-3

Is this currently still the latest version of the patch ? 

I know that Function.bind will not work, because I implemented a patch to this myself once and found that Reflect.compareMethods no longer works with the bound function, which is needed to implement event handing/dispatching in jeash. 

That said, javascript does support native getters and setters, so the only lacking target to native getters and setters in haxe is the neko target.

- Niel

On Wed, Sep 28, 2011 at 1:19 AM, David Peek <[hidden email]> wrote:
Hey Guys,

Coincidentally I tried to get one of our apps compiling with closure advanced optimisations last week. There were still a few defects, so I had to park it. But happy to share the code. Basically I was post processing to update string references to properties that had been renamed, reading in the property map file generated by closure and using RegEx to search/replace from the generated output. The main culprit was the ["com", "domain", "ClassName"] static properties, but you would have to updated any calls to reflect as well, and anywhere else where property names were referenced by string (closure leaves strings alone).

I'm not sure you could ever make it completely bullet proof (there's not much you can do if someone is using the same var name frequently and referencing by string), you might need to do some compiler changes as well.

Also, FWIW: "set_" + prop and "get_" + prop are much easier to check for than "set" + prop.charAt(0).toUpperCase() + prop.substr(1, prop.length - 1) :P

Best,
David

On 28/09/2011, at 1:26 AM, Franco Ponticelli wrote:

Unfortunately is a closed source project :(
I'd really love to see the advanced compiler option of closure and this effort seems to be oriented that way so I am really motivated to help you out with this. That said I'll try my best to do some more examples to exploit the issue. I'am heavily relying on "thx" so maybe the offending code is there.
I am using Reflect, not sure I am using it a lot.

Franco

On Tue, Sep 27, 2011 at 3:54 PM, Elsass Philippe <[hidden email]> wrote:
@Franco I'd be happy to try debugging it too if you can share a test url.

Are you using Reflect a lot for instance?

Also of course the __properties__ are just meta information for Reflect with an easy to lookup naming convention.

--
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


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

Re: JS generator improvements (was: Haxe JS ignores getters/setters when using Reflect.setField)

Elsass Philippe
I modified the patch since then, thanks to Franco's big test suite - Reflect.compareMethod & other issues have been fixed.

Latest patch is referenced here:
http://code.google.com/p/haxe/issues/detail?id=530


On Thu, Oct 6, 2011 at 11:15 PM, Niel Drummond <[hidden email]> wrote:

Is this currently still the latest version of the patch ? 

I know that Function.bind will not work, because I implemented a patch to this myself once and found that Reflect.compareMethods no longer works with the bound function, which is needed to implement event handing/dispatching in jeash. 

That said, javascript does support native getters and setters, so the only lacking target to native getters and setters in haxe is the neko target.

- Niel

On Wed, Sep 28, 2011 at 1:19 AM, David Peek <[hidden email]> wrote:
Hey Guys,

Coincidentally I tried to get one of our apps compiling with closure advanced optimisations last week. There were still a few defects, so I had to park it. But happy to share the code. Basically I was post processing to update string references to properties that had been renamed, reading in the property map file generated by closure and using RegEx to search/replace from the generated output. The main culprit was the ["com", "domain", "ClassName"] static properties, but you would have to updated any calls to reflect as well, and anywhere else where property names were referenced by string (closure leaves strings alone).

I'm not sure you could ever make it completely bullet proof (there's not much you can do if someone is using the same var name frequently and referencing by string), you might need to do some compiler changes as well.

Also, FWIW: "set_" + prop and "get_" + prop are much easier to check for than "set" + prop.charAt(0).toUpperCase() + prop.substr(1, prop.length - 1) :P

Best,
David

On 28/09/2011, at 1:26 AM, Franco Ponticelli wrote:

Unfortunately is a closed source project :(
I'd really love to see the advanced compiler option of closure and this effort seems to be oriented that way so I am really motivated to help you out with this. That said I'll try my best to do some more examples to exploit the issue. I'am heavily relying on "thx" so maybe the offending code is there.
I am using Reflect, not sure I am using it a lot.

Franco

On Tue, Sep 27, 2011 at 3:54 PM, Elsass Philippe <[hidden email]> wrote:
@Franco I'd be happy to try debugging it too if you can share a test url.

Are you using Reflect a lot for instance?

Also of course the __properties__ are just meta information for Reflect with an easy to lookup naming convention.

--
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




--
Philippe

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