07:24 <flux> I wonder if the meta-future-system could be used for writing an X-like windowing system, that would minimize the amount of round-trips

07:24 <flux> (and if such a system -would- actually reduce the round-trips compared to current systems)

08:10 <kaustuv> what is a meta-future-system?

08:10 <flux> http://okmij.org/ftp/meta-future/

08:15 <kaustuv> I think AliceML already did futures-as-RPC

08:16 <kaustuv> http://www.ps.uni-saarland.de/alice/manual/tour.html#distribution

08:23 <flux> but did it do batching?

08:24 <flux> the page has some pretty convincing examples of how seemingly complicated operations boil down into one round-trip

08:24 <flux> ..but one always wonders how it would work in 'real life'

08:29 <kaustuv> I think the only difference between futures-as-chr and futures-as-aliceml-futures is that the 'app' constructor is implicit in the latter. In other words, futures are silently coerced in Alice when there is a data dependency.

08:31 <kaustuv> Otherwise, I think you can definitely weave the equivalent of a chr using client code and then execute it in a single swoop.

08:32 <kaustuv> (note, I don't know AliceML that well and have only briefly scanned Oleg's page, so I might be talking nonsense as usual.)

08:39 <flux> kaustuv, I got the idea that the differences are:

08:39 <kaustuv> Futures are actually pretty neat devices. One can write a perfectly type-safe tail recursive List.map because futures let you implement the one-shot setcdr needed for it. I don't know why no "serious" ML dialect uses them (I'm guessing because of performance reasons)

08:39 <flux> 1) one .force forces all pending evaluations (maybe..?)

08:40 <flux> 2) one cahn bind the result of a remote opertation into the argument of a following remote op

08:41 <flux> 3) there is operation "guard"

08:42 <flux> and these together enable batching a greater number of even dependant ops into one round-trip

08:45 <Axioplase_> maybe because the user base itself is not comfortable with futures…

08:47 <kaustuv> flux: Well, strictly speaking you can just ship arbitrary code to the server using Remote.proxy in AliceML, so I think you should be able to do at least the limited computations supported by the CHR DSL.

08:47 <kaustuv> flux: But having the DSL explicitly might make the programmer more aware of what's going on, so it might be a better approach overall.

08:49 <flux> k, this approach is interesting in that it could work even in c++ ,)

08:49 <kaustuv> except for the type-safe bit, presumably

08:50 <flux> i think templates could help with that

09:42 <avsm> is there any way to pack a hierarchy of subdirectories into a -pack namespace in ocamlbuild?

09:42 <avsm> a/b/c becomes A.B.C

09:43 <avsm> you can't repack a packed cmx, it would appear, or could be done using individual .mlpack files in ocamlbuild

09:45 <gildor> avsm: is there a way to do it without ocamlbuild ?

09:46 <avsm> yeah, -for-pack A.B.C at the top-level

09:46 <avsm> which isn't so bad, but I would need to not use .mlpack files and use an ocamlbuild plugin. just wondering if there's an easier way

09:47 <gildor> avsm: maybe there is a for_pack(A.B.C) to put into _tags

09:51 <gildor> avsm: for-pack(A.B.C) maybe

09:52 <gildor> http://brion.inria.fr/gallium/index.php/Ocamlbuild_and_module_packs

09:59 <avsm> it's not that easy it seems

09:59 <avsm> If I compile a/b/c with -for-pack A.B.C

09:59 <avsm> you can't -pack A

10:00 <avsm> so hierarchies dont work

10:09 <avsm> hah, so ocamlopt -pack -for-pack works

10:09 <avsm> so if you go up the tree packing and repacking, it all seems to hold. now to get ocamlbuild to do that :)

10:13 <gildor> avsm: humm, hierarchy don't work even wo ocamlbuild ?

18:04 <adrien> is js_of_ocaml (or any other) able to interact with the system? like run a program or anything like that? (yeah, I *really* don't know js :-) )

18:18 <hcarty> adrien: My understanding is that most browsers have security layers which prevent that from happening.

18:18 <adrien> but does the language allow it?

18:19 <hcarty> That's a good question :-)

18:19 <adrien> bah, I'll google :P

18:19 <adrien> I need a graphical interface for a program and I don't want deps but it has to be portable too =/

18:19 <adrien> bah, I'll just use sdl or Graphics =P

18:25 <mfp> adrien: you could distribute the app as a web server

18:27 <adrien> mfp: yes, that was the initial plan but it doesn't look like a lot of fun and I was wondering if the various javascript "interfaces" could be good for making interfaces

18:28 <mfp> adrien: well, you'd use the JS "interfaces" you refer to, with the server providing the interaction with the system you needed

18:29 <mfp> ocsigen's dev branch has got some funky Eliom client integration to run code on the client but it's not really documented yet

18:29 <mfp> http://ocsigen.org/eliom/manual/dev/4

18:30 <mfp> "...use Eliom for mixing client side and server side programming. Eliom allows to write the client and server parts of a Web application fully in Objectice Caml..."

18:30 <adrien> right, that'd probably be better than only doing it from the webserver (I haven't tried it but doing it all in the webserver doesn't sound like something very nice)

18:30 <adrien> hmmm, that sounds interesting, will probably try during the holidays :P

18:31 <adrien> the biggest problem will probably to get it running on windows :-)

18:32 <adrien> as for the javascript part, I could also use the standalone interpreters/whatever from the various engines

18:33 <adrien> well, still not sure what I'll use in the end but it sounds like it should be possible to get something nice =)

19:16 <flux> kaustuv, something said by dmarbour @ ltu about the meta-future vs code sending: Sending code to the server is more general and powerful, but introduces concerns about security (sending malicious or buggy code), resource management (divergent code), and complexity (embedding an interpreter in the server app). By comparison, the promise pipelining style is a lot easier to reason about for security, has a resource cost no different from processing the ...

19:16 <flux> ... remote calls individually, and has a simpler implementation that can be quite small and easily embedded in an RPC element without any significant interpretation.

19:18 <hcarty> flux: Is the meta-future option the Oleg link you posted?

19:21 <hcarty> flux: Nevermind - from the ltu comments it looks like it is

19:24 <flux> yes :)