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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 553F37EEF6 for ; Mon, 15 Jun 2015 18:56:04 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of kennethadammiller@gmail.com) identity=pra; client-ip=209.85.218.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="kennethadammiller@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of kennethadammiller@gmail.com designates 209.85.218.46 as permitted sender) identity=mailfrom; client-ip=209.85.218.46; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f46.google.com) identity=helo; client-ip=209.85.218.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-oi0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAQCFAn9Vmy7aVdFchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEBBgsLCSEuhCIBAQEDARIRHQEbHgMBCwYFCw0qAgIhAQERAQUBHAYTCBqHdwEDCgipAT4xiz+Ba4J5ix4KGScNV4RjAQEIAgEZAQUOizaCTYFuUoJogUUFkQeCVIclgj2BYIEzhASDBYg+hUwSI4EMCYQ7IjGCRwEBAQ X-IPAS-Result: A0AcAQCFAn9Vmy7aVdFchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEBBgsLCSEuhCIBAQEDARIRHQEbHgMBCwYFCw0qAgIhAQERAQUBHAYTCBqHdwEDCgipAT4xiz+Ba4J5ix4KGScNV4RjAQEIAgEZAQUOizaCTYFuUoJogUUFkQeCVIclgj2BYIEzhASDBYg+hUwSI4EMCYQ7IjGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,620,1427752800"; d="scan'208";a="136344250" Received: from mail-oi0-f46.google.com ([209.85.218.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Jun 2015 18:56:03 +0200 Received: by oiax193 with SMTP id x193so5484713oia.2 for ; Mon, 15 Jun 2015 09:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3UAlvR7ky9LFR9SVZg+S9mPDGBCma/S8yQlVTXYtJhk=; b=fJlMgDsTLetAdkxpRspdwCMLQfOlzmMHKENP/+Jme/p0WvD7Nbx+neCt4M/H1N+yiH g2ygyYqqt+dTIHv32KLUOSu1bmhNv2H073XBnx//YsH+VextcqF0l8r2zJcLUjuK9OCW Yp+Miicoxa+Kt6mSqDvkvyVk6I9mz6sIczqFMFbrBstnapwaRiW5kRToJmosAjcOD45b L+fMRnelpdmeMZT4AMfBS1tUb1GPznRKAUeJztFE0aVNbGDSO05WT2XJx/PkIzEFVy+U EsA766eyBIVgiaxN4SyEQUYnrlnet/eabaaMVpWTIgmYOwsCUOyF+7e0MoneQ6R0wFJJ WCJg== MIME-Version: 1.0 X-Received: by 10.202.63.212 with SMTP id m203mr23334584oia.35.1434387361794; Mon, 15 Jun 2015 09:56:01 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Mon, 15 Jun 2015 09:56:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 12:56:01 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=001a113d6cb82b918c05189155c1 Subject: Re: [Caml-list] Unit testing Core Async --001a113d6cb82b918c05189155c1 Content-Type: text/plain; charset=UTF-8 That helps-I was literally looking up a way to running unit tests on that google group. I think that group helped a lot, I'll try and read what I can there before I blast the list (I didn't know about it before hand). On Mon, Jun 15, 2015 at 12:53 PM, Carl Eastlund wrote: > Internally at Jane Street -- and this may show up in some of the publicly > released code, but off the top of my head, I don't know what file to point > you at -- we run some of our async unit tests using > [Thread_safe.block_on_async_exn]. That will spin up the scheduler if > necessary, run the function you give it, block until the deferred is > determined, then return. It does not shut down the async scheduler; we > generally don't do that until the program is done, so we would leave the > scheduler up from one test to another. I don't know the entire rationale > behind this design, there may be a way to shut down the scheduler in > between tests, but in general it does not appear to be necessary. > > As for partial reads, if you're concerned with receiving whole messages, I > think [Reader.read_one_chunk_at_a_time] can do what you need -- if you get > too little, just return [`Consumed (n_already_consumed, `Need > n_total_bytes_to_proceed)]. > > I hope this helps! > > On Mon, Jun 15, 2015 at 12:33 PM, Kenneth Adam Miller < > kennethadammiller@gmail.com> wrote: > >> 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? >> > > > > -- > Carl Eastlund > --001a113d6cb82b918c05189155c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That helps-I was literally looking up a way to running uni= t tests on that google group. I think that group helped a lot, I'll try= and read what I can there before I blast the list (I didn't know about= it before hand).

On Mon, Jun 15, 2015 at 12:53 PM, Carl Eastlund <= ;ceastlund@ja= nestreet.com> wrote:
Internally at Jane Street -- and this may show up in some of the= publicly released code, but off the top of my head, I don't know what = file to point you at -- we run some of our async unit tests using [Thread_s= afe.block_on_async_exn].=C2=A0 That will spin up the scheduler if necessary= , run the function you give it, block until the deferred is determined, the= n return.=C2=A0 It does not shut down the async scheduler; we generally don= 't do that until the program is done, so we would leave the scheduler u= p from one test to another.=C2=A0 I don't know the entire rationale beh= ind this design, there may be a way to shut down the scheduler in between t= ests, but in general it does not appear to be necessary.

As for partial reads, if you're concerned with receiving whole message= s, I think [Reader.read_one_chunk_at_a_time] can do what you need -- if you= get too little, just return [`Consumed (n_already_consumed, `Need n_total_= bytes_to_proceed)].

I hope this helps!

= On Mon, Jun 15, 2015 at 12:33 PM, Kenneth Adam Miller <= ;kennethad= ammiller@gmail.com> wrote:
=
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?



--
C= arl Eastlund
--001a113d6cb82b918c05189155c1--