From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7B1A07EEF6 for ; Mon, 15 Jun 2015 18:33:04 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.218.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.218.54 as permitted sender) identity=mailfrom; client-ip=209.85.218.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f54.google.com) identity=helo; client-ip=209.85.218.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQDy/H5VmzbaVdFchEMGgxiwFpNLB0wBAQEBAQESAQEBAQEGCwsJIS6EOxEdARseAxIJBzcCJAERAQUBIjWHdwEDEqVLgzE+MYs/gWuCeYsbChknDVeFCQEFDo9xgzqBRQWTW4clhB2BM4QEkQ8SI4EMCYQ7IjGCRwEBAQ X-IPAS-Result: A0D/AQDy/H5VmzbaVdFchEMGgxiwFpNLB0wBAQEBAQESAQEBAQEGCwsJIS6EOxEdARseAxIJBzcCJAERAQUBIjWHdwEDEqVLgzE+MYs/gWuCeYsbChknDVeFCQEFDo9xgzqBRQWTW4clhB2BM4QEkQ8SI4EMCYQ7IjGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,618,1427752800"; d="scan'208";a="165414520" Received: from mail-oi0-f54.google.com ([209.85.218.54]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Jun 2015 18:33:03 +0200 Received: by oigx81 with SMTP id x81so3500772oig.1 for ; Mon, 15 Jun 2015 09:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xe3uZ4ycW7Fw1xb0vaOFiM+13gPp1Rpj1GHAfKmYCGY=; b=sDahLtI2pusgE/51mccKvW90mmtA7sSvoYHnnt8ecA5iWpY3s3MJZZn8c9ebv06/4n Cy0ja3RG5Bxkt4rOfkO3OmgaXrcNzjI9ebSP2l1HMOlBPhm48Ihr9848XcgnpIhwmIGx dxht4fehQVOK07jih0boH3yuPszPcGXkezRzc0YVJ4c4iVHT8GR3M+kodgvSHKzlhGk8 AmtRl+o7WR2px+GZvl6vxVrTlEqCLH+8K2BeyuooGqh4nOOCXNrTN9bR5/7BQWNgmCxg Ep46hbsBe/gto0MMCvnv5sxtkI9KvjxrGMM353ySIcfwrZ52jbH8n4lkQe0X7oc4aXJH 8sSA== MIME-Version: 1.0 X-Received: by 10.60.134.132 with SMTP id pk4mr24887498oeb.7.1434385982754; Mon, 15 Jun 2015 09:33:02 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Mon, 15 Jun 2015 09:33:02 -0700 (PDT) Date: Mon, 15 Jun 2015 12:33:02 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=047d7b47252cf9153a0518910296 Subject: [Caml-list] Unit testing Core Async --047d7b47252cf9153a0518910296 Content-Type: text/plain; charset=UTF-8 I've noticed that Core Async requites that a Scheduler.go () call be placed-but that never returns. I have a Tcp.server that I'm creating, and I like to use oUnit for my tests. Monads and all are beautiful, and Core is a wonderful library, but I'm adamant that I have at least some minimal functionality testing complete that demonstrates proper behavior as well as intended usage. What I'm wondering is the following: would there be a way to have the scheduler.go call be placed in order to fire things off, but in another thread have all the test code be dependent on the server's responses and all of that, so that once completed, it can call Shutdown.shutdown? I tried this out, and it introduced some issues. First, I think that my shutdown call got executed before the unit test was able to complete. This is because using Async's Deferred introduces some complication if you want behavior to proceed sequentially as in without building deeply nested callback chains. What I'm used to is asynchronous send, and blocking receive that operates on a common execution chain. I don't see any kind of Deferred.await that blocks until the instance resolves (yes, there's upon, but that's just nesting again because it returns another deferred. Second, I think shutdown shuts *everything* down. What I need is just to signal the completion of the job that was supposed to run, so that the Scheduler.go returns in order to allow my unit tests to run to completion. Third, I'm not certain about the semantics of Pipe/Reader/Writer. It's not behaviorally like what I'm familiar with. For instance, callbacks may return prematurely and only have part of a message. In ZMQ, what you send is what you get. So that makes me concerned in regards to the Tcp.Server, because right now what I need is for the Pipe to just allow blocking receive so that I can make the threads coordinated, but I need the Tcp Server to allow me to receive whole protobuf messages. Can anyone please help me? --047d7b47252cf9153a0518910296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've noticed that Core Async requites that a Scheduler= .go () call be placed-but that never returns. I have a Tcp.server that I= 9;m creating, and I like to use oUnit for my tests. Monads and all are beau= tiful, and Core is a wonderful library, but I'm adamant that I have at = least some minimal functionality testing complete that demonstrates proper = behavior as well as intended usage.

What I'm wonderi= ng is the following: would there be a way to have the scheduler.go call be = placed in order to fire things off, but in another thread have all the test= code be dependent on the server's responses and all of that, so that o= nce completed, it can call Shutdown.shutdown?

I tr= ied this out, and it introduced some issues.=C2=A0

First, I think that my shutdown call got executed before the unit test was= able to complete. This is because using Async's Deferred introduces so= me complication if you want behavior to proceed sequentially as in without = building deeply nested callback chains. What I'm used to is asynchronou= s send, and blocking receive that operates on a common execution chain. I d= on't see any kind of Deferred.await that blocks until the instance reso= lves (yes, there's upon, but that's just nesting again because it r= eturns another deferred.

Second, I think shutdown = shuts *everything* down. What I need is just to signal the completion of th= e job that was supposed to run, so that the Scheduler.go returns in order t= o allow my unit tests to run to completion.

Third,= I'm not certain about the semantics of Pipe/Reader/Writer. It's no= t behaviorally like what I'm familiar with. For instance, callbacks may= return prematurely and only have part of a message. In ZMQ, what you send = is what you get. So that makes me concerned in regards to the Tcp.Server, b= ecause right now what I need is for the Pipe to just allow blocking receive= so that I can make the threads coordinated, but I need the Tcp Server to a= llow me to receive whole protobuf messages.=C2=A0

= Can anyone please help me?
--047d7b47252cf9153a0518910296--