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 D8A1A7EEF6 for ; Mon, 15 Jun 2015 18:54:31 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of ceastlund@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ceastlund@janestreet.com"; x-sender="ceastlund@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of ceastlund@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ceastlund@janestreet.com"; x-sender="ceastlund@janestreet.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@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ceastlund@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcAQCFAn9VnHDIaSZchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEBBhYJT4QjAQEDARIRHQEBNwEECwsLNwICIQESAQUBHAYTIod4AwoIA6h+PjGKT3CEZAEFi2INhToBAQEBAQEEAQEBAQEBAQEUBgqLOoJNgW5LB4JogUWRDIJUhyWCPYFggTOEBItDhUwSI4EVhDtTgkcBAQE X-IPAS-Result: A0AcAQCFAn9VnHDIaSZchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEBBhYJT4QjAQEDARIRHQEBNwEECwsLNwICIQESAQUBHAYTIod4AwoIA6h+PjGKT3CEZAEFi2INhToBAQEBAQEEAQEBAQEBAQEUBgqLOoJNgW5LB4JogUWRDIJUhyWCPYFggTOEBItDhUwSI4EVhDtTgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,620,1427752800"; d="scan'208";a="136344062" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 15 Jun 2015 18:54:30 +0200 Received: from tot-qpr-mailcore2.delacy.com ([172.27.56.106] helo=tot-qpr-mailcore2) by mxout1.mail.janestreet.com with smtp (Exim 4.82) (envelope-from ) id 1Z4XeX-0003Bg-4d for caml-list@inria.fr; Mon, 15 Jun 2015 12:54:29 -0400 X-JS-Flow: external Received: by tot-qpr-mailcore2 with JS-mailcore (0.1) (envelope-from ) id BVfwNF-AAACkb-EF; 2015-06-15 12:54:29.131508-04:00 Received: from mail-ie0-f181.google.com ([209.85.223.181]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1Z4XeX-0000bG-1y for caml-list@inria.fr; Mon, 15 Jun 2015 12:54:29 -0400 Received: by iecrd14 with SMTP id rd14so35119884iec.3 for ; Mon, 15 Jun 2015 09:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CKa1pYWAnZ+31Fy6N6P151h7bK6d7CFmNcPpRFts6D8=; b=SkWIp/AA/irqFlepO1236hlhap81QZ+NzmUAfwT3jAt5Xy16HvICO+chaIo7mCpgrp kLaSXThnlhDOQDEr9iS5bHetM0ouZ33PwcETOx/olPjz3vFcSJcvPGky8/os+vIfRlJ/ TAWL2zJupw5oID5SKlG0MGiHVF+587UtKXTEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CKa1pYWAnZ+31Fy6N6P151h7bK6d7CFmNcPpRFts6D8=; b=BC+MYxcgbCPzvr7g6jYGu72SGcVWbynEvcPvHzIe5Go+IsBD8D1ci2NmRUWYtLEbFJ nDF11P9ZG8xQlt+6Q05UI5wbrGf5qTjhd0muah9DtCj0QbjHLU0LiBzuRhOaa3UcHmLi Bmq9lRkdJkjE7nROotPdDqZasrt7UYDliNRcM2C84GvpzmRrqfEecwYtjLIBxSQawueE 0Tbf5Nimg8DgOjfYxxy83TTkxq7qdFqtMImKpaiiqE13ePgDSGK+eKjROrN6jldl8ToA tq0LekebhlWuj47AGWIK9wdvwwsCIY5spm1iysRgge2OL79OJiQxNeeF4jccnfRZ1ERK ko0w== X-Gm-Message-State: ALoCoQkhhpuHZLtM0ND7kECnVRlpjWvassvcFiVx/Op7ph2PnsAW6uX8uJ1PvZcFLdcV6PhTqa90khoZwsg/raS3Na+GpTtVyprN87UtEBZSXPquHc1r6uvWjk/CsADFM6c2TNUuWRYr X-Received: by 10.107.28.202 with SMTP id c193mr28528021ioc.90.1434387268714; Mon, 15 Jun 2015 09:54:28 -0700 (PDT) X-Received: by 10.107.28.202 with SMTP id c193mr28528003ioc.90.1434387268579; Mon, 15 Jun 2015 09:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.29.4 with HTTP; Mon, 15 Jun 2015 09:53:48 -0700 (PDT) In-Reply-To: References: From:Carl Eastlund Date: Mon, 15 Jun 2015 12:53:48 -0400 Message-ID: To:Kenneth Adam Miller Cc:caml users Content-Type: multipart/alternative; boundary=001a113ff13c9d57e10518914f28 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Unit testing Core Async --001a113ff13c9d57e10518914f28 Content-Type: text/plain; charset=UTF-8 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 --001a113ff13c9d57e10518914f28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 [Th= read_safe.block_on_async_exn].=C2=A0 That will spin up the scheduler if nec= essary, run the function you give it, block until the deferred is determine= d, then return.=C2=A0 It does not shut down the async scheduler; we general= ly don't do that until the program is done, so we would leave the sched= uler up from one test to another.=C2=A0 I don't know the entire rationa= le behind this design, there may be a way to shut down the scheduler in bet= ween tests, but in general it does not appear to be necessary.

As for partial reads, if you're concerned with receiving whole m= essages, 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, 2= 015 at 12:33 PM, Kenneth Adam Miller <kennethadammiller@gmail.co= m> wrote:
= I've noticed that Core Async requites that a Scheduler.go () call be pl= aced-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 i= s a wonderful library, but I'm adamant that I have at least some minima= l functionality testing complete that demonstrates proper behavior as well = as intended usage.

What I'm wondering is the followi= ng: would there be a way to have the scheduler.go call be placed in order t= o fire things off, but in another thread have all the test code be dependen= t 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.=C2=A0

First, I think t= hat my shutdown call got executed before the unit test was able to complete= . This is because using Async's Deferred introduces some complication i= f you want behavior to proceed sequentially as in without building deeply n= ested callback chains. What I'm used to is asynchronous send, and block= ing 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&= #39;s upon, but that's just nesting again because it returns another de= ferred.

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

Third, I'm not cert= ain about the semantics of Pipe/Reader/Writer. It's not behaviorally li= ke what I'm familiar with. For instance, callbacks may return premature= ly 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 ma= ke the threads coordinated, but I need the Tcp Server to allow me to receiv= e whole protobuf messages.=C2=A0

Can anyone please= help me?



--
Carl Eastlund
--001a113ff13c9d57e10518914f28--