Re: [Caml-list] Desktop GUI toolkits - current state of the art?
There was also a project by Chris King to develop a GUI based on lablgtk in a Functional Reactive Programming style. http://lambda-the-ultimate.org/node/1918 On Wed, Nov 24, 2010 at 4:57 PM, Hezekiah M. Carty wrote: > On Wed, Nov 24, 2010 at 4:47 AM, Martin DeMello > wrote: > > > > I was surprised not to see much interest in GUI DSLs in OCaml. > > It's not complete or a full-blown DSL, but I started a small Gtk-light > module a while ago. I haven't had the time to complete it, but it > shouldn't be too difficult to modify for your needs: > > http://0ok.org/cgit/cgit.cgi/gtk-light/ > > Here is a brief example (uses the "open Module in" syntax extension): > > http://0ok.org/cgit/cgit.cgi/gtk-light/tree/basic_gui_test.ml > > With OCaml 3.12 the "open Module in" could be replaced by the new "let > open Module in" or Module.(...) syntax. > > Hez > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] zero-arity constructor
On 11/27/2010 11:31 AM, bluestorm wrote: Reversing the specific 0-ary modification suggested by Alain is probably easier, as I suspect most users don't use that one much, but Alain probably makes use of it; As I've been designated as the primary responsible for that uninspired change (I plead guilty), I guess it is my responsibility to state here that frankly, I don't give a damn. That said, enabling the warning by default sounds better to me than reverting the change or introducing a new syntax. -- Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] OCaml GC [was Is OCaml fast?]
Le 27/11/10 22:11, Pierre Etchemaïté a écrit : > Le Mon, 22 Nov 2010 20:33:34 +0200, Török Edwin a > écrit : > >> Not sure what the max should be for the minor heap increase, but based >> on this benchmark increasing size of minor heap never slows down the >> program. Even when size of minor heap exceeds what fits in the cache. >> I guess there is another microbenchmark that can show the opposite >> though. > Another consequence of increasing minor heap size is the latency > introduced by minor heap collections. That said, when does it become > the worse garbage collector latency? (... when heap compaction is > disabled?) > And of course, for many programs such latency matters a lot less than > thoughput... In fact, an allocated block is visited at most twice by a minor GC and if promoted (that if visited twice by the minor GC) at least once by the major GC (when freed because major GC is mark and sweep) ... So a heap allocated block is traversed 0, 1, 3 or more time by one of the GC ... So increasing the minor heap size strictly decreases the number of time a word is examined by one of the GC ... I think that having two heaps is mainly (only ?) for one reason: collecting some memory sooner (and therefore using less memory for dead objects). This may speed up the program because saving memory decreases cache misses, but normaly it slows down the program. But it is still better than one generation GCed more frequently ... The latency is not directly related to minor collection ... If there was only the major heap, OCaml could still to a bit of major-gc cycle at each collection ... This is a (good) design choice of OCaml to have a small minor heap that can be collected in a short time by a simple and fast "stop and copy" algorithm. The main problem of the bin-tree benchmark is when you know that an object will live long enough to be promoted, you can not ask OCaml to allocate it in the major heap directly. This is why increasing the minor heap to have all object collected at the first GC works. A syntax like Node#(x,d,y) to allocate a variant in the major heap directly together with similar syntax for tuples, records, ... could be quite useful in OCaml in general for known long living objects ... An the is the Ancient modules for object that will live even longer. Cheers, Christophe > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs signature.asc Description: OpenPGP digital signature ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml GC [was Is OCaml fast?]
Speaking of the OCaml GC in general, wouldn't it make sense to replace the current generational collector with a collector framework that requires less copying in the common case. For example, dividing the heap into two parts, "large object space" and "small object space", where LOS is managed by mark-sweep/mark-compact (could use the current major heap) and SOS is managed by a recent mark-copy/mark-region collector (Immix [1] comes to mind here). That way objects would no longer need to be copied between generations, and using Immix may also reduce cache misses and improve locality of small/medium sized objects (with proper evacuation heuristics). This should be doable with a moderate amount of work, and should require no incompatible changes, while opening the door for concurrent/parallel garbage collection (this would require incompatible changes then, replacing caml_young_ptr/caml_young_limit with TLS vars, etc.). Benedikt [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.144.3640 ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: oasis
On 27-11-2010, Anastasia Gornostaeva wrote: > On Sat, Nov 27, 2010 at 10:20:38AM +, Sylvain Le Gall wrote: >> Hi, >> >> On 26-11-2010, Anastasia Gornostaeva wrote: >> > Hello. >> > >> > How can I substitute in setup.ml (not in _oasis file) values for >> > CCOpt and CCLib fields? I think it is better to substitute them from >> > setup.data, if I could to put proper values to setup.data. >> > For example: >> > CCOpt: $freetype_ccopt >> > and put to setup.data output of `freetype-config --clib` for field >> > freetype_ccopt. >> >> As I answer you in private: there will be pkg-config support in 0.3.0. >> This will solve this issue, at least. >> (e.g. you will be able to define: >> BuildDepends: freetype2 (pkg-config), oUnit, ...) > > Sorry, but i didnt receive your mail.. I resent it, but it doesn't contains the ultimate solution, just what I said here. > And pkg-config probably is not best solution on bsd and macosx systems because > it does not guarante nothing. > The best (and common) solution is CFLAGS and LIBS env variables. :-) > Or this pkg-config will allow custom paths for those C librares that do not > depend on pkg-config at concrete systems? > > [...] My current state about this solution is: - defines BuildDepends: freetype2 (pkg-config), to make clear that there is a C build-depends - allow to override the defined variable freetype2_cflags and freetype2_libs. If they are both defined by user, don't even call pkg-config for this package > >> > I need a way to substitute paths. >> > >> >> A last solution, you can apply right now, is to override this call: >> let () = setup ();; >> (last line of setup.ml) >> >> by >> >> let f pkg = >> (* Call freetype-config and add flags where >> needed in pkg >>*) >> ... >> >> let () = BaseSetup.setup (f setup_t);; > > Interesting way. Thanks, I'll ckeck it right how. > As you state privately, this indeed has also problem because you also need to do it in myocamlbuild.ml. Here is a new proposal about this: - use a PostConfigureCommand to invoke a shell script freetype2.sh - in freetype2.sh invoke freetype-config and output flags in setup.data using "echo 'freetype2_cflags = "$output"' >> setup.data' and "echo 'freetype2_libs = "$output"' >> setup.data' - add in _tags a "src/toto.cma: pkg_config_freetype2" - add in myocamlbuild.ml a "tag [pkg_config_freetyp2; compile; ocaml] & [... (* load the content of freetyp2_cflags *) ... ]" This is not simple but this is probably what I will do for the support of C libraries in 0.3.0. Regards, Sylvain Le Gall ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Is OCaml fast?
On Thu, Nov 25, 2010 at 11:50:58PM +0100, Fabrice Le Fessant wrote: [...] > The main problem was that other languages have bigger standard > libraries, whereas OCaml has a very small one (just what is needed > to compile the compiler, actually). In many problems, you could > benefit from using a very simple shared-memory library (in > mandelbrot, the ocaml multicore solution has to copy the image in a > socket between processes, whereas it could just be in a shared > memory segment), ...so you work on a shared-mem module?! > and in general, many solutions could benefit from > specialised data structures that are provided in other languages by > their standard libraries, and from some system calls that are > currently not in the Unix library. [...] During the last some releases a lot more unix syscalls were added and that's fine of course). Which calls are you missing there? Ciao, Oliver ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Is OCaml fast?
On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote: > Hello, > > To the extent that this rule is the same for all languages and that most > > languages on the shootout are also garbage collected, I think OCaml's > > problem with this benchmark do point at a weakness of the current > > GC code. > This is untrue ... the bintree example, is just bad in OCaml because the > default > value of the minor heap size is the correct value for reactive programs > where you want fast minor GC slice, because they interrupt the program ... [...] And if your program contains both kinds of functionality? What possible solution would you recommend? Ciao, Oliver ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml GC [was Is OCaml fast?]
On Sun, Nov 28, 2010 at 4:29 PM, Benedikt Meurer < benedikt.meu...@googlemail.com> wrote: > Speaking of the OCaml GC in general, wouldn't it make sense to replace the > current generational collector with a collector framework that requires less > copying in the common case. For example, dividing the heap into two parts, > "large object space" and "small object space", where LOS is managed by > mark-sweep/mark-compact (could use the current major heap) and SOS is > managed by a recent mark-copy/mark-region collector (Immix [1] comes to mind > here). That way objects would no longer need to be copied between > generations, and using Immix may also reduce cache misses and improve > locality of small/medium sized objects (with proper evacuation heuristics). > This should be doable with a moderate amount of work, and should require no > incompatible changes, while opening the door for concurrent/parallel garbage > collection (this would require incompatible changes then, replacing > caml_young_ptr/caml_young_limit with TLS vars, etc.). > > Benedikt > > [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.144.3640 > I was suggesting dealing with small fixed-size objects differently in another post. This doesn't sound like a bad combination, nice idea :) Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] OCaml GC [was Is OCaml fast?]
I don't understand why this would help here though. Wouldn't that help when a long-lived structure was single large block but, in this case, the long-lived structure is a tree composed of many small heap-allocated blocks and, therefore, they would undergo the same wasteful "allocate in young only to be copied to old" pathological behaviour? Surely what you really want the ability to spot when a full minor heap contains mostly live objects and, therefore, make the whole minor heap part of the major heap, allocate yourself a new minor heap and clear the remembered sets. IIRC, G1 does something like this. On a related note, When designing HLVM I thought that a mallocs function that allocated many small blocks of the same size such that they could be freed individually would be helpful. Another option might be to preallocate larger numbers of blocks at the same time under the assumption that a thread allocating many small surviving blocks would continue to do so, as a kind of pool hybrid. Cheers, Jon. From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Eray Ozkural Sent: 28 November 2010 18:57 To: Benedikt Meurer Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml GC [was Is OCaml fast?] On Sun, Nov 28, 2010 at 4:29 PM, Benedikt Meurer wrote: Speaking of the OCaml GC in general, wouldn't it make sense to replace the current generational collector with a collector framework that requires less copying in the common case. For example, dividing the heap into two parts, "large object space" and "small object space", where LOS is managed by mark-sweep/mark-compact (could use the current major heap) and SOS is managed by a recent mark-copy/mark-region collector (Immix [1] comes to mind here). That way objects would no longer need to be copied between generations, and using Immix may also reduce cache misses and improve locality of small/medium sized objects (with proper evacuation heuristics). This should be doable with a moderate amount of work, and should require no incompatible changes, while opening the door for concurrent/parallel garbage collection (this would require incompatible changes then, replacing caml_young_ptr/caml_young_limit with TLS vars, etc.). Benedikt [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.144.3640 I was suggesting dealing with small fixed-size objects differently in another post. This doesn't sound like a bad combination, nice idea :) Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] OCaml GC [was Is OCaml fast?]
On Nov 28, 2010, at 20:40 , Jon Harrop wrote: > I don’t understand why this would help here though. Wouldn’t that help when a > long-lived structure was single large block but, in this case, the long-lived > structure is a tree composed of many small heap-allocated blocks and, > therefore, they would undergo the same wasteful “allocate in young only to be > copied to old” pathological behaviour? There is no "young" and no "old" in this scheme. There are two different heaps, one for large objects, one for small (probably 2-8k max object size, so not really small in the sense of OCaml). The small area is managed by Immix, which avoids copying of long-lived objects if they are allocated together with other long-lived objects (likely), or if not evacuates a set of probably related objects to a single chunk (this is somewhat dependent on the evacuation strategy, which will be differnt for OCaml compared to Java), further improving locality. There are simple heuristics to ensure that an object is not evacuated too often (it is already unlikely with the base algorithm), so there will be a lot less copying. One difficulty remains however: the pause times. It would probably be necessary to adopt Immix to a (semi-)incremental style to get the same pause times as with the current GC. Benedikt ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Desktop GUI toolkits - current state of the art?
Hi,
As Jacques said, lablgtk's api is close to gtk's one. I also believe
that was the best solution/approach. Binding that many C functions to
ocaml is already hard enough (not that it could be made easier, the
difficulty lies in the number of functions).
The drawback is of course that writing code using lablgtk is almost as
verbose as writing it directly in C with gtk.
Something nice would probably be to share more extensions and wrappers
around lablgtk. I've noticed Maxence Guesdon had made some available as
stand-alone libraries but I'm not aware of others. Or maybe they're
scattered around and it's hard to find them.
As far as I'm concerned I've started experimenting with the concept of
"tiling" (as used by tiling window managers) and zippers of horizontal
and vertical boxes. That's pretty much what xmonad (window manager
written in haskell) does. The zipper allows to nicely track the
"current" widget.
Next in my plans is a wrapper around treeviews/listviews and gtknotebook
to map a set of widgets to a list or tabs.
And, a last (long) point, a few months ago, I asked on this list about
lablgtk and FRP; I ended up doing something myself. It turned out that
my "lablgtk-react" is something like 50 lines of code. It's really
small and there wasn't much work, once you knew the guts of lablgtk and
gtk that is.
GTK defines properties and signals. Signals are regular "something
happened"-messages and properties are values stored inside objets. Each
property also defines a "${prop_name}::notify" signal that is emitted
each time the property is modified. This is unfortunately not exposed
through lablgtk but the connect_by_name function is enough.
Now, you may wonder whether FRP is *that* nice to use. One of the nicest
thing imho is the ability to use "fold":
let zipper = React.E.fold (zipper x config t) Zipper.empty tabs in
This means it's possible to move away from imperative data structures
with all their disadvantages.
There is currently one issue however: the API is quite bad.
install_sgn_event Entry.S.activate address_bar.as_e Signal.apply1
address_bar.activate
(* Entry.S.activate is emitted by a text entry upon pressing Return
* address_bar.as_e(ntry) returns the 'Gtk.entry Gtk.obj' because
* its's not possible (yet) to use the object layer here
* address_bar.activate is a potential previous signal handler for
* active, we'd uninstall it before install another one *)
Ideally, it'll become something like:
address_bar#react#activate#event
If you want to have a look at the module, I've put it on vpaste.net[1].
It's a bit old and several things have been changed but it still shows
how things are done.
[1] http://vpaste.net/Vrukn?
--
Adrien Nader
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] OCaml GC [was Is OCaml fast?]
I see. Yes, that sounds like a great idea. How well does Immix cope with high allocation rates of short-lived objects? Been a while since I read the Immix paper... Cheers, Jon. > -Original Message- > From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- > boun...@yquem.inria.fr] On Behalf Of Benedikt Meurer > Sent: 28 November 2010 20:00 > To: caml-list@yquem.inria.fr > Subject: Re: [Caml-list] OCaml GC [was Is OCaml fast?] > > > On Nov 28, 2010, at 20:40 , Jon Harrop wrote: > > > I don't understand why this would help here though. Wouldn't that > help when a long-lived structure was single large block but, in this > case, the long-lived structure is a tree composed of many small heap- > allocated blocks and, therefore, they would undergo the same wasteful > "allocate in young only to be copied to old" pathological behaviour? > > There is no "young" and no "old" in this scheme. There are two > different heaps, one for large objects, one for small (probably 2-8k > max object size, so not really small in the sense of OCaml). The small > area is managed by Immix, which avoids copying of long-lived objects if > they are allocated together with other long-lived objects (likely), or > if not evacuates a set of probably related objects to a single chunk > (this is somewhat dependent on the evacuation strategy, which will be > differnt for OCaml compared to Java), further improving locality. There > are simple heuristics to ensure that an object is not evacuated too > often (it is already unlikely with the base algorithm), so there will > be a lot less copying. One difficulty remains however: the pause times. > It would probably be necessary to adopt Immix to a (semi-)incremental > style to get the same pause times as with the current GC. > > Benedikt > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Is OCaml fast?
Le 28/11/2010 19:17, oli...@first.in-berlin.de a écrit : > On Sat, Nov 27, 2010 at 04:58:55PM +0100, Christophe Raffalli wrote: >> Hello, >>> To the extent that this rule is the same for all languages and that most >>> languages on the shootout are also garbage collected, I think OCaml's >>> problem with this benchmark do point at a weakness of the current >>> GC code. >> This is untrue ... the bintree example, is just bad in OCaml because the >> default >> value of the minor heap size is the correct value for reactive programs >> where you want fast minor GC slice, because they interrupt the program ... > [...] > > And if your program contains both kinds of functionality? > What possible solution would you recommend? Changing the value of the minor heap size at runtime ... There is no pb with this ... > > > Ciao, >Oliver > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs -- Christophe Raffalli Universite de Savoie Batiment Le Chablais, bureau 21 73376 Le Bourget-du-Lac Cedex tel: (33) 4 79 75 81 03 fax: (33) 4 79 75 87 42 mail: christophe.raffa...@univ-savoie.fr www: http://www.lama.univ-savoie.fr/~RAFFALLI - IMPORTANT: this mail is signed using PGP/MIME At least Enigmail/Mozilla, mutt or evolution can check this signature. The public key is stored on www.keyserver.net - signature.asc Description: OpenPGP digital signature ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
