From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 3D84BBBAF for ; Tue, 23 Jun 2009 02:26:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYCAHK+P0rRVdzemGdsb2JhbACYJz8BAQEBAQgJDAcTp0iOPAEDAgSEBgWHLQ X-IronPort-AV: E=Sophos;i="4.42,272,1243807200"; d="scan'208";a="31743320" Received: from mail-fx0-f222.google.com ([209.85.220.222]) by mail1-smtp-roc.national.inria.fr with ESMTP; 23 Jun 2009 02:25:57 +0200 Received: by fxm22 with SMTP id 22so4075501fxm.9 for ; Mon, 22 Jun 2009 17:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=SUxYMG2v+x+J7dwfR4AoUVUKuZBFTOh2T0DhKvUjFGo=; b=ATj+XfLT4Zg0gh58XuCHmawGDcOe1VPjxN2GFobu0Dt9xk8ihuLfOcnIucTMVg8brO yCp7JL2Gz2DZSNBZbuzm6ZZ8LejAYOKXt0WpzeFiL1uWmznNC5GkstCGvdvBr5w3NnRi e+DJeevb9yzhzXlLoCMU/EC/uRfFNrYvc8/Xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=lC6XvkgDWxDabTqPbb92D7TWDrEASekO1DcOVRPmEF6zrUjiQlsgYIrwULmawrZFj7 YvA0SXgKp/3V261nNaHrFEEQvZTsNNFjk2UHbFTNo/4s4uL3BmUM/pUxlsr0fDddglB6 6D7u+OIrif0Pmu8Mf2VYX9+CSlhF3TcegMQSw= Received: by 10.103.252.17 with SMTP id e17mr2621588mus.14.1245716756934; Mon, 22 Jun 2009 17:25:56 -0700 (PDT) Received: from ?192.168.1.34? (5-232.76-83.cust.bluewin.ch [83.76.232.5]) by mx.google.com with ESMTPS id e9sm14200239muf.32.2009.06.22.17.25.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Jun 2009 17:25:56 -0700 (PDT) Sender: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Message-Id: <66E06129-1281-48F4-AE9D-E56FD716917A@erratique.ch> From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= To: OCaml List In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [Caml-list] Re: Obj.magic and existential types. Date: Tue, 23 Jun 2009 02:24:22 +0200 References: <4A3BCE1A.3010403@citycable.ch> <91F6B99D-3075-47A1-9257-0BD208C6D5D8@erratique.ch> X-Mailer: Apple Mail (2.935.3) X-Spam: no; 0.00; bunzli:01 buenzli:01 existential:01 distro:01 pointer:01 corresponds:01 dependencies:01 toplevel:01 garbage:01 garbage:01 abstract:01 compile:01 caml-list:01 short:01 benjamin:01 Le 22 juin 09 =E0 11:19, Benjamin Canou a =E9crit : > Abstract: The weak.js file remaining in the distro is a mistake. I =20 > see possibilities to implement them but have no short term plans for =20= > a perfect solution. Thanks for your response. Since it allows to compile more sources =20 without changes I'd leave the weak support in obrowser, but I'd make =20 it clear in the documentation that so far no weak pointer will ever be =20= reclaimed. So to sum up using react in obrowser will leak, however it doesn't =20 leak in "traditional" environments. Le 22 juin 09 =E0 19:02, Jake Donham a =E9crit : > Everything in froc happens on a "timeline". When you bind a changeable > value, there's a chunk of the timeline that corresponds to the dynamic > scope of the bind function. When the value changes, that chunk is > removed, which unregisters any dependencies created in the course of > evaluating the bind function. But in this "chunk" can you repeatedly get external (in the sense =20 primitive) input ? Because _if_ you can't then in the breakout game example where you =20 need to constantly gather (external) time and keyboards events you =20 cannot "pipe" those under a single bind where you create the game =20 simulation and logic signals needed for a game run as any new =20 keyboard or time event would garbage collect them. In that case the =20 game signals need to be defined outside a toplevel bind and cannot be =20= garbage collected by froc, it wouldn't be fixed "by wrapping =20 everything in a top-level bind". Best, Daniel=