[Grace-core] My wishes/desires for Grace this fall

[Kim Bruce]

What I'm hoping for in both cases is an underlying substrate that we commit to supporting in the future.  I spent a lot of time this summer working on developing libraries based on Processing, only to find that now they are no longer supported.  In the GTK+ library you again add a disclaimer that there is no guarantee they will be supported in the future.  A guarantee of that sort is what I am looking for.

Similarly for the concurrency library.  It is more important to me that I have a dependable basis to build on than that it be fine-tuned for performance.

Can we make a decision on what will be supported in both of these cases?

Kim



On Sep 25, 2012, at 7:18 PM, Michael Homer wrote:

> On Wed, Sep 26, 2012 at 12:38 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
>> Hi,
>> 
>> I'd like to write more Grace programs this fall, which will entail me working further on a Grace equivalent of the objectdraw library and making sure that event-driven programming and concurrency both work.
>> To continue this work I would appreciate (PLEASE!) the following help from the folks in New Zealand:
>> 
>> 1.  Reintegrate the processing support into the compiler, for either (though ideally both) back end.
> It has never been integrated in the first place. There is no native
> Processing library. I do have prototype GTK+ bindings that run
> natively: <https://github.com/mwh/grace-gtk>.
>> 2.  Provide some set of bindings in either (ideally both) backends so that I could write libraries for true concurrency to be used in Grace.
> JavaScript is always single-threaded. There is River Trail that
> supports certain kinds of concurrency but I think it's data-parallel
> only and so couldn't really help you here.
> 
> There is a hacky pthreads module but it breaks in a lot of
> circumstances at the moment, although you can try it if you like. I
> have attached a patch for it on top of master (interface: def thrd =
> pthreads.create { some code } ; thrd.join). I'm not sure how often it
> breaks these days - the runtime isn't really ready for it, but I did
> make some more things thread-local for it so it's not as bad as it
> was. You can try it out anyway - it might be a good enough start for
> what you're doing.
> -Michael
> <pthreadsmodule.patch>