Feb 10, 6-7 AM (12)
Feb 10, 7-8 AM (28)
Feb 10, 8-9 AM (20)
Feb 10, 9-10 AM (9)
Feb 10, 10-11 AM (15)
Feb 10, 11-12 PM (22)
Feb 10, 12-1 PM (18)
Feb 10, 1-2 PM (37)
Feb 10, 2-3 PM (20)
Feb 10, 3-4 PM (14)
Feb 10, 4-5 PM (8)
Feb 10, 5-6 PM (10)
Feb 10, 6-7 PM (12)
Feb 10, 7-8 PM (12)
Feb 10, 8-9 PM (12)
Feb 10, 9-10 PM (3)
Feb 10, 10-11 PM (2)
Feb 10, 11-12 AM (4)
Tue
Feb 11, 12-1 AM (13)
Feb 11, 1-2 AM (4)
Feb 11, 2-3 AM (8)
Feb 11, 3-4 AM (12)
Feb 11, 4-5 AM (22)
Feb 11, 5-6 AM (0)
Feb 11, 6-7 AM (5)
Feb 11, 7-8 AM (10)
Feb 11, 8-9 AM (5)
Feb 11, 9-10 AM (20)
Feb 11, 10-11 AM (12)
Feb 11, 11-12 PM (14)
Feb 11, 12-1 PM (10)
Feb 11, 1-2 PM (21)
Feb 11, 2-3 PM (20)
Feb 11, 3-4 PM (14)
Feb 11, 4-5 PM (17)
Feb 11, 5-6 PM (21)
Feb 11, 6-7 PM (6)
Feb 11, 7-8 PM (9)
Feb 11, 8-9 PM (5)
Feb 11, 9-10 PM (2)
Feb 11, 10-11 PM (1)
Feb 11, 11-12 AM (17)
Wed
Feb 12, 12-1 AM (10)
Feb 12, 1-2 AM (7)
Feb 12, 2-3 AM (4)
Feb 12, 3-4 AM (1)
Feb 12, 4-5 AM (15)
Feb 12, 5-6 AM (7)
Feb 12, 6-7 AM (8)
Feb 12, 7-8 AM (7)
Feb 12, 8-9 AM (22)
Feb 12, 9-10 AM (28)
Feb 12, 10-11 AM (22)
Feb 12, 11-12 PM (8)
Feb 12, 12-1 PM (24)
Feb 12, 1-2 PM (12)
Feb 12, 2-3 PM (16)
Feb 12, 3-4 PM (17)
Feb 12, 4-5 PM (19)
Feb 12, 5-6 PM (13)
Feb 12, 6-7 PM (11)
Feb 12, 7-8 PM (4)
Feb 12, 8-9 PM (4)
Feb 12, 9-10 PM (1)
Feb 12, 10-11 PM (0)
Feb 12, 11-12 AM (8)
Thu
Feb 13, 12-1 AM (5)
Feb 13, 1-2 AM (1)
Feb 13, 2-3 AM (0)
Feb 13, 3-4 AM (2)
Feb 13, 4-5 AM (7)
Feb 13, 5-6 AM (13)
Feb 13, 6-7 AM (10)
Feb 13, 7-8 AM (17)
Feb 13, 8-9 AM (17)
Feb 13, 9-10 AM (20)
Feb 13, 10-11 AM (15)
Feb 13, 11-12 PM (18)
Feb 13, 12-1 PM (17)
Feb 13, 1-2 PM (16)
Feb 13, 2-3 PM (8)
Feb 13, 3-4 PM (22)
Feb 13, 4-5 PM (4)
Feb 13, 5-6 PM (17)
Feb 13, 6-7 PM (9)
Feb 13, 7-8 PM (12)
Feb 13, 8-9 PM (6)
Feb 13, 9-10 PM (6)
Feb 13, 10-11 PM (7)
Feb 13, 11-12 AM (3)
Fri
Feb 14, 12-1 AM (3)
Feb 14, 1-2 AM (1)
Feb 14, 2-3 AM (12)
Feb 14, 3-4 AM (2)
Feb 14, 4-5 AM (4)
Feb 14, 5-6 AM (1)
Feb 14, 6-7 AM (5)
Feb 14, 7-8 AM (7)
Feb 14, 8-9 AM (9)
Feb 14, 9-10 AM (16)
Feb 14, 10-11 AM (15)
Feb 14, 11-12 PM (17)
Feb 14, 12-1 PM (23)
Feb 14, 1-2 PM (19)
Feb 14, 2-3 PM (16)
Feb 14, 3-4 PM (7)
Feb 14, 4-5 PM (15)
Feb 14, 5-6 PM (11)
Feb 14, 6-7 PM (2)
Feb 14, 7-8 PM (6)
Feb 14, 8-9 PM (9)
Feb 14, 9-10 PM (2)
Feb 14, 10-11 PM (3)
Feb 14, 11-12 AM (1)
Sat
Feb 15, 12-1 AM (0)
Feb 15, 1-2 AM (2)
Feb 15, 2-3 AM (0)
Feb 15, 3-4 AM (1)
Feb 15, 4-5 AM (4)
Feb 15, 5-6 AM (0)
Feb 15, 6-7 AM (1)
Feb 15, 7-8 AM (1)
Feb 15, 8-9 AM (0)
Feb 15, 9-10 AM (1)
Feb 15, 10-11 AM (3)
Feb 15, 11-12 PM (2)
Feb 15, 12-1 PM (1)
Feb 15, 1-2 PM (0)
Feb 15, 2-3 PM (0)
Feb 15, 3-4 PM (0)
Feb 15, 4-5 PM (0)
Feb 15, 5-6 PM (0)
Feb 15, 6-7 PM (1)
Feb 15, 7-8 PM (0)
Feb 15, 8-9 PM (3)
Feb 15, 9-10 PM (5)
Feb 15, 10-11 PM (6)
Feb 15, 11-12 AM (0)
Sun
Feb 16, 12-1 AM (4)
Feb 16, 1-2 AM (0)
Feb 16, 2-3 AM (0)
Feb 16, 3-4 AM (0)
Feb 16, 4-5 AM (0)
Feb 16, 5-6 AM (0)
Feb 16, 6-7 AM (0)
Feb 16, 7-8 AM (0)
Feb 16, 8-9 AM (1)
Feb 16, 9-10 AM (1)
Feb 16, 10-11 AM (0)
Feb 16, 11-12 PM (0)
Feb 16, 12-1 PM (2)
Feb 16, 1-2 PM (0)
Feb 16, 2-3 PM (0)
Feb 16, 3-4 PM (0)
Feb 16, 4-5 PM (2)
Feb 16, 5-6 PM (1)
Feb 16, 6-7 PM (4)
Feb 16, 7-8 PM (0)
Feb 16, 8-9 PM (0)
Feb 16, 9-10 PM (2)
Feb 16, 10-11 PM (1)
Feb 16, 11-12 AM (2)
Mon
Feb 17, 12-1 AM (6)
Feb 17, 1-2 AM (3)
Feb 17, 2-3 AM (0)
Feb 17, 3-4 AM (1)
Feb 17, 4-5 AM (4)
Feb 17, 5-6 AM (4)
Feb 17, 6-7 AM (4)
1312 commits this week - Page 2 Feb 10, 2020 - Feb 17, 2020

