00:19 <headius[m]> lopex: they definitely target the large scale data processing apps

00:19 <headius[m]> if you need to have 64TB of data in flight you probably want zing

00:29 <lopex> headius[m]: and nowadys business is more and more keen to rely on it

00:30 <headius[m]> There's certainly demand above a certain scale

00:30 <lopex> yeah, it;s percentages

00:31 <lopex> aka demand

00:31 <lopex> now is aggregation of sensor networks and BI

00:31 <headius[m]> Apps seem to be trending away from giant monoliths though

00:33 <lopex> but thre's a trend, more ppl seem to be wanting all the data the is available

00:34 <lopex> and then that 5 year old machine learning slogan

00:35 <lopex> I'm agnostic

00:35 <lopex> it's a business thing

20:44 <headius[m]> done with my talk at the Graal workshop

20:45 <headius[m]> rg_3: welcome!

20:58 <rg_3[m]> Thanks!

21:05 <headius[m]> rg_3: Do you have any small apps you're interested in trying out? Most of the time it's just a matter of getting it to bundle and then see how it runs

21:12 <rg_3[m]> headius: i'm in this weird situation where most (i guess all) open source ruby i have written is not compatible with jruby. it's either using Thread#set_trace_func, or fork/IPC features. but i'd like to change that and leverage JVM features for a change.

21:12 <headius[m]> sounds like some interesting use cases! We have talked about making set_trace_func always available but it's hard to do without introducing at least a little overhead

21:13 <headius[m]> it doesn't prevent our JIT from working but it gets in the way of deeper optimizations

21:14 <rg_3[m]> yeah, the `set_trace_func` project could be useful for developer tools, how is set trace func enabled right now on jruby?

21:15 <rg_3[m]> since this project is also threaded and makes some assumptions, it'd be interesting to see if it works on jruby at all

21:35 <headius[m]> set_trace_func is always there but most of the interesting events will only fire with --debug flag

21:36 <headius[m]> e.g. line or call events

21:38 <headius[m]> I think heavier events like opening up a class or throwing an exception may be always-on

22:11 <rg_3[m]> warning: thread "Ruby-0-Thread-1: /home/rg/code/me/trip.rb/lib/trip.rb:88" terminated with exception (report_on_exception is true):

22:11 <rg_3[m]> NoMethodError: private method `set_trace_func' called for #<Thread:0x36727edd@/home/rg/code/me/trip.rb/lib/trip.rb:88 run>

22:12 <rg_3[m]> on cruby, Thread#set_trace_func is public

22:39 <headius[m]> Huh I didn't know they had added a thread-local version of it...that may be a 2.6 feature?

22:40 <headius[m]> It shouldn't be hard to add but it is not there yet

22:43 <rg_3[m]> yeah, Thread#set_trace_func is thread-local

22:43 <rg_3[m]> i think it's way before 2.6 ?

22:44 <rg_3[m]> i've been relying on it for a while

22:47 <rg_3[m]> sadly, 0 of my projects work on jruby 😁

22:47 <headius[m]> Huh yeah at least as far back as 2.4

22:47 <headius[m]> Either the tests for this are weak or we just never got around to it. All the trace uses I know of are global or use tracepoint

22:48 <headius[m]> What are you using tracing for?

22:49 <rg_3[m]> pointing you to this readme probably explains it best: https://github.com/rg-3/trip.rb#readme - i built a concurrent tracer with it, it'd be cool to see if it could work on jruby, as how control is yielded back & forth might be peculiar to cruby as well