Announcing activities haxelib - soliciting feedback

[Bryan Ischo]

Hi there.  We've created a haxelib called the "activities" haxelib to provide a thread-like API that is portable across all targets.  The idea being to allow developers to write code once that can take advantage of multiple threads for performance on platforms which support that, but still work on single threaded platforms like javascript.  Additionally, this haxelib tries to provide some nice abstractions for message passing and event handling.

The library is not 100% complete, because it is not fully implemented on all platforms yet, and furthermore, the C++/neko/C# implementations are not actually multithreaded yet.  But the API is complete and working in a single threaded backend implementation on a variety of platforms.  We'd really like some feedback on the API.  If the feedback is positive, we'd like to work on integrating support for it into existing haxelib frameworks like OpenFL.

Here's a link:

http://lib.haxe.org/p/activity

If you follow through to the github link, you'll find the readme that comes up on the repository page to be quite descriptive.

Thanks!

[Benjamin Dubois]

Looks very haxy.

If I read it well,

it's not only cross-platform but also inter-platform, it's a big step forward of the remoting proxy.

--
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/d/optout.

[Simon Krajewski]

Hi Bryan,

I have already seen this library a few days ago and we talked about it
on IRC. The activity abstraction is really nice! What was the
inspiration for that?

Also I really like the way you document public functions. It has a very
professional vibe which is still not very common in Haxe libraries. You
should consider generating API documentation from that, too.

Looking forward to getting actual multithreading support!
Simon

P.S.: Your haxelib.zip includes a .git directory which it probably
shouldn't.

[Bryan Ischo]

On Tuesday, March 31, 2015 at 1:16:17 AM UTC-7, Simon Krajewski wrote:

P.S.: Your haxelib.zip includes a .git directory which it probably
shouldn't.

Whoops!  Thanks for pointing that out.  I will be sure that the next time I zip up the haxelib, I remove the .git directory first!
 

[Bryan Ischo]

On Tuesday, March 31, 2015 at 1:16:17 AM UTC-7, Simon Krajewski wrote:

I have already seen this library a few days ago and we talked about it
on IRC. The activity abstraction is really nice! What was the
inspiration for that?

We had a pre-existing C++ architecture also called "activities" which we have been using for many years.  It was created by one of our software architects very early in TiVo's development history as a way to allow a simpler mechanism for creating a thread-like API that is less error prone to use than real threads.

We have adapted many of the concepts of our C++ activities into this haxe library, but with some differences.  Whereas the C++ library requires all activities to derive from a base class, and uses macros for construction of activities, all with the goal of ensuring that the developer cannot access parts of the API that are unsafe or should not be used, the haxe version doesn't need any of that baggage because it can use true function closures and can be much simpler and more concise.  Also object lifetimes are easier to manage in haxe because of garbage collection; a significant amount of baggage exists in our C++ activites API just to deal with all of the ways that the developer may need assistance in managing activity lifetimes.

I am glad you like the abstraction.  I was worried that people would see it as an unnecessary and superfluous framework.

In terms of why we created it for haxe, it is because we want to be able to continue to write our application in a way that is completely cross-platform and target agnostic, but we do want to be able to take advantage of multithreading where we can because performance is really critical on our set top box platforms, where we have multi-core CPUs.  We thought that adapting the activity API from C++ to haxe would give us a good way to leverage our familiarity with this programming model while at the same time providing a single API that we can write to and get the best performance possible on every platform.

Our goal is to integrate the activity API into OpenFL so that an OpenFL program is already using the activity API without needing to be aware of it (OpenFL would run its UI thread as an Activity), but the full Activity API would then be available to applications who wanted to be aware of and use its functionality, which we would do.

I think it would be interesting if haxe would provide something like the activity API as a part of the standard runtime.  For example, what if haxe provided something like activities in its standard library with the guarantee that each back end would guarantee that the 'main' function was run within an activity?  This would provide a nice programming model where programs could continue to operate as if 'main' bounded the lifetime of the program if they wanted to, but could also use multiple thread-like control structures that would work on every target platform and would provide multi-threading where possible but gracefully fall back to single threaded implementations where necessary.  This would also build a "main loop" into every haxe program implicitly, allowing things like network programming to be easier, as the user would not even have to run their own socket select() loop and manage timers manually and stuff like that.

