Suggested Improvements to Try Haxe ! Site


(Randy Maxwell) #1

Haxe compiler on the Web is a great learning experience.
I have seen others and myself use it to help figure out code solutions.

I think there could be:
More Haxe target language options.
Do every output language that Haxe supports now.
That really shows the unique strength of Haxe.

Instead of Radio Buttons for selecting a target language
Right now is only JavaScript or SWF
Change to Check Boxes for the various languages.
Perhaps have JavaScript also built by Default along with any other languages.

I think most important is to make available all the generated sources from the site just as JavaScript or SWF is made available now.

I think Java and Python might especially be wanted by someone using Try Haxe because there may be low overhead. Java or Python may be already available to Run, even on phone platforms.

What would be even more impressive is to allow fairly significant input as the Haxe code to compile. Allowing multiple .hx source files from a src directory as is typical when building a Haxe project locally.

I think there was some discussion about allowing the Haxe compiler to run on platforms other than Desktops or Laptops. Making these suggested changes to Try Haxe ! could be like an big wave of acceptance for Haxe Then to get the Haxe compiler to run on less capable platforms would not be as urgent.

(Mark) #2

It is open source and Clemos probably would appreciate the help, so go ahead

(Philippe) #3

It’s worth noting that sandboxing is a difficult exercise for this kind of execution environment.

(Ian Harrigan) #4

Out of interest, what is the general thoughts about sandboxing a haxe env? I know “mr ck” does it by just stripping macros - but is that enough? I looked at a few things, and went with the macro stripping idea (before my SSD went the way of the dodo)

What about docker? Could that work? Each execution is in its own container… is that a huge resource hog?

(Jens Fischer) #5

Do you mean I think that actually does allow macros, and runs in Docker. The second source tab is even called Macro by default.

(Ian Harrigan) #6

Oh - then im getting completely mixed up. Its been a while since i looked at it. Is it the normal try.haxe that strips macros?

(Ian Harrigan) #7

Yeah, it does work:

Its not just macros. Ignore me, i was thinking about something else, clearly. (very good to know though)

(Philippe) #8

It’s tricky - I’ve seen a few articles about that but essentially, when the script runs on a server you want to guarantee that it runs safe instructions (e.g. can’t be used to DDoS others or the host server) and for a short time (prevent infinite loops).

And the problem of macros is that they have access to some of the Sys methods and could do harmful things potentially.

(Gene Pavlovsky) #9

I love try-haxe, but would really like to see it’s improvements.
The biggest issue for me is library support. I would like to play with various libraries which are not available or are outdated on either try-haxe or try-haxe.mrcdk. Perhaps even different versions of the same library.
Or a library from GitHub (not haxelib), particular commit.
Another thing is being able to use different versions of haxe (e.g. I use haxe 4 for all new projects and it’s a pity try-haxe doesn’t support haxe 4; try-haxe.mrcdk does, but doesn’t have some of the libs I need to play with).
It would be really cool if try-haxe would support lix - that would help to provide support for everything I described. To save disk space, a maintenance script would periodically clean up the least recently used haxe and library versions.
I like some of the features of try-haxe.mrcdk which the regular try-haxe is lacking, it would be nice if they could be merged back and incorporated into upstream.

(Jens Fischer) #10

There’s been some discussion on that topic here: