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.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 5807DBBAF for ; Mon, 22 Jun 2009 02:05:23 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoACAIpnPkpIDtyfk2dsb2JhbACYID8BAQEBCQkKCRMDpgCNTgEDAgSEBgWHKg X-IronPort-AV: E=Sophos;i="4.42,264,1243807200"; d="scan'208";a="28486443" Received: from fg-out-1718.google.com ([72.14.220.159]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Jun 2009 02:05:22 +0200 Received: by fg-out-1718.google.com with SMTP id 22so1031811fge.2 for ; Sun, 21 Jun 2009 17:05:22 -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=vXiAe1i5WNCVg8sBl3OR5g8YFh7mwq4GqTkYJ7B0QgU=; b=wq6ytW1CyCWtqSi6/NoB6MJ/NBQYzGCLLw7G6iZ4QeByANxfzgl26UakQafYCLO5yZ DWEGDIlhdzt6VDnGjvbLm1/6vQ9YlKHREuD/enoxYrvV21kqYuSORrIIz1kF7bt2/ksI 8UhXDaCthEVOEkGsCKihuuHlOluYNrLC7utho= 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=iJNVH0KEkFNCgccgdXQXzI8KQ7+cNgGAvxoVRwP1K9zyirMPWTguQlSA4QtBZn3jHn AdQOTMb2pgWHfdliygmxpWhiYYblmDu+1PWMj3ox3bBLZZp4aumKosFu/ehF8m+HC0dF A3aZWf+s7A71WWSaeadVaHlXPfm1MNxehV8II= Received: by 10.86.79.6 with SMTP id c6mr5866885fgb.52.1245629121295; Sun, 21 Jun 2009 17:05:21 -0700 (PDT) Received: from ?192.168.1.34? (121-40.79-83.cust.bluewin.ch [83.79.40.121]) by mx.google.com with ESMTPS id l19sm7482417fgb.6.2009.06.21.17.05.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Jun 2009 17:05:21 -0700 (PDT) Sender: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Message-Id: 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: Mon, 22 Jun 2009 02:03:45 +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 implements:01 semantics:01 gc'd:01 javascript:98 garbage:01 imho:01 dynamically:01 caml-list:01 module:03 pattern:04 daniel:04 daniel:04 Le 21 juin 09 =E0 20:08, Jake Donham a =E9crit : > I have not tried either, but from a cursory glance at the code I =20 > have the impression that React's space safety relies on support for =20= > weak references, which standard Javascript does not have. Yes. The weak module is available in obrowser, but I don't know if it =20 implements its semantics. If the author of obrowser is on this list =20 would he be kind enough to enlight us ? > Leaks memory, yes in your example, but in a less contrived usage, =20 > where dead references are underneath a bind, Does that mean the only values froc knows how to garbage collect are =20 those values that are dynamically created in an update cycle and not =20 used further ? (because that's rather contrived IMHO) While excessive in allocation rate the example I gave is not that =20 contrived e.g. the same pattern occurs naturally in the terminal =20 breakout game present in react's distribution : each time a new game =20 starts a record of signals is created to manage the simulation and =20 game logic and these signals need to be eventually gc'd when the game =20= is over. Best, Daniel