On 31 October 2010 16:14, Johan Tibell wrote:

This version marks the end of the network-bytestring package, which has now been merged into the network package. This means that efficient and correct networking using ByteStrings is available as part of the standard network package.

As part of the merger, two new modules have been added: Network.Socket.ByteString and Network.Socket.ByteString.lAzy

Huzzah! I updated my little throttler program to use ByteString.[1] One thing I'm curious about, that maybe you probably know off the top of your head, is that when I'm limiting the speed, I was merely recv'ing and send'ing at 1024 bytes a pop[2], however, when I did this at, say, ~500KB/s, Firefox is really slow at receiving it, whereas when I set it 4096 it's much faster/more accurate to the speed I intend. Chrome doesn't seem to care. I think the difference is that Firefox is single threaded (select/poll-based?) and has to switch between various jobs while receiving every tiny block that I'm sending. Chrome probably has the receiver in a separate process. So it seems like, short of balancing the package size (at powers of 2) and the delay to get some ideal throughput, it's easiest and probably realistically equivalent to set it to 4096 and just rely on an accurate delay? What do you think? Just curious. This is something I think I'll look into in the future, I really don't have a good feel for typical network latency and throughput. It's not a big deal right now as "56k slow" is all I need to test my web app. [1]: http://github.com/chrisdone/throttle/commit/97e03bfc64adc074c9d1f19c2605cb49... [2]: http://github.com/chrisdone/throttle/commit/30dc1d970a7c0d43c1b6dc33da9deecf...

On Sun, Oct 31, 2010 at 4:14 PM, Johan Tibell wrote:

Hi all,

I like to announce a new version of the network package, network-2.2.3. You can install the latest version by running:

   cabal update && cabal install network

This version marks the end of the network-bytestring package, which has now been merged into the network package. This means that efficient and correct networking using ByteStrings is available as part of the standard network package.

As part of the merger, two new modules have been added: Network.Socket.ByteString and Network.Socket.ByteString.lAzy

This release is backwards compatible with the previous release.

After merging the packages, I only bumped the minor version of network. That wasn't a great idea, as anyone with a dependency on "network == 2.2.*" (or equivalent) and network-bytestring got build problems due to module name clashes. I've released network-2.3 and added a preferred version constraint to Hackage to avoid having people end up using network-2.2.3.*. If you want the new ByteString-based modules please depend on network-2.3.*, if you use qualified imports, and network-2.3.0.*, if you don't. If you previously depended on both network and network-bytestring and still want to support older versions of network you can use Cabal's flag feature. Example: flag network-bytestring Library if flag(network-bytestring) build-depends: network < 2.2.3, network-bytestring < 0.1.4 else build-depends: network >= 2.3 && < 2.3.1 Sorry for the mess. Johan