Haxe 3.2.0-rc2 has been released!

[Simon Krajewski]

Dear community,

On behalf of the Haxe Foundation I am proud to announce that Haxe
3.2.0-rc2 is now officially released! It is available along with the
changelog at http://haxe.org/download/version/3.2.0-rc.2

This release introduces the new Python target which was developed by
Heinz Hölzer and Dan Korostelev. As with any new target it should be
considered to be in beta stage.

Another new feature is the static analyzer which can be activated by
compiling with -D analyzer. It applies various optimizations such as
constant propagation and expression-level DCE which improves the quality
of the generated code on targets such as Javascript. We plan to make
this a default setting in the future once the implementation has stabilized.

There are quite a few other new features, improvements and bugfixes, so
make sure to check out the changelog. We addressed many issues that are
present in Haxe 3.1.3!

Haxe 3.2.0 is going to have a few breaking changes. While we try to
avoid these in general, there are situations where that's not feasible.
We have prepared an overview of the breaking changes at
https://github.com/HaxeFoundation/haxe/wiki/Breaking-changes-in-Haxe-3.2.0.

Please test your Haxe code with this version and let us know if you come
across any problems at https://github.com/HaxeFoundation/haxe/issues. We
plan to have the next release very soon, so make sure to get your issue
reports in!

Thank you for your support
Simon Krajewski

[Heinz Hölzer]

Awesome, thx for your hard work!

[David Elahee]

Congratulation !

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

David Elahee

[Aleksandr "FIZZER" Kozlovskij]

Great! Thx!

пятница, 20 марта 2015 г., 10:56:09 UTC+3 пользователь Simon Krajewski написал:

[clemos]

Great :)

try-haxe has been updated accordingly, btw.

Best,

Clément

--

[Pierre Chamberlain]

Will the "-D analyzer" compiler argument be documented somewhere, so we see some examples of the optimizations it brings to Javascript?

-Pierre

[Tarwin Stroh-Spijer]

Thanks guys.

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

--

[Simon Krajewski]

Am 20.03.2015 um 20:07 schrieb Pierre Chamberlain:
> Will the "-D analyzer" compiler argument be documented somewhere, so
> we see some examples of the optimizations it brings to Javascript?

I'll document this once it's relatively stable. Here's a quick example
of constant propagation: https://gist.github.com/Simn/4a87a9469c407e221795

Our JS unit test file loses 20kb with the analyzer despite the fact that
there's a lot more inlining going on. The amount of $this closures goes
down from 773 to 4 (of which 2 are static inits where it's
hard/pointless to avoid).

I have uploaded the current diff here if you want to check some
examples: https://www.diffchecker.com/dlg4r8vi
Note that it's backwards, i.e. the analyzer version is on the left side.
You will find that it's not perfect yet in some places and creates too
many temporary variables, but we'll improve on that a bit later.

Simon

[Skyler Parr]

I'm getting strange feedback from the java target

$ haxe -java java -main Main

haxelib run hxjava hxjava_build.txt --haxe-version 3200 --feature-level 1

javac "-sourcepath" "src" "-d" "obj" "-g:none" "@cmd"

Is this just temporary?

[Haxiomic]

Excited to see 3.2 is nearly ready for release :D

Curiously I found building with -D analyzer results in a js file about 33% larger - I haven't tested perf but is this the expected behavior? What have other people found? (the build I'm testing)

[Simon Krajewski]

Am 22.03.2015 um 01:46 schrieb Haxiomic:

Excited to see 3.2 is nearly ready for release :D

Curiously I found building with -D analyzer results in a js file about 33% larger - I haven't tested perf but is this the expected behavior? What have other people found? (the build I'm testing)

That can happen with inlining because the compiler now doesn't cancel inlining as much as it used to. There are also some cases where we create too many temp variables which I have yet to look into. If you post a diff to https://www.diffchecker.com/ or somewhere else I can take a look.

Simon

[Haxiomic]

Ahh, yeah, you're spot on - https://www.diffchecker.com/cc4retqw the -D analyzer version is smaller up until about line 3500 where there's a long series of StringMap set()'s and it's the new inlining that's pushing the analyzer version over by about 300 lines

[Simon Krajewski]

Am 22.03.2015 um 14:16 schrieb Haxiomic:
> Ahh, yeah, you're spot on - https://www.diffchecker.com/cc4retqw the
> -D analyzer version is smaller up until about line 3500 where there's
> a long series of StringMap set()'s and it's the new inlining that's
> pushing the analyzer version over by about 300 lines

Yes, that's the typical example. Without the analyzer inlining is
cancelled because both key and value appear multiple times in the
function body, making it necessary to introduce a temp var in the
general case. This leads to ugly code on JS, at least in value places.
The analyzer now transforms this nicely and even inlines the value for
`key` because it's a string literal.

