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 7DAB27EEF6 for ; Mon, 15 Jun 2015 18:57:32 +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.214.176; 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.214.176 as permitted sender) identity=mailfrom; client-ip=209.85.214.176; 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-ob0-f176.google.com) identity=helo; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="kennethadammiller@gmail.com"; x-sender="postmaster@mail-ob0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7AQD9An9VlLDWVdFchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEHCwsJHzCEIgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMbB4d3AQMKCKh+PjGLP4FrgnmLIAoZJw1XhGMBAQEHAgEZAQUOizaCTYFuUoJogUUFkQeCVIclgj2BYIEzhASDBYg+hUwSI4EMCYQ7IjGCRwEBAQ X-IPAS-Result: A0A7AQD9An9VlLDWVdFchEMGgxjCKwKBNQdMAQEBAQEBEgEBAQEHCwsJHzCEIgEBAQMBEhEdARseAwELBgULDSoCAiEBAREBBQEcBhMbB4d3AQMKCKh+PjGLP4FrgnmLIAoZJw1XhGMBAQEHAgEZAQUOizaCTYFuUoJogUUFkQeCVIclgj2BYIEzhASDBYg+hUwSI4EMCYQ7IjGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,620,1427752800"; d="scan'208";a="165418120" Received: from mail-ob0-f176.google.com ([209.85.214.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Jun 2015 18:57:31 +0200 Received: by obbsn1 with SMTP id sn1so68335199obb.1 for ; Mon, 15 Jun 2015 09:57:30 -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=SU2onKecjXkQ418dAQkFeXF2HM5n7PjhYIs+/gtCW+0=; b=DdE1b4KjvpYQAURQCKbzDLMOvzsa+vswX3uczyg0OrHnoXf/yoJzaGd1EKWON4nQ/j NrG7WORv2BjvlktbfPRXNCcDeN1kZpVSbfeBgLzAJH2nKR5cZQOXx0rbDiit7YQz9pNA H+fgV/Z2IwsvzjLMleLXUQAJsbR0Ja31TtAfT3vityLvwinpelODwm19QkGVjdtu2DZF 1dBue7hlVlOTsgLxAS8F4SJ4g1XXsSkAlF7trhCuKbyVwgqqNa+dL9G2PrO/HEu0Jwm9 Zwc9LbIgGKyhs/1R3iRqKCSxeN4pzFj9TJ2FfvLeCR0HPsG/LIsYXPa7YsyF/PUkbqXD Q2+g== MIME-Version: 1.0 X-Received: by 10.202.242.212 with SMTP id q203mr19393009oih.52.1434387450446; Mon, 15 Jun 2015 09:57:30 -0700 (PDT) Received: by 10.202.191.8 with HTTP; Mon, 15 Jun 2015 09:57:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jun 2015 12:57:30 -0400 Message-ID: From: Kenneth Adam Miller To: caml users Content-Type: multipart/alternative; boundary=94eb2c09561474490e0518915af6 Subject: Re: [Caml-list] Unit testing Core Async --94eb2c09561474490e0518915af6 Content-Type: text/plain; charset=UTF-8 Oh, as far as shutting the scheduler down, I just wanted the scheduler to return from the go (); I need my unit tests to execute until completion but afterward just finish. I think the solution you pointed me to was exactly what I was looking for. :) On Mon, Jun 15, 2015 at 12:56 PM, Kenneth Adam Miller < kennethadammiller@gmail.com> wrote: > 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 >> > > --94eb2c09561474490e0518915af6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, as far as shutting the scheduler down, I just wanted t= he scheduler to return from the go (); I need my unit tests to execute unti= l completion but afterward just finish. I think the solution you pointed me= to was exactly what I was looking for. :)
=
On Mon, Jun 15, 2015 at 12:56 PM, Kenneth Ad= am Miller <kennethadammiller@gmail.com> wrote:
=
That helps-I was literally = looking up a way to running unit tests on that google group. I think that g= roup helped a lot, I'll try and read what I can there before I blast th= e list (I didn't know about it before hand).

On Mon, Jun 15, 2015 at 12:53 PM, Carl Eastlund <ceastlund@janest= reet.com> wrote:
Internally at Jane Street -- and this may show up in some of the p= ublicly released code, but off the top of my head, I don't know what fi= le to point you at -- we run some of our async unit tests using [Thread_saf= e.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, then = return.=C2=A0 It does not shut down the async scheduler; we generally don&#= 39;t do that until the program is done, so we would leave the scheduler up = from one test to another.=C2=A0 I don't know the entire rationale behin= d this design, there may be a way to shut down the scheduler in between tes= ts, but in general it does not appear to be necessary.

A= s 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 g= et too little, just return [`Consumed (n_already_consumed, `Need n_total_by= tes_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, a= nd 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 mini= mal functionality testing complete that demonstrates proper behavior as wel= l as intended usage.

What I'm wondering is the follo= wing: 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 depend= ent on the server's responses and all of that, so that once completed, = it can call Shutdown.shutdown?

I tried this out, a= nd it introduced some issues.=C2=A0

First, I think= that my shutdown call got executed before the unit test was able to comple= te. 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 blo= cking receive that operates on a common execution chain. I don't see an= y kind of Deferred.await that blocks until the instance resolves (yes, ther= e's upon, but that's just nesting again because it returns another = deferred.

Second, I think shutdown shuts *everythi= ng* 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 ce= rtain about the semantics of Pipe/Reader/Writer. It's not behaviorally = like what I'm familiar with. For instance, callbacks may return prematu= rely 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 no= w 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 rece= ive whole protobuf messages.=C2=A0

Can anyone plea= se help me?



<= font color=3D"#888888">--
Carl Eastlund
<= /div>


--94eb2c09561474490e0518915af6--