Haxe 4.0.0-rc.4 is released

Announcements
1

Dear Community,

On behalf of the Haxe Foundation, we are proud to announce the official release of the Haxe 4.0.0-rc.4! It is available along with the changelog at Haxe 4.0.0-rc.4 - Haxe - The Cross-platform Toolkit.

Our focus was on small bugfixes and internal stability. In particular, we made an effort to improve the integrity and memory usage of the compilation server. There were also a lot of changes to make IDE support even better.

There are still some issues to sort out before we declare Haxe to be ready for 4.0. We are getting closer, though! Your help in testing this release is, as always, greatly appreciated.

See the changelog. Please report any issues here: https://github.com/HaxeFoundation/haxe/issues

Thank you very much for your help!

18 Likes
5

Thanks for your hard work! :+1:

1 Like
6

It seems Haxe4 kills Unifill. The workaround for unicode support.

/HaxeToolkit/haxe/lib/unifill/0,4,1/unifill/Unifill.hx:21: characters 41-50 : Warning : haxe.Utf8 is deprecated. Use UnicodeString instead.

Please ensure you do not kill established workarounds/haxelibs with updates.

(slight background info: I need to publish an app asap. I had to update from openfl legacy because it does not support the new android 64bit requirements. However some recent lime/openfl releases contain a random opengl crash bug on android. This seems fixed in the latest versions but it requires Haxe4rc4. And that in turn kills the AlivePDF and Unifill libs. The past month I’ve been migrating/rewriting code and it is all a highly frustrating process, especially because of looming deadlines. No-ones fault in particular. But it really needs a much more solid foundation. I’m spending way too much time dealing with issues than creating the actual things I want to create. Also there does not seem to be an upgrade guide document or something… /rant)

1 Like
7

This is not a compilation error but just a warning which doesn’t prevent using haxe.Utf8.

Also compiler team cannot force library maintainers neither to keep backward compatibility nor to not drop support for the latest stable Haxe version when the next one is not yet released :slight_smile:

I agree with you on an upgrade guide, but as I said Haxe 4 is not released yet. In the meantime we’re collecting breaking changes here: Breaking changes in Haxe 4.0.0 · HaxeFoundation/haxe Wiki · GitHub it’s not always up to date with the bleeding edge of Haxe language development because our manpower is pretty limited.

2 Likes
8

I know it’s just a warning, but I used to see all Unicode characters in my app, and now I’m seeing a lot of broken characters. So despite it just being a bunch of warnings, unicode support with unifill no longer works. In haxe 3.4.7 it does.

I would indeed rather not upgrade to haxe4, but openfl and lime bugs & fixes are forcing me to.

I’m not really expecting you to verify everything, but perhaps it’s a good idea to introduce a mandatory test case/test code with each haxelib or something. So you could set up automated test cases and get an overview of everything that breaks.

Currently it feels very similar with the linux os for me. It can work great, but only under the right precarious circumstances, when all the planets are aligned etc…

9

Have you tried using <haxedef name="disable_unicode_strings" />?

10

Thanks for the tip. Unfortunately that causes a number of errors in HXCPP:
/HaxeToolkit/haxe/lib/hxcpp/4,0,52/src/hx/libs/regexp/RegExp.cpp:56: error: undefined reference to ‘pcre16_fullinfo’

