Haxe 3 migration experience

[Simon Krajewski]

Hi,

how is everyone's migration experience so far with haxe 3 RC? We are
interested in making the haxe 2 to haxe 3 step as easy as possible, so
any kind of feedback is appreciated!

Simon

[John Plsek]

Spent hours

1. removing comma's in class definitions
2. adding semicolons to the end of one line functions i.e. things like "function simple(x) return x+x" (why haxe2 refused to accept them there always baffled me) - ended up actually changing it so it compiled in both 2 & 3 without #if haxe3 ; #end, i.e. "function simple(x) { return x+ x;}"
3. changing Hash<X> to Map<String,X> and associated new Hash calls to new Map - wow, I use Hash a LOT!!!
4. I also seem to use many "static inline" objects, so had to change them to static inline functions returning the object, and associated x.prop to x().prop
5. "fixed" some broken (with respect to haxe3 syntax) haxelib's
6. Int32 - grrr - all my crypto stuff I spent ages writing, broken - that took a while to fix for some reason
   

All in all it was time consuming, but relatively painless. Of the points above though, I can't see the point of removing the "," from class defn lines

Everything now runs in haxe3 and at the moment I can compile in either 2 or 3 with judicious use of #if haxe3 throughout my code.

Regards

John

Simon

--
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/groups/opt_out.

