Haxe in unix world

[delahee]

Something that was inferred at FOSDEM.

Nobody deep in the unix/linux world really knows haxe because we have a very very big issue about distributions integration. Very often unix and linux teams are separated and have separated managements so if any of us is going to a linux/unix convention , we really need to have a fairly stable and recent haxe release available when we do speeches. Otherwise we are doom to speech in the wind.

haxe on debian : https://packages.debian.org/sid/devel/haxe haxe on centos : ??? haxe on suse : ??? haxe on ubuntu : http://packages.ubuntu.com/trusty/devel/haxe (1.3 ?)

and so on... same goes for neko..

I am really kind of the opposite of unix user because I make games and all my tools are windows but if you want to really ease our job evangelizing and haxe spreading and seducing the "app" world.

We really need have to have :

• One page listing packages links for rpm, yast and alikes.
• Someone in the foundation spending time negociating and preparing the echosystem to be available on current top linux distros.

Of course one can argue that they can downalod binaries or build haxe themselves but early adopters really are looking for well packaged solutions and apt-get haxe should just work and retrieve something fresh enough.

Thanks !

[ibilon]

My two cents as a linux user:

There's no haxe or neko on the main repositories of openSuse, it seems there a 3.2 there: https://build.opensuse.org/package/show?project=games&package=haxe

A first step would be for the build server to make a rpm and deb, a second would be to make repositories for the biggest linuxs, not an expert on that but they look like a set of specific folders and a couple of metadata files so shouldn't be too hard. And an official package/repository from haxe would give us better credibility about maintaining the packages in the long term.

Doing that would change the message from "we have a product and we'd like to add it to your distribution" to "we have a {distrib.name}-ready architecture and we'd like to be added to your distribution".

Worth looking into known community repositories too, openSuse has packman (http://packman.links2linux.org/), a lot of people have this kind of repository installed and they may be easier to get approved into and a gateway into an official repository.

About neko it will require a couple of changes, having a 64bits program living in /usr/lib/ will get you a direct no because there's /usr/lib64/ for that (some rare pure 64bits systems don't have a /usr/lib/ anyway) and it'd be impossible to install both 32bits and 64bits (which is a pain).

The other one is that neko executable are neko + the n file behind, except that's not mentioned in the elf headers, so strip will get rid of the n file, and a linux build server do that so haxelib/nekoc/nekotools... are destroyed.

[ashes999]

Two more cents from a dual Windows/Unix user on the Unix experience:

• The haxe versions available in repos are usually outdated. Very outdated.
• The installation experience is smooth on Windows. On Linux, it's harder, because of Neko integration specifically. HaxeFlixel maintains an excellent script to manage this; I think there are already discussions to reuse that for "core" Haxe.

[delahee]

leaving link archives : https://launchpad.net/~eyecreate/+archive/ubuntu/haxe

[delahee]

link for suse : http://rpm.pbone.net/index.php3/stat/4/idpl/23755285/dir/opensuse/com/haxe-3.0-81.7.i586.rpm.html

[delahee]

link for neko centos : http://rpm.pbone.net/index.php3/stat/4/idpl/23755262/dir/centos_6/com/neko-2.0.0-65.1.x86_64.rpm.html

[kulick]

The other Linux specific problem that I see regularly is related to an interaction between neko and the strip tool.

I've been meaning to write this down (write this up?) for a while now. This may not be the best location for this write up. If people know of a better location, feel to copy this text or tell me the location and I'll do same. :)

Problem description: Running strip on programs constructed from neko bytecode using the 'nekotools boot' command causes these programs to stop working as intended.

Details:

Using 'nekotools boot' to create a directly executable program from a neko bytecode file results in an executable that contains both the neko interpreter and the bytecode file. Since the resulting file is likely an ELF format binary and that file's ELF headers do not contain a section describing the neko bytecode, the strip command will believe that these extra bytes are not important and it will remove them to reduce the file size (as is strip's goal after all).

After stripping an executable that was built with 'nekotools boot', that executable will effectively revert to behaving just like the 'neko' program since that is what it will be (the interpreter with no bytecode concatenated onto the end of the file). The symptom for this kind of error is that programs that are not the neko interpreter begin to behave as if they were the neko interpreter (and, in fact, at that point, they are.)

Neko itself includes three binaries that are built in this way and that are susceptible to this kind of problem: nekoc, nekoml, and nekotools. The haxe distribution includes haxedoc and haxelib which are also neko programs that are susceptible.

The effect of this issue is two-fold. First, many simple rpmspec files that attempt to build and package neko or haxe fail because they include default binary stripping logic which breaks nekoc, nekoml, nekotools, haxedoc, and haxelib. Similar problems are surely possible with Debian packages also. The second form of this kind of problem occurs on some Linux distributions that contain logic that attempts to optimize disk space by running a nightly cron job that strips binaries. This version is particularly insidious since things work for a while and mysteriously fail at some point later. On laptops or other machines that aren't left on all night, it can be even trickier to understand since it may not happen for some number of days.

