More haxelib libs.

[deltaluca]

What are the possibilities for having say, 'all' haxelib libs available for use?

[clemos]

In theory it would be quite easy;

There are just two things that prevent me from adding 'all' of them:

• Most libs have additional dependencies : some are available only on one or x target(s), some need an .swf (away3d) or .js (jQuery) to be included, some need specific compilation flags.
• I try to be careful as to what the available library actually does under the hood, mainly for security reasons: macros can have access to files on disk, which can become a vulnerability. Currently, only user code is scanned for macros, not library code...
• A significant number of libraries just don't work anymore, often because they are not maintained. I prefer to keep the project free of these.

All this is not really a big deal, but these are the main reasons why I just can't "add them all": adding libraries requires human intervention.

Feel free to give suggestions as to which libraries you'd like to be available.

[bradparks]

you could consider including "HaxeFlixel" (haxelib install flixel).... It's a game library for haxe that's becoming quite popular, and even though it's png based, there's lots that can be tested/demoed without assets....

[deltaluca]

Well one that would certainly be useful for me would be Nape :) Whenever I need to give advice on my forums I always want to quickly set up an example showing how things work, and try.haxe would be great for it!

[bradparks]

for what it's worth, I second the vote for nape ;-)

[profelis]

@deltaluca just fork project and add your favorite libs here https://github.com/clemos/try-haxe/blob/master/src/Libs.hx#L35 (check libs for macros filesystem access and etc)

[bradparks]

@clemos is already providing an important piece of the puzzle right now - maintenance and hosting of it... Which is a significant contribution, and I think would be nice as a "one stop" eval shop for haxe ;-)

[clemos]

Thanks all for your suggestions.
Good to see try-haxe is appreciated ;).
Now, as @profelis said, I'd rather accept pull requests than adding them myself.
Otherwise, I may do it when I have some time, but it is very unlikely this month... :p

[bradparks]

hey @clemos - are you still open to having haxe flixel or nape added to this? I could do a fork and add them if you are....

[clemos]

Yeah sure, I'm open to adding more libs.
I'll try to take some time soon to upgrade try-haxe:

• merge @profelis 's haxe3 branch / provide haxe2+3 support (for older demos)
• merge @freakinruben 's branch ? (didn't review yet, but looks promising)
• add more libs
• fix some security issue ( @profelis knows what I mean :p )

Hopefully I'll be able to deploy a new version online next week or something.

[bradparks]

so did you want me to do a fork for adding nape/flixel? Or are you planning on adding even more libs?

[clemos]

I'd definitely prefer a fork / pull request ;)

[bradparks]

cool... i'll see what I can do! thanks....

[freakinruben]

Hey Clemos,

Here's my list of changes to try-haxe:

• use md5 hash of code+used libs instead of random token
• haxe3
• split try-haxe website code from try-haxe code-editor. They can also be splitted into seperate projects now
• upgraded version of CodeMirror
• optimalizations
• ability to use more then one try-haxe-editor on a page
• define compile-options per try-haxe-editor in html. This also means specifying haxelibs more easily

Cheers,
Ruben

[markknol]

I think it would be super awesome if these libraries/frameworks could be supported:

• OpenFL
• Flambe
• Flixel
• Haxeui
• Heaps

This will not only encourage people to doodle around with these common haxe libraries, but also to have sharable live-examples and offer the opportunity to help others with with small issues.

[clemos]

Regarding OpenFL and Flambe, they have a different build system, so it will require some changes here and there.
The others can definitely be added to try-haxe, as long as they don't introduce security caveats: for instance, any library that allow loading external files at compile-time would be a threat.
@ metadata are currently disabled for this reason, but I believe some of these frameworks expose API methods such as Assets.load( path ) that are going to be difficult to secure.
So if anyone is interested in reviewing each of these framework for these potential security issues, and then adding it to the UI / API, I'd be happy to merge a PR and take care of installing these frameworks on the server.