Takafumi Arakaki
Takafumi Arakaki
Ah, I see. That makes sense.
My implementation `wait_timeout(c::Channel, timeout::Real)` above https://github.com/JuliaLang/julia/issues/36217#issuecomment-643719590 looks like easily generalizable. In particular, I think we can implement `waitfirst(waitables...)` quite easily. I wonder if it makes sense to define internal interface...
What are the other implementation strategies? Maybe we can define `waitfirst(waitables...)` if we have `waitfirst(::Condition, ::Condition)` as a primitive? I'm guessing that the cancellable wait can then use "shared" (e.g.,...
Don't you need `close(::Task)` for `wait_until` to work in full generality? For example, `wait_until(c::Channel, timeout)` shouldn't close `c`, right? (Discussion above: https://github.com/JuliaLang/julia/issues/36217#issuecomment-643685832). I can imagine `wait_until` would work if I...
OK, I guess discussion for it can happen elsewhere. Anyway, I'm still interested in your implementation strategy for `wait_until(c::Channel, timeout)` that does not close `c`.
There is now https://github.com/JunoLab/ProgressLogging.jl which should be usable as a drop-in replacement of Juno. I also created https://github.com/tkf/ConsoleProgressMonitor.jl as a console-based backend for handling the log messages using ProgressMeter.jl. ref:...
It looks like `flush` is not needed anymore thanks to #124. But that change is not released yet #100.
> You can reference finder instances by percol.model_candidate.finder and percol.model_action.finder. Ah, I didn't notice. I think this solves my problem.
(Hi, allow me to jumping in. I just found this in Julia slack.) > but that means that no one will ever be able to overload `*` to represent the...
> I think there's even more nuance to the dispatch vs checking point. In Julia, not being able to resolve a method statically (e.g. due to type instability) is not...