Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 26 2017 14:18
    codecov-io commented #98
  • Jan 26 2017 14:11
    winitzki synchronize #98
  • Jan 26 2017 14:11
    codecov-io commented #98
  • Jan 26 2017 14:04
    winitzki synchronize #98
  • Jan 26 2017 14:02
    codecov-io commented #99
  • Jan 26 2017 14:01
    codecov-io commented #98
  • Jan 26 2017 13:54
    codacy-badger opened #99
  • Jan 26 2017 13:51
    winitzki opened #98
  • Jan 26 2017 04:21
    winitzki closed #97
  • Jan 26 2017 03:02
    codecov-io commented #97
  • Jan 26 2017 02:57
    winitzki synchronize #97
  • Jan 26 2017 02:50
    codecov-io commented #97
  • Jan 26 2017 02:44
    winitzki synchronize #97
  • Jan 25 2017 18:35
    winitzki synchronize #97
  • Jan 25 2017 09:13
    winitzki synchronize #97
  • Jan 25 2017 09:12
    winitzki opened #97
  • Jan 25 2017 08:40
    winitzki closed #86
  • Jan 25 2017 08:26
    winitzki synchronize #86
  • Jan 25 2017 07:58
    winitzki synchronize #86
  • Jan 25 2017 07:09
    codecov-io commented #86
Sergei Winitzki
@winitzki
Here is how.
val f = m[ (String, Promise[Int]) ] // choose String and Int types arbitrarily
site(go { case f((x, promiseR)) => .... promiseR.succeed(123) ... })
val p = Promise[Int]()
f("abc", p)
val futureR = p.future
// Done. We got a future that resolves when a reply to f is sent.
Compare this with the code that is implemented currently in Chymyst:
val f = b[String, Int]
site(go { case f(x, reply) => .... reply(123) ... })
val futureR = f.futureReply("abc") // We got a future that resolves when a reply to f is sent.
These code snippets are completely equivalent. Just a little shorter syntax.
Sergei Winitzki
@winitzki
But this is not the unblocking transformation I was talking about.
Sergei Winitzki
@winitzki
I added the futureReply() API in hope that it will be useful for something, and it was not hard to implement.
It does not change the expressive power of the chemical machine, it's just a convenience.
If you would like to have a scala.js implementation where the futureReply() API is the only available API for blocking molecules, that's just as good.
I'm not very familiar with how scala.js works and how to write web applications with it; do you have experience with that?
Sergei Winitzki
@winitzki
As a first step towards a scala.js implementation for Chymyst, I would try to implement only non-blocking molecules, no thread pools, no debugging hooks, and no waiting. This would be a great first step, because a chemical machine with only non-blocking molecules is equally expressive and equally powerful when compared to a chemical machine with blocking molecules.
Walter Chang
@weihsiu
that would be pretty cool. i wouldn't call myself a scalajs expert by any stretch of imagination. i've used scalajs for some small projects and know the pain for dealing with callbacks everywhere.
if your code does not use any native threads and has no dependencies on other libraries, porting to scalajs should be a cinch ;)
Sergei Winitzki
@winitzki
what, a concurrency library that does not use any native threads? ;)
I do use threads, of course. Actually I use thread pools, not the bare Thread object.
all I need is the Pool interface, look at Pool.scala. I need a facility to schedule the execution of a closure, asynchronously.
e.g. I need to be able to do this:
val closure = x => x + 1 + veryLongCalculation(x)
pool.runClosure(closure, 123)
// runClosure returns quickly, but "closure" is scheduled and will run later, when the run loop comes to that
this can be simulated with javascript's setTimeout() API, perhaps.
it has it's own ExecutionContext that is based on setTimeout() and all the future api can run off that.
akka.js dispatcher is probably backed by QueueExecutionContext as well
Sergei Winitzki
@winitzki
I see.
So, perhaps the first step would be to re-implement Chymyst using just Future while keeping in mind that it is going to run in a single-threaded context.
Walter Chang
@weihsiu
or ExecutionContext
Sergei Winitzki
@winitzki
Alternatively, use QueueExecutionContext directly to schedule closures on it, which is perhaps more straightforward since Chymyst doesn't chain futures.
It just schedules closures that mutate some hidden state.
For example, emitting a new non-blocking molecule means scheduling a closure that will add a new molecule copy to the soup and look for possible new reactions involving that molecule.
new reactions can be scheduled in the same way, since we are going to have one execution context for everything.
each reaction is a closure that evaluates the reaction body on the input molecule values.
Walter Chang
@weihsiu

in scalajs, ExecutionContext is usually imported implicitly:
so in scala, we do

import scala.concurrent.ExecutionContext.Implicits.global

in scalajs,

import scala.scalajs.concurrent.JSExecutionContext.Implicits.queue // points to QueueExecutionContext
Sergei Winitzki
@winitzki
does scala.js have an API for web workers?
Walter Chang
@weihsiu
nope
it has facade that wrap regular javascript webworker api calls, but that's about it
Sergei Winitzki
@winitzki
each webworker requires a static .js file to run, correct?
Walter Chang
@weihsiu
yes
Sergei Winitzki
@winitzki
can scala.js generate those .js files from the Scala code of a closure?
Walter Chang
@weihsiu
i did successfully run webworker using scalajs generated javascript
Sergei Winitzki
@winitzki
maybe in this way, with some sbt plugins, one could actually use webworkers directly, implementing a "webworker execution context"
Walter Chang
@weihsiu
it has to be the whole program, not just a closure
Sergei Winitzki
@winitzki
well, it can be a very small program, just computing a function from some arguments, no?
Walter Chang
@weihsiu
webworker in chrome is another PROCESS which is quite heavy. i can't really imagine one webworker per normal jvm thread...
for scalajs, the baggage (collection, utilities, etc) is quite large. it does it's best to trim the generated code but a really simple program using the optimizing output mode is still around 100KB
Sergei Winitzki
@winitzki
I see... so the performance will be really bad. How many webworkers per second can you start?
(assuming that webworker's code itself is really short)
Walter Chang
@weihsiu
i haven't timed it but i would assume it's a lot slower than spawning jvm threads
Sergei Winitzki
@winitzki
I am using the guava library for its ConcurrentMultiSet, but this is unnecessary if you are running on a single thread.
Walter Chang
@weihsiu
yes
Sergei Winitzki
@winitzki
ok - I'm going to bed now.... talk to you later! Let me know if you want to implement something.
Walter Chang
@weihsiu
bye