[Jason O'Neil]

My experience is really similar to John's - lots of time finding all the small syntax changes, and putting Map/StringMap in everywhere I used to use Hash, that all took a while, but was relatively straight forward.  I didn't end up using the hx2compat library, I thought it would be easier to just bite the bullet and change everything now.

I think the biggest thing was just how many libraries I depend on, and how many needed patching / updating.  And once you've fixed them, packaging them, installing them, setting up pull requests or packaging for haxelib etc.  It's been pretty time consuming.  If I could have any input on the timing of the final release I'd say if you can hold off for several more weeks for all of the haxelibs to catch up, that would be awfully kind and help people have confidence in the Haxe3 release. 

Libraries and code changes aside, the compiler itself and the standard library are pretty awesome.  Lots of new features to play with, LOVING having 'string $interpolation'.  The simplified APIs

Jason

[Dom De Lorenzo]

Hi simon,

After migrating mlib, munit, mcover, mconsole and mockatoo, I found the process mostly painless (and I was impressed with the quality of the release in general). The first three took less than an hour in total to get running. Mockatoo took the longest due to the number of subtle macro changes (which was to be expected with so many changes to the language)

I ended up with a list of about 10 simple search and replaces that resolved most things (pro tip: replace 'IntHash<' with 'Map<Int,' before replacing 'IntHash' with 'Map' and similar for Hash to save a bunch of typing issues). 

The implements/extends syntax change was easy enough to resolve, but makes code very messy when handling both haxe2 and 3 syntax through #if #else statements.

Most painful:

- locating the cause of macro issues from vague 'Defined in this class' compiler errors. Argh!!!!

- non-explicitly typed dynamic arrays '[1,"foo",true]

- library dependencies (even between our libs mentioned above was a hassle!)

- occasional type issues due to reversed order of imports (when two classes with same name have changed priority)

My biggest gripe is the inability to identify which haxelibs are haxe 3 compliant. It makes estimating/evaluating the feasibility of migrating actual projects incredibly time consuming at this stage. If only we had better recommended guidelines around library versioning, and integration of hx-semver (https://github.com/dpeek/hx-semver) to list libs based on haxe version :)

Cheers,

Dom

[Simon Krajewski]

Am 01.03.2013 12:28, schrieb Dom De Lorenzo:

Hi simon,

After migrating mlib, munit, mcover, mconsole and mockatoo, I found the process mostly painless (and I was impressed with the quality of the release in general). The first three took less than an hour in total to get running. Mockatoo took the longest due to the number of subtle macro changes (which was to be expected with so many changes to the language)

I ended up with a list of about 10 simple search and replaces that resolved most things (pro tip: replace 'IntHash<' with 'Map<Int,' before replacing 'IntHash' with 'Map' and similar for Hash to save a bunch of typing issues). 

The implements/extends syntax change was easy enough to resolve, but makes code very messy when handling both haxe2 and 3 syntax through #if #else statements.

Most painful:

- locating the cause of macro issues from vague 'Defined in this class' compiler errors. Argh!!!!

- non-explicitly typed dynamic arrays '[1,"foo",true]

- library dependencies (even between our libs mentioned above was a hassle!)

- occasional type issues due to reversed order of imports (when two classes with same name have changed priority)

My biggest gripe is the inability to identify which haxelibs are haxe 3 compliant. It makes estimating/evaluating the feasibility of migrating actual projects incredibly time consuming at this stage. If only we had better recommended guidelines around library versioning, and integration of hx-semver (https://github.com/dpeek/hx-semver) to list libs based on haxe version :)

Hi Dom,

thanks for the detailed information, this is pretty much what I expected.

I agree that haxelib needs some love, but we cannot allocate much time to it at the moment. The other day we were talking about rebooting the haxelib database due to the vast amount of unmaintained, broken libraries. It would be nice if we then could start over with proper versioning, for which hx-semver seems very nice.

I will try to check out how much work integrating it would require, but in the long run we may need a dedicated haxelib maintainer.

Simon

[杨博]

We are using Haxe 2.11 r5884 for some days. In these days, we have gotten Haxe 3 pattern matching and many Haxe 2.10 bug fixes. We have no plan to upgrade to Haxe 3 very soon. We will be happier if there is an official Haxe 2.11 release.

[Adrian Veith]

Took me about 3 days to fix and test most of our codes (and playing
around with abstract types).

Main problems where:

- dead code elimination - after some problems with our neko servers, I
switched all neko projects to -dce no
- javascript strict mode broke some clients, but the problem was some
old dirty code (we are using haxe since many years now)
- some moved modules where not found by the compiler, because they were
in untyped code - dirty code again.
- many strings with '$something' to change to "$something"

over all experience: very good, the new std library layout is much
cleaner, the new language features like abstract types are cool

thanks for the good work.
Adrian.

[Justin Donaldson]

On Fri, Mar 1, 2013 at 1:18 AM, John Plsek <jaro...@gmail.com> wrote:

1. changing Hash<X> to Map<String,X> and associated new Hash calls to new Map - wow, I use Hash a LOT!!!

You can add a quick conditional typedef for this:

#if haxe3 typedef Hash<T> = Map<String,T>; #end

(repeat for IntHash)

It lets you maintain backwards compatibility.  I haven't used hx2compat yet though, does it do something similar?

Best,

-Justin

 

--
blog: http://www.scwn.net
twitter: sudojudo

[Cauê Waneck]

you can also add

#if haxe3 

import haxe.ds.StringMap in Hash;

#end

2013/3/1 Justin Donaldson <jdona...@gmail.com>

--

[Bruno Garcia]

On 03/01/2013 04:01 AM, Simon Krajewski wrote:
> The other day we were talking about rebooting the haxelib database due
> to the vast amount of unmaintained, broken libraries.

+1, especially if Haxe 2 users can remain on the old DB.

Bruno

[whitetigle]

+1
I will use haxe 3 for my following projects but I want to stick to my
current configuration for older projects.
So will there be a 2.11 release ?

--
ThinkSlow -
cross-platform gaming experiments

( who ? why ? what ? ) -> http://thinkslow.net
( how ? when ? ) -> http://blog.thinkslow.net

[Nicolas Cannasse]

Le 01/03/2013 15:51, 杨博 a écrit :

Maintaining two separate branches is a lot of work. We have to plans to
do it atm but will do if some of the Haxe Foundation partners request
for it.

Best,
Nicolas

[Tom]

There is a "small" problem with NME (the latest from github(?)). It can compile to windows, but the exe not run, just hang on, and stop.
And assets > font not work properly for me.

Any idea?

[Joshua Granick]

Make sure you follow the directions here:

http://github.com/haxenme/NME

I've been using the development builds on Windows, and with fonts, just fine. However, if you are having problems, please let me know so we can handle any possible issues.

[Tom]

I do this steps once, befor, bit without remove nme 3.5.5.
Now I have removed it (haxelib remove nme.)
I do the steps, but step 6. 'Install the "nme" command alias: haxelib run nme setup'  just give up one line: [file_contents,C:\HaxeFoundation\haxe\lib\nme//.current]
the .current file is missing? But if I add it, with folder path to the git clone of the NME, it give more errors:
Called from ? line 1
Called from RunScript.hx line 901
Called from RunScript.hx line 709
Called from C:\Program Files (x86)\HaxeFoundation\haxe/std/neko/_std/Sys.hx line 87
Uncaught exception - std@set_cwd

If I'm not mistaken the some of the paths is hard-coded? My haxe 3, and neko 2 have installed into "c:\HaxeFoundation\". This is a problem?
Thanks for any idea!

[Francois Nicaise]

what about a svn tag?

Thinkslow
Cross- platform gaming experiments
Http://thinkslow.net
Http://blog.thinkslow.org

[Nicolas Cannasse]

Le 03/03/2013 09:46, Tom a �crit :

> I do this steps once, befor, bit without remove nme 3.5.5.
> Now I have removed it (haxelib remove nme.)
> I do the steps, but step 6. 'Install the "nme" command alias: haxelib
> run nme setup' just give up one
> line:[file_contents,C:\HaxeFoundation\haxe\lib\nme//.current]
> the .current file is missing? But if I add it, with folder path to the
> git clone of the NME, it give more errors:
> Called from ? line 1
> Called from RunScript.hx line 901
> Called from RunScript.hx line 709
> Called from C:\Program Files
> (x86)\HaxeFoundation\haxe/std/neko/_std/Sys.hx line 87
> Uncaught exception - std@set_cwd
>
> If I'm not mistaken the some of the paths is hard-coded? My haxe 3, and
> neko 2 have installed into "c:\HaxeFoundation\". This is a problem?
> Thanks for any idea!

Seems like you don't have the access rights to the haxe\lib or
haxe\lib\nme directory, which prevents either writing .current file or
even switching the directory to it.

Best,
Nicolas

[Tom]

 
Strange. UAC has switched off years ago. The ".dev" file was created in haxe\lib\nme directory correctly in step 2.

Edit_1: In the nme directroy only the .current file wasn't there. And when I put it there, the it's content was incorrect: a directory path, and not the "dev" word.
Now the project is compiling, well.
But the assets fonts is not working for me (in flash: ReferenceError: Error #1065: Variable NME_fonts_jesterregular_ttf is not defined. ), and the windows exe is just hanging, not running.

Edit_2: After an nme rebuild tools,clean,windows  the font assets does not throw any error in flash. The windows exe still hanging (freeze). :-/

[Hugh]

Hi

For me, the biggest mess was the comma in the class inheritance.

The main problem was trying to be a good citizen with the (NME) library and support both haxe2 and haxe3 with the same code base.  It would have been easier if I had just said "right, everything over to haxe3", but I quite like having an intermediate version that supports both for several months.  So, when someone does "NME update" it does not matter if they have moved over to haxe3 or not.  For me, it would have been easier if haxe had adopted this philosophy too, ie optional comma for haxe3 and then remove it for haxe 3.1, then we can do a new release a few months after haxe3 that has the new syntax and it would have worked on haxe3 and been ready for haxe3.1.  I guess same for Hash and ';' on single-line functions - allowing a grace period of 1 version.

Hugh

[Tom]

 
The hanging of the EXE occurs on Windows 7 64 bit, but on XP it run, and working.

[Dom De Lorenzo]

Hi Simon,

One other issue i ran into while trying to maintain both haxe3 and haxe 2.10 compatibility.

Both mlib and munit contain run.n files.  If these neko files are compiled under Haxe 3 and/or Neko 2 they trigger RTE in haxelib when running in haxe 2.10 (with either neko 1.8 or 2.0) - which is fair enough as they are newer.

When compiled in haxe 2.10 with neko 1.8 they seem to run ok on Haxe3/Neko 2 as well which is great.

If a developer accidentally compiles and release a lib while using haxe 3 it wont work in Haxe 2.10 even if the code base is compatible.

Likewise, if we want to start utilizing haxe 3 (or neko 2) APIs in the run.n file, we will be forced to drop haxe 2.10 support for the runner, as there is no way of specifying different run files for each version.

I'm not sure what the solution is, but it will make for a bunch of fragile libraries during the transition process between versions.

Dom

This means that the release builds for these libraries

Unless these were compiled in Haxe 2.10 with Neko 1.x, they would not work 

While updating several haxelibs to support both Haxe 3 and Haxe 2.10, there were issues with haxelib executing the lib run.n files if they weren't compiled in neko 1 and haxe 2.10.

[Thuyen Nguyen]

I know this is a very old thread, but I just recently started to migrate some old Haxe 2 code to Haxe 3, and encountered a problem with my switch statement, similar to this snippet below:

static var nameList : Array<String> = ["Joe", "John", "Jane"];

static function Test(name:String)
{
  switch (name)
  {
    case nameList[0]:  // do something

    case nameList[1]:  // do something

    default:
  }

}

The code compiled fine for Haxe 2, but in Haxe 3, it complained not able to parse "nameList[0]". I don't have the actual error message on hand, but can get it later. I just want to know if anyone had seen something like this before, and how would you resolve it.

Adding "-D no-pattern-matching" to the compile script had no observable effect.

TIA.

[Alexander Kuzmenko]

In Haxe 3 you can check only against patterns or constant values.

Try something like this:

switch (name)
  {
    case n if(n == nameList[0]):  // do something

    case n if(n == nameList[1]):  // do something

    default:
  }

вторник, 20 сентября 2016 г., 21:40:07 UTC+3 пользователь Thuyen Nguyen написал:

[Thuyen Nguyen]

Thank you Alaxander.

That's a bit convoluted. I wish they'd stick to the KISS principle.

The "if then else" statement looks like a better alternative, unfortunately :(.