Alpounet changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.1 out now! Get yours from http://caml.inria.fr/ocaml/release.html
ikaros_ has quit ["Leave the magic to Houdini"]
sporkmonger has quit []
ulfdoz_ has joined #ocaml
julm has joined #ocaml
ulfdoz has quit [Read error: 145 (Connection timed out)]
ulfdoz_ is now known as ulfdoz
Alpounet has quit ["Leaving"]
Alpounet has joined #ocaml
tmaedaZ is now known as tmaeda0
Alpounet has quit ["Leaving"]
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
mbishop_ is now known as mbishop
<c0m> define a function curry f that converts an uncurried function to a curried function
<c0m> what exactly does that mean
<c0m> converts uncurried to curried
<c0m> meaning, takes a touple and but curry the arguements?
caligula_ has joined #ocaml
<thelema> c0m: meaning takes a tupled function and returns a function that takes arguments one at a time
<c0m> hmm
<c0m> ok
<c0m> ty
NYNix has joined #ocaml
caligula__ has quit [Read error: 110 (Connection timed out)]
seanmcl has quit []
<orbitz> c0m: so like ('a * 'b -> 'c) -> 'a -> 'b -> 'c
Ringo48 has quit [Read error: 110 (Connection timed out)]
Ringo48 has joined #ocaml
f[x] has joined #ocaml
kaustuv_ has joined #ocaml
_zack has joined #ocaml
verte has joined #ocaml
kaustuv_` has quit [Read error: 110 (Connection timed out)]
hjpark has quit [Remote closed the connection]
Amorphous has quit [calvino.freenode.net irc.freenode.net]
prigaux has quit [calvino.freenode.net irc.freenode.net]
shr3kst3r has quit [calvino.freenode.net irc.freenode.net]
__marius__ has quit [calvino.freenode.net irc.freenode.net]
rwmjones has quit [calvino.freenode.net irc.freenode.net]
tarbo2 has quit [calvino.freenode.net irc.freenode.net]
prigaux has joined #ocaml
__marius__ has joined #ocaml
Amorphous has joined #ocaml
rwmjones has joined #ocaml
tarbo2 has joined #ocaml
shr3kst3r has joined #ocaml
Amorphous has quit [SendQ exceeded]
Amorphous has joined #ocaml
shr3kst3r has quit [Connection reset by peer]
<flux> hmph, my ordeal with darcs continues with an internal error (in GHC?!)
meltingwacks has joined #ocaml
Snark has joined #ocaml
munga has joined #ocaml
ikaros has joined #ocaml
_zack has quit ["Leaving."]
ikaros has quit ["Leave the magic to Houdini"]
tmaeda0 has quit [Read error: 145 (Connection timed out)]
tmaeda has joined #ocaml
ikaros has joined #ocaml
_zack has joined #ocaml
Alpounet has joined #ocaml
munga has quit [Read error: 145 (Connection timed out)]
BiDOrD has quit [Remote closed the connection]
munga has joined #ocaml
BiDOrD has joined #ocaml
munga has quit [Read error: 60 (Operation timed out)]
Anarchos has joined #ocaml
<Anarchos> i caan't build ocamlbuild with ocamlopt, i got tons of 'undefined reference'
<Anarchos> Has someone test the 'ocaml for multicore' patch ?
Yoric[DT] has joined #ocaml
schmx has quit [Read error: 110 (Connection timed out)]
julm_ has joined #ocaml
julm has quit [Read error: 60 (Operation timed out)]
schme has joined #ocaml
Alpounet has quit [Remote closed the connection]
Anarchos has quit ["Vision[0.9.7-H-090423]: i've been blurred!"]
Alpounet has joined #ocaml
konr has joined #ocaml
<konr> how can I get started with ML programming? does it have a REPL like Lisp or a compiler? What compiler/interpreter should I download on GNU/Linux?
<konr> also, should I really learn OCaml instead of ML?
<konr> (I'm reading modern compiler implementation on ML)
<schme> konr: it has a repl somewhat like lisp, yes. and a compiler.
<Alpounet> konr, launch "ocaml" in a shell
<Alpounet> => REPL
<Alpounet> the bytecode compiler is 'ocamlc'
<Alpounet> and the native compiler is 'ocamlopt'
<schme> konr: or if you're looking for sml there's .. some other one.
<schme> heh :)
<konr> interesting... so OCaml, SML and ML are different languages, right? What are their strong points? Are they the first two much different than ML?
<schme> I think ML is pretty dead. so there's SML and ocaml :)
<schme> When I read ML I think either family or SML. but that's me.
<schme> and other random pages google gave he
<schme> me
<konr> excelent!
<konr> Thanks for the help, schme and Alpounet!
<Alpounet> konr, which distro are you running ?
<konr> Alpounet: debian
<Alpounet> if it is a widespread enough one, you should have an "ocaml" package, with the latest version of the REPL & compiler.
<Alpounet> yeah, the Debian-OCaml team is the most active I think, so there'll be no problem ;-)
<konr> awesome!
<Yoric[DT]> Essentially, ML is the "historical" implementation.
<Yoric[DT]> Both OCaml and SML go much farther.
<Yoric[DT]> ... and are maintained
<Yoric[DT]> Then there are plenty of other variants (JoCaml, OCamlDuce, PolyML, and now F#...)
bluestorm has joined #ocaml
<flux> screenshot through your webkit bindings?
<flux> ..because I've seen the page before ;)
<Camarade_Tux> now, let's try a Gc.full_major and see how it segfaults :)
<Camarade_Tux> flux: yeah, throught the webkit-gtk bindings ;)
<flux> camarade_tux, will you be surprised if it doesn't?
<flux> camarade_tux, next make it surf random pages over night and see what happens :)
<Camarade_Tux> the code: http://vpaste.net/KActW? (class web_view and let web_view shouldn't be in this file so the code is 12 lines long without the open directives)
<Camarade_Tux> flux: it doesn't really interact nicely with the gc right now, at least I don't think so
<Camarade_Tux> well, it could survive but if it does, there are still dozens of functions that could make it crash :)
<Camarade_Tux> oh, I should put window borders back when I take such screenshots
<kaustuv_> konr: Modern Compiler Implementation in ML uses Standard ML
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
verte has quit ["~~~ Crash in JIT!"]
<Camarade_Tux> and the reason I wanted webkit-gtk: http://omploader.org/vMml1ag/sunspider.png (on a not-so-good cpu, try to get better results at http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html :) ) [these are micro benchmarks, set you cpu governor to "performance" or anything that doesn't let it lower its frequency]
seanmcl has joined #ocaml
ikaros has quit ["Leave the magic to Houdini"]
julm_ is now known as julm
bluestorm has quit ["Leaving"]
* thelema is reading how ruby's GC was modified to be CoW friendly
<Camarade_Tux> thelema: have a link? =)
<thelema> http://www.rubyenterpriseedition.com/faq.html#what_is_this <- the list of links at the end of this entry
hsuh has joined #ocaml
hsuh has left #ocaml []
<Camarade_Tux> thanks, some interesting stuff
<mfp> thelema: IIRC it essentially boils down to using a separate table to mark objects, therefore avoiding page dirtying
tmaeda is now known as tmaedaZ
tmaedaZ is now known as tmaeda
<Camarade_Tux> I remember how I was hit by that, GC.compact would make the program use more memory :)
<mfp> (keep in mind that Ruby's GC doesn't compact or move objects, it's a plain mark & sweep)
stan_ has joined #ocaml
Hadaka has quit ["leaving"]
stan_ has quit [Client Quit]
<thelema> mfp: understood. Major compactions in ocaml *require* dirtying pages
<thelema> but the idea that GC can play well with CoW isn't bad...
<mfp> well, I suppose you could set max_overhead to 1_000_000 and disable compaction
<mfp> leaving marking as the only pb
<kaustuv_> compaction has a higher chance of moving newer data which tends to be dirty anyway
<kaustuv_> (recall that the GC does not reorder data)
<thelema> Is there a TODO list for OCaml?
<thelema> some wiki page somewhere?
<mfp> kaustuv_: do you think making the GC COW-friendly with a bit set would be worth the ~6(or 3)% space overhead?
<kaustuv_> I think it's a lot of work with likely very little gain. In fact, I have tried advocating changing the block representation to have a bitset pointing pointers in the blocks. This would have a far larger overhead, but it would potentially improve performance greatly
<kaustuv_> (for one, we'd have unboxed ints of all sizes and unboxed floats in heterogenous blocks)
<mfp> variable size headers hmm
<mfp> records/constructors with more than 31(63) fields should be rare though
<kaustuv_> Yeah, it's arrays that potentially screws this up.
<mfp> arrays? why?
<mfp> with them being homogeneous, isn't a single bit needed to indicate whether everything is/can be a pointer or not?
<mfp> which makes me think that the bitset could bring the same benefit as pointer tagging
<mfp> with some monomorphic option types being unboxed and such
seanmcl has quit []
<mfp> but I remembed xleroy saying that "clever" non-uniform constructor representation was discarded because it didn't help enough performance-wise to make up for the complexity/loss in regularity
<kaustuv_> Well, I suppose arrays are find actually. I was worried about the tag casing in Array.create, but you're right, whatever the result is of Array.create, it's homogeneous
<kaustuv_> s/find/fine/
<kaustuv_> Well, it would still be uniform in the sense of no rewriting of datatype definitions. It would potentially be more uniform that now because we'd have no need of string_tag or double_array_tag any more
<mfp> are there any free bits left in the header now?
<kaustuv_> Not as far as I know
<mfp> a "no pointers in this block" would help the GC when scanning large arrays
<mfp> :-|
<mfp> + bit
<mfp> [ wosize | color | tag ]
<kaustuv_> It might almost be better to maintain such a table somewhere else. I believe there will be some GC changes in 3.12 and some small amount of that involves caching more information.
<mfp> ah, there's Double_array_tag > No_scan_tag to skip float arrays, but no such thing for e.g. int arrays (tag = 0)
<flux> mfp, should be easy to fix?
<mfp> or ints records, etc.
<flux> hm, actually, no?
<flux> actually, how does that tag get into its place?
<flux> I suppose it works because floats are boxed?
<flux> (and array constructors can figure that out dynamically)
<mfp> flux: it's written at the time the block is allocated
<flux> so it would need some special compiler magic
<mfp> it seems it'd amount to just adding a tag (246 = Lazy_tag seems to be the lowest reserved one, so 245) for record/arr with no pointers
<mfp> but then the array get/set check would become slower
<flux> mfp, but the problem is adding the tag is the problem
<flux> uh, redundant phrase is redundant :)
<mfp> it'd only work on monomorphic functions which know the type of the array
<mfp> or record
<flux> but the compiler would need to do it
<mfp> yes
<flux> pass a secret parameter to Array.init/make
<flux> or patch the resulting value
<mfp> the same way it does for anything vs. float arrays
<flux> but float arrays can be handled by Array-module, no?
<flux> because it can just look at the tag of the default value argument
schme has quit [Read error: 110 (Connection timed out)]
<mfp> yes, it just uses the polymorphic code
<flux> and float array literals are different
<mfp> hmm there must be some magic in Array.make to determine the tag, yes
<kaustuv_> Yes, it's a C function that looks at the tag of the init value
<mfp> I see, caml_make_vect
<flux> yeah, if (Is_block(init) && Is_in_value_area(init) && Tag_val(init) == Double_tag) { ..
<flux> (just to prove I was already there ;-))
<mfp> so the hypothetic No_pointer_tag would be set there
<flux> hmm
<flux> so how would it work?
<flux> I wonder if it could work dynamically
<flux> the sizes of blocks cannot change, right?
<mfp> if the value is immediate (int, char, bool), use No_pointer_tag
<flux> hmph, but no, the contents could change from untagged to tagged
<mfp> but the polymorphic set/get problem remains
<mfp> problem = slower tag casing
<flux> because of floats it already needs to do some casing?
* mfp realizes he needs to eat something
<mfp> flux: yes, it already generates code to verify if the tag is Double_array_tag
<mfp> would have to add another branch
<flux> benchmark, benchmark, benchmark :)
<mfp> = potential ~15 cycle penalty on miss :-|
<flux> predictors are that bad?-)
<mfp> hmm needs not be much slower in fact
<mfp> I'm being silly
<mfp> if the tag is not Double_array_tag, the same code is OK for both pointer and non-pointer
<mfp> so no cost whatsoever on set/get
<mfp> only slightly slower branching in marking phase, easily offset by large integer arrays/records being skipped
<flux> I wonder how common such thing sare
<flux> but then again, when you have them, the win can be significant
<flux> ..I guess atleast, without benchmarking..
<thelema> The purpose of Ruby's CoW-friendly GC is for web servers to be able to fork easily with comparable memory overhead to forking C programs
<thelema> I guess ocaml might benefit from this with the efforts to make typed web servers in ocaml
<flux> I suppose in ocaml you might want to run multiple threads, though, or then you go the cgi-bin route
<flux> although it is possible to use mod_caml too, which would gain from the same optimization (if there is anything to gain)
Ched has joined #ocaml
ched_ has quit [Read error: 113 (No route to host)]
BiDOrD has quit [Client Quit]
slash_ has joined #ocaml
jeddhaberstro has joined #ocaml
<mfp> flux: in fact, marking would be strictly faster, you just need to use a tag > No_scan_tag, and shift existing tags <- clearer thinking with some more glucose in the bloodstream
ikaros has joined #ocaml
<mfp> which also means that this is trivially implementable without any changes to the code generator, just in mlvalues.h (tags) and caml_make_vect
slash__ has joined #ocaml
<mfp> thelema: the reason why they need fork in Ruby (esp. in Rails) is that loading the environment is very slow (up to several seconds)
<mfp> also, multiple processes needed because Rails was historically not thread-safe, and request processing blocked
slash_ has quit [calvino.freenode.net irc.freenode.net]
Ched has quit [calvino.freenode.net irc.freenode.net]
tmaeda has quit [calvino.freenode.net irc.freenode.net]
brendan has quit [calvino.freenode.net irc.freenode.net]
infoe has quit [calvino.freenode.net irc.freenode.net]
<mfp> so you needed extra processes to handle requests concurrently
slash__ is now known as slash_
Modius has quit [Read error: 110 (Connection timed out)]
Ched has joined #ocaml
tmaeda has joined #ocaml
brendan has joined #ocaml
infoe has joined #ocaml
brendan has quit [calvino.freenode.net irc.freenode.net]
Ched has quit [calvino.freenode.net irc.freenode.net]
infoe has quit [calvino.freenode.net irc.freenode.net]
tmaeda has quit [calvino.freenode.net irc.freenode.net]
Ched has joined #ocaml
tmaeda has joined #ocaml
brendan has joined #ocaml
infoe has joined #ocaml
schme has joined #ocaml
brendan has quit [calvino.freenode.net irc.freenode.net]
Ched has quit [calvino.freenode.net irc.freenode.net]
infoe has quit [calvino.freenode.net irc.freenode.net]
tmaeda has quit [calvino.freenode.net irc.freenode.net]
_zack has quit ["Leaving."]
smimram has joined #ocaml
tmaeda has joined #ocaml
smimou_ has quit [Read error: 113 (No route to host)]
Ched has joined #ocaml
brendan has joined #ocaml
infoe has joined #ocaml
Narrenschiff has joined #ocaml
jeddhaberstro has quit [Read error: 60 (Operation timed out)]
ulfdoz_ has joined #ocaml
jeddhaberstro has joined #ocaml
ulfdoz has quit [Read error: 110 (Connection timed out)]
ulfdoz_ is now known as ulfdoz
Snark has quit ["Ex-Chat"]
seanmcl has joined #ocaml
munga has joined #ocaml
kaustuv_` has joined #ocaml
seanmcl has quit []
kaustuv_ has quit [Read error: 145 (Connection timed out)]
seanmcl has joined #ocaml
tmaeda is now known as tmaedaZ
Narrenschiff has quit []
Smerdyakov has joined #ocaml
munga has quit [Read error: 60 (Operation timed out)]
ztfw has joined #ocaml
f[x] has quit [Read error: 145 (Connection timed out)]
onigiri has joined #ocaml
seanmcl has quit []
Yoric[DT] has quit ["Ex-Chat"]
slash_ has quit ["Lost terminal"]
ikaros has quit ["Leave the magic to Houdini"]
_unK has joined #ocaml
Alpounet has quit ["Leaving"]
seanmcl has joined #ocaml
Alpounet has joined #ocaml
Alpounet has quit [Client Quit]
valross has joined #ocaml