#ifdef HX_SMART_STRINGS
   void create16(pcre16 *inR, String inExpr, int inFlags)
   {
      rUtf8 = 0;
      rUtf16 = inR;
      expr = inExpr;
      HX_OBJ_WB_GET(this, expr.raw_ref());
      flags = inFlags;

      nmatchs = 0;
      pcre16_fullinfo(rUtf16,NULL,PCRE_INFO_CAPTURECOUNT,&nmatchs);

And a couple more similar to it…

11

as far as I understand HX_SMART_STRINGS is not set by default when using -D disable_unicode_strings… are you explicitly setting HX_SMART_STRINGS?

12

Not that I know of, but another lib might. Might be haxeui, I’m on the dev branch there (out of necessity again).

Here’s my project xml:

<?xml version="1.0" encoding="utf-8"?>
<project>
    <meta XXX />
    <app YYY path="build/openfl" />

    <window background="#FFFFFF" fps="60" />
    <window width="800" height="600" if="desktop" />
    <window width="0" height="0" if="html5" />
	
	<!--android-->
	<architecture name="arm64" if="android" />
	<config:android minimum-sdk-version="19" target-sdk-version="28" />
	
	<android permission="android.permission.WRITE_EXTERNAL_STORAGE"/>
	<android permission="android.permission.READ_EXTERNAL_STORAGE"/>
	<android permission="android.permission.BLUETOOTH"/>
        <android permission="android.permission.BLUETOOTH_ADMIN"/>
	<android permission="android.permission.ACCESS_COARSE_LOCATION"/>
        <android permission="android.permission.ACCESS_FINE_LOCATION"/>
	<android permission="android.permission.INTERNET"/>
	<android keepScreenOn="true"/>
	<android feature="android.hardware.bluetooth_le" required="true"/>
	<certificate ZZZ if="android" unless="debug" />
	
	<haxedef name="disable_unicode_strings" />

    <!-- classpath, haxe libs -->
    <source path="src" />

    <!--<haxelib name="openfl-alivepdf"/>-->
    <haxelib name="datetime"/>
    <haxelib name="openfl" />
    <haxelib name="actuate" />
    <haxelib name="haxeui-core" />
    <haxelib name="haxeui-openfl" />
    <haxelib name="unifill"/>
	
	<assets path="assets" rename="assets" />
	<assets path="assets/img" rename="img" embed="true"/>
</project>

Haxelib list:
actuate: 1.8.7 [1.8.9]
box2d: [1.2.3]
datetime: [3.1.1]
format: 3.4.1 [3.4.2]
haxeui-core: 0.0.4 Copygitchanges [git]
haxeui-file-dialogs: [0.1.1]
haxeui-openfl: 0.0.2 [git]
haxeui: [1.8.21]
hscript: 2.1.1 [2.3.0]
hxcpp: 3.4.188 4.0.4 4.0.8 4.0.19 [4.0.52]
hxp: 1.1.2 [1.1.3]
layout: [1.2.1]
lime-samples: 6.2.0 [7.0.0]
lime: 2.9.0 2.9.1 6.2.0 7.5.0 7.6.0 [7.6.2]
openfl-alivepdf: [dev:\trunk\pdf\openfl-alivepdf-master]
openfl-samples: 6.0.0 [8.7.0]
openfl: 3.6.1 7.1.2 8.9.0 8.9.1 8.9.2 [8.9.4]
unifill: [0.4.1]

But it’s just moving the issue. That’s why I’d like some kind of automated testing. Or perhaps making a clear divide in haxelibs, subdivide them based on haxe versions or something, dunno…

13

It’s always interesting to me to see the pull between the two conflicting desires to:

  • keep development nimble, with a relatively quick deprecation cycle, vs.
  • keep backward compatibility

and to see where different projects land on that continuum.

I do not envy project leadership on this. Leave a flaw alone and folks will keep asking for it to be fixed (well, and, if left alone, you’ve still got the flaw). Fix the flaw and other folks will be unhappy with the resulting code breakage.

(+1 on deprecation warnings and upgrade guides!)

Thank you to the core team for navigating these waters in the pursuit of making Haxe better every release! :smiley:

14

I wanted to point out that it seems to have been unintentional for lime/openfl to force people to haxe 4. The issue is being worked on.

So the choice just went from:
The current latest stable haxe+lime+openfl will not build therefore you must upgrade and lose functionality.
To:
The current latest stable haxe+lime+openfl has some bugs but you can choose to upgrade and trade them for some loss of functionality/other bugs.

I think the latter is acceptable because the former isn’t much of a choice.

15

There is also an option to find what’s incompatible with Haxe 3.4 in the latest openfl and make a pull request :slight_smile:

1 Like