Merge #1343

1343: Introduce SomeMnemonic as source of root keys (instead of entropy) r=Anviking a=Anviking

Issue Number

#1316, preliminary work to unblock #1321

Overview

  • Add SomeMnemonic as return type of fromMnemonic
  • Make e.g. unsafeGenerateKeyFromSeed take a SomeMnemonic instead entropy. This is more similar to Icarus.generateKeyFromHardwareLedger
  • Add genMnemonic helper in a shared location

Comments

Co-authored-by: Johannes Lund [email protected]

Merge #1649

1649: Disable the on-demand start of mini-protocol threads for now r=dcoutts a=dcoutts

Fixes issue #1646.

This is an alternative to #1648. This PR simply disables on-demand start. That PR tries to fix it. However this bit of code is in the middle of being refactored so it is simpler to disable it for now and include the fix in the refactoring.

The problem, we realised, is that which peer initiates the overall mux bearer is actually independent from whether protocol threads should be started on-demand or started eagerly. What it really depends on is which peer has agency in the initial protocol state. For most mini-protocols it is the peer that initiated the bearer that has agency in the initial state, but that is not true for all protocols, and in particular for the TxSubmission protocol in ouroboros-network.

The solution will be to make the on-demand vs eager distinction independent of the initiator vs responder distinction, and have it be specified in the MuxMiniProtocol.

We missed this in the network-mux and ouroboros-network tests because we did not have bundles of mini-protocols with mixed initial agency. This should be corrected.

Co-authored-by: Duncan Coutts [email protected]

Disable the on-demand start of mini-protocol threads for now

Fixes issue #1646

The problem, we realised, is that which peer initiates the overall mux bearer is actually independent from whether protocol threads should be started on-demand or started eagerly. What it really depends on is which peer has agency in the initial protocol state. For most mini-protocols it is the peer that initiated the bearer that has agency in the initial state, but that is not true for all protocols, and in particular for the TxSubmission protocol in ouroboros-network.

The solution will be to make the on-demand vs eager distinction independent of the initiator vs responder distinction, and have it be specified in the MuxMiniProtocol.

We missed this in the network-mux and ouroboros-network tests because we did not have bundles of mini-protocols with mixed initial agency. This should be corrected.

Disable the on-demand start of mini-protocol threads for now

Fixes issue #1646

The problem, we realised, is that which peer initiates the overall mux bearer is actually independent from whether protocol threads should be started on-demand or started eagerly. What it really depends on is which peer has agency in the initial protocol state. For most mini-protocols it is the peer that initiated the bearer that has agency in the initial state, but that is not true for all protocols, and in particular for the TxSubmission protocol in ouroboros-network.

The solution will be to make the on-demand vs eager distinction independent of the initiator vs responder distinction, and have it be specified in the MuxMiniProtocol.

We missed this in the network-mux and ouroboros-network tests because we did not have bundles of mini-protocols with mixed initial agency. This should be corrected.

Merge #1499

1499: Snockets r=coot a=coot

This PR introduce snockets which abstract the interface for Berkeley sockets and named pipes (windows).

The PR consist of smaller reviewable and mostly buildable patches.

Highlight of changes:

Win32-network

A bug fixed in System.Win32.Async.connect

network-mux

  • runMuxWithPipes handles named pipes as well
  • new tests which include posix pipes, named pipes and queues
  • mux-demo - windows named pipe demo using mux: an echo server and client

ouroboros-network

  • IOManager - system indepdendent IO manager. On Windows using System.Win32.Async.withIOManager, on posix it’s a no-op
  • Snockets - abstraction which handles both Berkeley sockets and Windows named pipes, together with smart constructors for both.
  • Snocket shim layer with type alliases for different paltforms (posix / win32)
  • demo-chain-sync - can now run on Windows with named pipes

future work

  • NodeToClient and NodeToNode which are using named pipes for local clients on windows.

Co-authored-by: Marcin Szamotulski [email protected]