Simon

[Dion Whitehead Amago]

Congrats, that is amazing work. The number of platforms and language outputs is now objectively amazing.

[Simon Krajewski]

So, uhm, is anybody actually testing this RC? It's been four days and so far I had to fix one issue which wasn't even reported to our own repository. I would love to believe that everything just works, but I don't feel naive enough for that yet!

Simon

[Juraj Kirchheim]

My guess is that you can consider the python backend virtually untested, but I wouldn't know what to do about that.

--

[Simon Krajewski]

Am 24.03.2015 um 08:14 schrieb Juraj Kirchheim:
> My guess is that you can consider the python backend virtually
> untested, but I wouldn't know what to do about that.

The python target is not so important because it's something new anyway.
I'm more worried about general regressions.

Simon

[Joshua Granick]

I'm consistently testing against the latest RC

[Dan Korostelev]

вторник, 24 марта 2015 г., 10:08:07 UTC+3 пользователь Simon Krajewski написал:

So, uhm, is anybody actually testing this RC? It's been four days and so far I had to fix one issue which wasn't even reported to our own repository. I would love to believe that everything just works, but I don't feel naive enough for that yet!

I'm using a version from git somewhere near the RC in production for JS and C# targets. I reported some minor issues, but other than that is seems to work nicely so far.

[Sven Bergström]

We've been testing the RC extensively (across windows/mac/linux/ios/android with cpp and web with js). 
I've also been testing using half 3.1.3 and half 3.2 across my builds, as to catch any differences for backward compatibility that aren't known.
So far no new problems. Only issues so far were minor changes to deal with newer api (Xml for example) which are noted.

I've tested some c# and python target, mostly existing code that I had been using along git versions, so nothing really to report there.

It's unlikely you'll catch the kind of point-release-update-requiring bugs wanted in just days, 

but what you will (and did) catch are the kind of breaking bugs that ensure the release is not usable

for the majority. This is no longer the case with 3.2.0-rc2 \o/

RC.2 is usable, and pretty solid so far, going by reading the forums and issue threads and feedback from users.
Except for the known issues on the list - It looks like a good candidate for release (heh).

[Jason O'Neil]

I'm going through my projects now.

Honestly most of the issues I'm getting are compile time errors that pick up behaviour that was previously broken but compiled, and now does not compile.  (Which is great!  But does require some library updates). 

With these issues of code no longer compiling, but it's actually a bug fix:

• report them
  
• add them to the breaking changes list, or
  
• add a generic item: "The compiler is now smarter, and won't let you do as many stupid things as before.  Some code will no longer compile, because it was always broken, but now the compiler will tell you.  Try to understand error messages you may not have encountered before - it may be a bug in your code"?

One example was this issue I filed a while back: https://github.com/HaxeFoundation/haxe/issues/3772

Another example is this code, which used to compile in a macro or --run, but did not work correctly.  Now it gives a compile error:

class ContinueOutsideLoop {
    static function main() {
        for (i in [1,2]) {
            Lambda.map(["a"], function(s) {
                trace( i ); // Previous traced both 1 and 2, so the continue statement did not work.
                continue; // In Haxe 3.2, it now gives the error "Continue outside a loop"
            });
        }
    }
}

(For the record, that example was from the old selecthxml library you wrote and I still sort of use: https://github.com/jasononeil/selecthxml/blob/master/src/selecthxml/engine/TypeResolver.hx#L276)

--

[Jason O'Neil]

Another example, with the mockatoo library,

    var obj = MyClass.mock();

    obj.somePropertyWithPrivateGetter.returns( 3 );

used to work.  Now it gives the error `Cannot access private field get_somePropertyWithPrivateGetter`.

You can work around it with @:privateAccess.  Again it's hard to tell if this is a regression or a bug fix without investigating mockatoo more thoroughly.

[Juraj Kirchheim]

That's a side effect of this being fixed: https://github.com/HaxeFoundation/haxe/issues/3714

[Daniel Uranga]

Ohhh that explains this https://github.com/jdonaldson/promhx/issues/51

[Jason O'Neil]

I thought it would be something like that.

Given that it is affecting a few different libraries it would be nice to mention it in the list of breaking changes, if we can describe the change succinctly enough.

Would something like this be sufficient:

Expressions generated in macros no longer have access to private fields by default (see [Issue 3714](https://github.com/HaxeFoundation/haxe/issues/3714)).  A workaround is to add `@:privateAccess` metadata to your generated expressions.

We could also mention the bit about round-trips through the typer and static extensions, but that may be overcomplicating it.

Thoughts?

[Jason O'Neil]

Oh, I see the change has been reverted.  Nevermind!