Also I really like the way you document public functions. It has a very
professional vibe which is still not very common in Haxe libraries. You
should consider generating API documentation from that, too.

Thank you for your comments, they are very encouraging.  Sometimes I over do the documentation, please let me know if it's too verbose anywhere and I'll try to trim it down.  Also, can you recommend a tool for generating the API documentation?

Thanks,
Bryan

[Bryan Ischo]

p.s. We'll be presenting the activity API and providing examples of how it can be used at WWX 2015, so any feedback now that allows us to make the API more complete/usable will really help.  Thank you!

[Justin Donaldson]

Can I make a humble request?  

Can we have a "best of" award session for the year?  I hope that's not too tacky.

I don't mean an award for "best new game framework", "best new asynchronous library", "best  macro for short lambdas", or any of the typical stuff that gets created anyways.  It should be given to folks that put an effort into the areas where we are sorely lacking (documentation, promotion, parody twitter accounts*, etc.).  We could also do the best haxelib of the year, best usage of a new language feature, best armwrestler at wwx (Franco is not competing this year, so it's anybody's game).

*Simn's work on the docs for haxe.org is awesome.

*Skial, likewise

*Haxe hulk has smashed his way into my heart

-Justin

On Tue, Mar 31, 2015 at 10:14 AM, Bryan Ischo <b...@tivo.com> wrote:

p.s. We'll be presenting the activity API and providing examples of how it can be used at WWX 2015, so any feedback now that allows us to make the API more complete/usable will really help.  Thank you!

[Benjamin Dubois]

Was that topic-jacking or you were trying to say it should compete in best haxelib category?

[Justin Donaldson]

I was trying to be subtle.  but yes.

[Simon Krajewski]

Am 31.03.2015 um 19:11 schrieb Bryan Ischo:

Also I really like the way you document public functions. It has a very
professional vibe which is still not very common in Haxe libraries. You
should consider generating API documentation from that, too.

Thank you for your comments, they are very encouraging.  Sometimes I over do the documentation, please let me know if it's too verbose anywhere and I'll try to trim it down.  Also, can you recommend a tool for generating the API documentation?

I'm co-maintaining Dox so obviously I'm gonna recommend that: https://github.com/dpeek/dox

We use it to generate our API documentation: http://api.haxe.org/Map.html
Flambe uses it with a different theme: https://aduros.com/flambe/api/Map.html
Also we'll update our API documentation to use a modification of that theme soon: http://api.haxe.org/v/dev/Map.html

We don't yet have a theme for the typical framed Java API, but my theory is that's because nobody actually likes that one.

Simon

[SunGang]

I have a test with activity lib 1.0.0, but it can not work now.
this project seems be inactive for 3 months, will it be updated or not?

there are two issues:
1. WebSocketTest.hx:17: characters 7-24 : Type not found : activity.Activity
   the classPath is missing from haxelib.json, so the compiler can not find the correct class.
   I fixed it by add "classPath": "src", in haxelib.json.
2. C:\HaxeToolkit\haxe\lib\activity/0,1,0/src/activity/impl/SingleThreadedScheduler.hx:561: characters 8-26 : Class<sys.net.Socket> has no field fast_select
the fast_select seems not available in sys.net.Socket.

Best Regards,
Gang Sun

---

Date: Wed, 1 Apr 2015 09:40:26 +0200
From: si...@haxe.org
To: haxe...@googlegroups.com
Subject: Re: [haxe] Announcing activities haxelib - soliciting feedback

[SunGang]

I found these two issues have been raised before, so ignore it.

---

From: sun_j...@hotmail.com
To: haxe...@googlegroups.com
Subject: RE: [haxe] Announcing activities haxelib - soliciting feedback
Date: Tue, 30 Jun 2015 14:56:14 +0800