tag:blogger.com,1999:blog-1445545651031573301.post3240693088163498353..comments2022-04-27T00:11:58.467-07:00Comments on Ambassador to the Computers: How froc worksJake Donhamhttp://www.blogger.com/profile/04768087689799941690noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1445545651031573301.post-55833952129357268052013-04-09T02:33:00.674-07:002013-04-09T02:33:00.674-07:00re building it -- fwiw i've recently packaged ...re building it -- fwiw i've recently packaged Froc up for opam, and it's now in the main repo. seemed to build just fine using ocaml 4.00.1 and 4.01.0dev+trunk, modulo the Makefile patches i had to include in the opam package. thought you might be interested...morthttps://www.blogger.com/profile/12200457619167911747noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-37005057340560811702013-03-28T04:22:55.409-07:002013-03-28T04:22:55.409-07:00FROC is now available in OPAM via `opam install fr...FROC is now available in OPAM via `opam install froc`Anil Madhavapeddyhttps://www.blogger.com/profile/12639201598014663735noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-10433035139500057752013-03-15T20:11:14.878-07:002013-03-15T20:11:14.878-07:00Cool, nice to see someone using it. Unfortunately ...Cool, nice to see someone using it. Unfortunately I don't do OCaml for work any more and I have no opportunity to use or improve froc at the moment, so it is dormant.<br /><br />I think froc is usable as it stands (although I have not tried building it with a recent OCaml), but there is certainly more that could be done with it. One direction I'd like to go is support for "traceable" data structures as in<br /><br /> http://www.umut-acar.org/publications/pldi2010.pdf<br /><br />or some other efficient way to handle small changes to large data structures.<br />Jake Donhamhttps://www.blogger.com/profile/04768087689799941690noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-34875632709499796452013-03-15T06:55:21.942-07:002013-03-15T06:55:21.942-07:00Hello! Noting that Froc updates are 2 years old, i...Hello! Noting that Froc updates are 2 years old, is Froc dormant, or do you use it and it simply is a completed product without need of fixes or extensions? I've written about Froc and implemented a Flows module modeled after "Deprecating the Observer Pattern with Scala.React" paper, in lecture 10 at http://www.ii.uni.wroc.pl/~lukstafi/pmwiki/index.php?n=Functional.Functional#curlectureLukasz Stafiniakhttps://www.blogger.com/profile/13429327869433289392noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-91926906903735359712013-02-04T17:06:41.165-08:002013-02-04T17:06:41.165-08:00Thanks for the comment, I'm glad you are enjoy...Thanks for the comment, I'm glad you are enjoying froc.<br /><br />1) You are right, thanks for the fix.<br /><br />2) Only successful values are propagated via bind, not exceptions. If you want to attach a notifier which receives exceptions you can use notify_result_b, which for an 'a behavior passes an 'a result (i.e. Value of 'a | Fail of exn) to the notification function. You could also use try_bind, catch, etc. to handle exceptions.<br /><br />2bis) For notifications set with notify_b_cancel you are returned a cancellation handle; call Froc.cancel on it to cancel the notification. Other kinds of attachment (bind, notify_b, etc.) are cancelled automatically when their enclosing scope is cleaned up.<br /><br />3) Timestamps are allocated in order as evaluation proceeds; calls to bind force an evaluation order. So in the second example, 100/x is bound to x within the bind of b, so its node has a later timestamp.<br /><br />4) One way to accomplish it is to fire a single event consisting of the tuple of values you want, then take the tuple apart in an event handler and pass the parts where you need them.Jake Donhamhttps://www.blogger.com/profile/04768087689799941690noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-37276849168460181602013-02-04T09:45:47.495-08:002013-02-04T09:45:47.495-08:00Hello Jake,
Thanks for your excellent froc librar...Hello Jake,<br /><br />Thanks for your excellent froc library, i had given up learning frp until I came across your blog entry and library.<br /><br /><br />1) <br />In the example, the definition of y should be :<br />let y = bind2 b n0 (fun b _ -> if b then return 0 else n0) <br /><br />2)<br />I am baffled by the following code :<br /><br />let print_nl s = print_string s; print_newline()<br /><br />let u,send_u = make_cell 1<br />let v,send_v = make_cell 1 <br />let x = blift2 u v (fun u v -> u/v)<br />let y = blift2 u v (fun u v -> u*v) <br /><br />let x' = blift x (fun _ -> print_nl "x changed") <br />let y' = blift y (fun _ -> print_nl "y changed") <br /><br />Now in the toplevel :<br />send_v 2;;<br />x changed<br />y changed<br />- : unit = ()<br /><br />so far so good, but when I set v to 0 :<br /><br />send_v 0;;<br />y changed<br />- : unit = ()<br /><br /><br />Does froc "holds and hides" the Division_by_zero exception and only exposes it only when I do "Froc.sample x" ?<br />If so, why isn't the x' notifier never get triggered for that value, even when I do an explicit sample ?<br /><br /><br />2bis)<br />In the example above, is there any way to "unbind" the x' behavior so that any subsequent update of x wont trigger the print_nl "callback"<br />I guess the cleanup function is what I need, it would be great if you could provide me an example.<br /><br /><br /><br />3)<br />In the ddg section, you explain the timestamp update mechanism. Yet, if the "b" node had an initial timestamp value of 1 and "n0" a ts value of 0, this wouldnt work.<br /><br />Does Frog somehow (seems impossible to me since it would require statical code analysis) figures out that the "b node" determines the control flow and hence gets allocated a lesser timestamp than the n0 node ?<br />Or is it simply because we defined the b behavior before n0 ? (it dont think so because i switched the order and didnt observe a different result)<br />Or because the same phenomenon as in 2) occurs ?<br /><br /><br />4) <br />Is there any controlled way to fire n events simultaneously <br />(so that everything gets treated within the same update cycle ) ?<br /><br />let's consider the behavior u = f(v,w,x,y,z) above. I want to change<br />"atomically" (within the same update cycle) the 4 inputs without trigering 4 distinct update cycles.<br /><br /> <br />Thanks in advance and sorry for this long comment <br />Jeanhttps://www.blogger.com/profile/02392879304315949917noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-59476381700661726552010-05-08T11:19:16.985-07:002010-05-08T11:19:16.985-07:00Oops, of course, thanks for the correction.Oops, of course, thanks for the correction.Jake Donhamhttps://www.blogger.com/profile/04768087689799941690noreply@blogger.comtag:blogger.com,1999:blog-1445545651031573301.post-86231921659089639802010-05-08T10:55:14.932-07:002010-05-08T10:55:14.932-07:00shouldn't the return of map be: return (Cons (...shouldn't the return of map be: return (Cons (f h, t)) instead of: return (Cons (h, t)) [the same goes for memoized version] ?Unknownhttps://www.blogger.com/profile/10222516666682837564noreply@blogger.com