commits
apparently comparison of Gem::Version with a string was also added around that time
- when #sections is called, load all sections to the end
- in #inspect output, show sections as [...] if not loaded
The CAR includes several "sections", but unless someone wants to process the MST data, you only really need one of those sections that includes the record data. This section is usually one of the first few ones. If we parse them only on demand and only get to the one we need, skipping the rest, we can often save half or more of the work.
iso8601 is 2-3x faster than .parse and Time.new is ~10x faster than iso8601
so that they are included in inspect output
so they can be printed in the inspect output
Because EventMachine uses a single special "reactor thread" to run things and handle events, and there can be only one such thread at a time, you can't run two completely separate such setups in one process. You could run the second Stream inside the existing reactor thread, but this can lead to some unexpected behavior, like Stream#start method exiting immediately when you expect it to block (since the current thread isn't blocked to run the reactor, but simply passes the proc to the other thread), or different Streams blocking each other if processing events takes a bit longer than expected (since the processing of both would happen on the same thread, unless work is explicitly done in the background).
If you want to do it anyway and you know what you're doing, you know what to do.
The CAR includes several "sections", but unless someone wants to process the MST data, you only really need one of those sections that includes the record data. This section is usually one of the first few ones. If we parse them only on demand and only get to the one we need, skipping the rest, we can often save half or more of the work.
Because EventMachine uses a single special "reactor thread" to run things and handle events, and there can be only one such thread at a time, you can't run two completely separate such setups in one process. You could run the second Stream inside the existing reactor thread, but this can lead to some unexpected behavior, like Stream#start method exiting immediately when you expect it to block (since the current thread isn't blocked to run the reactor, but simply passes the proc to the other thread), or different Streams blocking each other if processing events takes a bit longer than expected (since the processing of both would happen on the same thread, unless work is explicitly done in the background).
If you want to do it anyway and you know what you're doing, you know what to do.