Anyway...fixing these kinds of problems is probably an important part of building and packaging neko and haxe in a way that also them to work correctly and permanently when people do a simple install using their operating system's package manager.

[kulick]

Here is another example error...

$ cp /usr/bin/nekotools . $ strip nekotools $ ./nekotools boot example.ml Uncaught exception - load.c(181) : Module not found : boot

The error you get depends on how you try to run what is in effect the neko interpreter.

Here are some search matches that I think are actually this problem (usually misdiagnosed)...

https://code.google.com/p/nekovm/issues/detail?id=32 http://echelog.com/logs/browse/haxe/1361746800 http://www.openfl.org/archive/community/bugs/uncaught-exception-loadc393-invalid-module-runn/

And, problem diagnosed by Nicolas years ago...

https://groups.google.com/forum/#!topic/haxelang/0VO2j0G7C4s

[delahee]

@kulick I took liberty to uplift the issue here https://github.com/HaxeFoundation/neko/issues/75

[Merelleya]

I have to ask since I feel a little confused: Is this issue in the right repository?

It seems to me that this is about getting issues in other repositories fixed or actions taken with regards to having stable linux realeases of both Haxe and neko. If that is the case, would you mind transferring the "To-Do"s and discussion there?

Also, @delahee, would you mind making a list of things that you want to "have done" and then, if necessary, create the relevant issues in the relevant repositories? I know we can create lists of tasks in GitHub, but unfortunately, those can not be assigned to people, so I think you might have more luck to get things done, if you create separate issues. That way, progress can be made in small steps, which is better than no steps.

[delahee]

@Merelleya This is a meta-issues as it expand through many aspect of haxe...It is not just about having stable versions but also resolving communication and cross polinisation issues.

Imvho, this is the right place for the ticket but it will have dependencies toward many other issues...

It take a big amount of time to centralize and make list of where is actually haxe in the unix world and so I need a repository, I can do it out of here but I don't really where to put...if you insist I can create a "own" repository but then I would not be able to invoke team players...

So i will juste assign this to myself for now if it does'nt bother you.

[Merelleya]

Just as long as you get actionable thingies out of it xD

[kulick]

Thanks for the uplift, @delahee. :+1:

Sorry for the noise, @Merelleya...

[ncannasse]

@delahee any progress on this ? @andyli might be able to help when he have some time maybe ?

[andyli]

I've already looked into debian. I can start to work on it. But again, since haxe depends on neko, I hope neko 2.1 will be released soon (https://github.com/HaxeFoundation/neko/issues/69), or else we have to package neko 2.0.

[delahee]

I am not actively progressing this one myself. Its more a central monitoring issues, Andy li and some other guys seems to have taken note and are taking action which looks very promising to me.

Where we are :

0- https://github.com/HaxeFoundation/neko/issues/75 must be fixed so that packaging the Haxe tk is safe and easier this is a priority. If andy li want to have a look that would be awesome !

1- Made a roundup of different distros and it seems there are active maintainers here and there, I plan to ask the foundation to directly link their package on haxe pages as 0 is ok 2- We shoud start a discussion with the different maintainer of the major distros then 3- Continue to watch activity and try to act

This is a collective effort, I sadly cannot take full ownership, only executive overview over this as I am no linux users neither have I got much time.

I hope it's ok , don't hesitate to pull me off if you find better alternative ;)

[kulick]

Sorry for slow progress on HaxeFoundation/neko#75. Trying to move that one forward.

Also, I build neko RPMs here at TiVo, so we have an rpm spec file that can be used for packaging neko if that's helpful. Just FYI.

[hughsando]

Just thinking laterally about this - you could compile haxelib with hxcpp. Had to make a few minor changes (plus one where doc.dependencies was an empty object, rather than an empty array), but all seemed to work. It runs a bit faster (although both run fast), but it is a bit bigger. But it can be compiled statically with no external dependencies.

[delahee]

Very nice indeed ! Le 16 juil. 2015 16:34, "Hugh Sanderson" notifications@github.com a écrit :

Just thinking laterally about this - you could compile haxelib with hxcpp. Had to make a few minor changes (plus one where doc.dependencies was an empty object, rather than an empty array), but all seemed to work. It runs a bit faster (although both run fast), but it is a bit bigger. But it can be compiled statically with no external dependencies.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFoundation/Project-Management/issues/29#issuecomment-121975505 .

[delahee]

Ok Andy progressed a lot on the debian side, Todd and Nicolas made everything needed for stripping.

Thanks all, this is a good show that when big problems are isolated we can move on together, I'll close for now as this issue is globally adressed, the sub problems will be handled at individual scale.