Date | Commit message (Collapse) |
|
bogomips.org is due to expire, soon, and I'm not willing to pay
extortionists at Ethos Capital/PIR/ICANN to keep a .org. So
it's at yhbt.net, for now... Identity is overrated.
Tor users can use .onions and kick ICANN to the curb:
torsocks w3m http://rainbows.ou63pmih66umazou.onion/
torsocks git clone http://ou63pmih66umazou.onion/rainbows.git/
torsocks w3m http://ou63pmih66umazou.onion/rainbows-public/
While we're at it, switch news.gmane.org => news.gmane.io
(but I suspect that'll need to be resynched since our mail
"List-Id:" header is changing).
|
|
We're migrating to a new public-inbox[1] + mailing list
rainbows-public@bogomips.org
[1] http://public-inbox.org/
|
|
Clearly users need to know about more options
|
|
They're probably ready for general use in a very limited
capacity...
|
|
They're not bad with slow clients a previously thought.
|
|
The WebSocket protocol is still undergoing changes and unused.
We won't waste time supporting it until it's finalized and
doesn't break HTTP.
|
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
This is also our website, so we need to document the new
Cool.io-based concurrency options for users and point
existing Rev* users to it.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
It is a common base so we can share documentation tasks
more easily with Unicorn and it ensures our RDoc no longer
has JavaScript in it!
|
|
It hits 100% CPU usage and Rev's 1.8 support when mixed
with threads is currently suboptimal. Unfortunately
our tests can not check for 100% CPU usage, so I had to
*gasp* confirm it by actually starting an app :x
This appears to be a fixable bug in Rev, however, and
we'll try to fix it as soon as we have time.
|
|
I still have a hard time keeping track of what's capable of
what.
|
|
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
We'll export this across the board to all Rack applications
to sleep with. This provides the optimum method of sleeping
regardless of the concurrency model you choose. This method
is still highly not recommended for pure event-driven models
like Rev or EventMachine (but the threaded/fiber/actor-based
variants are fine).
|
|
|
|
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
|
|
|
|
Guess I'll have to make the Revactor model work with that.
|
|
|
|
Patches submitted to rev-talk, awaiting feedback and
hopefully a new release.
|
|
|
|
This will hopefully make many things clearer about the project.
|