gildor changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | OCaml 3.12.1 http://bit.ly/nNVIVH
buriedhead has joined #ocaml
smerz has quit [Quit: Ex-Chat]
<NaCl> adrien: haha
<NaCl> Is there any way to slice a BatVect?
<thelema> NaCl: sub?
<NaCl> yes!
<thelema> same as array
<NaCl> I didn't know that existed!
<thelema> vect is good, vect is wise
<NaCl> what tends to be more efficient, tail recursion or loops?
<NaCl> in ocaml, anyway
<companion_cube> they are compiled the same
<companion_cube> afaik
<NaCl> You monster!
<companion_cube> No, me cube.
<orbitz> I should hope they are the same since if recursion is efficient it's so trivial to compile a loop into a recursive call
lamawithonel_ has quit [Remote host closed the connection]
philtor has joined #ocaml
<NaCl> thelema: Array.sub and Vect.sub have different signatures
<NaCl> thelema: is that intentional?
buriedhead has quit [Ping timeout: 240 seconds]
<ecc> I've written an ocamlsdl app that needs to specify some window manager hints. Is there any way to do it besides writing a C stub?
oriba_ has joined #ocaml
<NaCl> ecc: there are bindings to xlib out there, but I'm not exactly sure they'll do what you want
<ecc> I can't even see how to get the low-level info (like X window id, display connection, etc.) via the ocamlsdl interface
oriba has quit [Ping timeout: 240 seconds]
<NaCl> :/
buriedhead has joined #ocaml
roconnor_ has quit [Ping timeout: 255 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
emmanuel_ has joined #ocaml
emmanuel_ has quit [Read error: Connection reset by peer]
buriedhead has quit [Read error: Connection reset by peer]
dsheets has quit [Ping timeout: 244 seconds]
dsheets has joined #ocaml
philtor has quit [Ping timeout: 240 seconds]
oriba_ has quit [Quit: oriba_]
emmanuelux has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
ulfdoz has quit [Ping timeout: 240 seconds]
dsheets has quit [Ping timeout: 240 seconds]
dsheets has joined #ocaml
philtor has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
philtor has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
cago has joined #ocaml
edwin has joined #ocaml
dsheets has quit [Ping timeout: 248 seconds]
dsheets has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
ttamttam has joined #ocaml
BiDOrD has joined #ocaml
BiDOrD_ has quit [Ping timeout: 255 seconds]
Cyanure has joined #ocaml
<adrien> is there no tool to generate a C header file from ocaml type definitions?
_andre has joined #ocaml
<adrien> having to use indices for all the macros is simply too brittle
<flux> maybe you could at least write all the stuff in the same file, and generate the .ml+.h-files from it with a preprocessor?
newbie26 has joined #ocaml
<adrien> my current issue is rather that C stubs are quite unreadable and typos are quite likely
<flux> it's too bad nobody (myself included ;)) seems to have the energy and the mind power to solve these problems once and for all :)
<adrien> might try it some day; with the standalon ecamlp4 parser, it shouldn't be too hard
<flux> until a case you hadn't considered comes along ;)
<adrien> yup ='(
<newbie26> I am writing a parser in lex and yacc. What does `fun i -> Parser.IF i` construct mean?
<adrien> but I think that something like "type t = { foo : int; bar : int }" -> #define T_FOO 0, #define T_BAR 1
<adrien> would already be nicer
<adrien> (I need a dice to find out how many new bugs there are in the modified C stubs)
<flux> newbie26, that is an expression of a function that accepts a value and returns the same value wrapped into a datatype constructor Parser.IF
<newbie26> @flux somethi9ng like a type cast?
ulfdoz has joined #ocaml
buriedhead has joined #ocaml
<flux> newbie26, not really
<flux> Parser.IF is a like a case of a tagged union
<flux> or, it can be just a single constructor, in which case it is just tagging it with that name. however, given that name, I think it's one of multiple cases.
<newbie26> @flux Thanks a lot! I think I need to RTFM more on this.
buriedhead has quit [Ping timeout: 252 seconds]
newbie26 has quit [Quit: Page closed]
asmanur1 has joined #ocaml
asmanur has quit [Ping timeout: 260 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
<ttamttam> adrien: ping
<adrien> ttamttam: pong
<ttamttam> Did you already check odll?
<ttamttam> It did not evolve, but was interesting.
<adrien> I actually did but that was years ago and had forgotten about it
<adrien> I'll have to try it, thanks
<ttamttam> If I remember correctly, it was generating a DLL from a module.
<ttamttam> I don't think it will work out of the box.
<adrien> "Simply run ODLL with you CMA/CMXA and one or several CMI interfaces"
<ttamttam> But it is some OCaml versions back.
<ttamttam> And using com
<ttamttam> compiler code to analyse modules.
<ttamttam> → should certainly be adapted
<adrien> it won't be useful for my current (as in "*right* now") but it could be useful for yypkg
<adrien> current projects*
buriedhead has joined #ocaml
Xizor has joined #ocaml
letrec has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
dsheets has quit [Read error: Connection reset by peer]
dsheets has joined #ocaml
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
<Kakadu> Qrntzz: hi!
<Kakadu> Does anybody has cygwin nearby?
<Kakadu> can you call `grep stack_t /usr/include/* -r` ?
<f[x]> Kakadu, nothing
<Kakadu> f[x]: I suppose that you'll fail to compile lwt on cygwin :D
* f[x] dunno
buriedhead has joined #ocaml
<thelema> NaCl: unlikely - I'll fix
avsm has joined #ocaml
<thelema> NaCl: ah, it was done for ease of implementation
buriedhead has quit [Ping timeout: 268 seconds]
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
buriedhead has joined #ocaml
emmanuelux has joined #ocaml
lamawithonel has joined #ocaml
Kakadu has quit [Quit: Page closed]
roconnor_ has joined #ocaml
roconnor_ is now known as roconnor
oriba has joined #ocaml
ikaros has joined #ocaml
<NaCl> thelema: I noticed a few interface differences between DynArray and Array and other types as well.
<NaCl> And that DynArray was in some places 2x faster than Vect
<thelema> dynarray has the advantage that it's not chunked like vect, but I'm a little surprised at 2x faster
<thelema> (vect is a tree of short arrays)
Xizor has quit []
<thelema> NaCl: let me know the other interface differences; batteries is going through a "great standardization" right about now
ankit9 has quit [Read error: Connection reset by peer]
oriba has quit [Quit: oriba]
Snark has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
<hcarty> thelema: Which is more important in Batteries during this standardization process - consistency within Batteries, or compatibility/consistency with stdlib?
ankit9 has joined #ocaml
<NaCl> thelema: DynArray has "get" whereas everything else I've seen has "at". index_of instead of findi. No "mem".
<NaCl> thelema: thoes are the ones at the top of my head
<hcarty> NaCl: My guess is that DynArray.get is meant to match Array.get
buriedhead has joined #ocaml
<NaCl> ah
buriedhead has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
<thelema> hcarty: compatibility with stdlib is first priority, but consistency within batteries can often be achieved by extending stdlib modules
cago has left #ocaml []
buriedhead has joined #ocaml
<thelema> NaCl: only list has at... index_of is fixable, mem can be added
<thelema> NaCl: do you recall the performance problem?
<NaCl> thelema: not particularly. It just went "faster". I won't be able to profile it until tonight
philtor has joined #ocaml
<hcarty> thelema: I'm thinking along the lines of labeled arguments and raising/not raising exceptions.
<hcarty> thelema: I've been happy with the BatFoo.Exceptionless and BatFoo.Labels approach
<thelema> NaCl: ok.
<thelema> hcarty: I think batteries original modules should be exceptionless and labeled
<hcarty> thelema: I'm ok with that, it just make it harder to use Batteries with non-Batteries code.
<thelema> stdlib-extended libraries should be stdlib-compatible by default and have Exceptionless and Labels
<hcarty> thelema: Functors, for example, which expect stdlib-like modules
<hcarty> That's horribly inconsistent within Batteries
<hcarty> Why should there be that big of a difference between BatArray and BatEnum?
<thelema> hmm...
<thelema> you're right...
<thelema> functor parameters probably shouldn't be named
<thelema> err, labelled
<thelema> I think labeled arguments are very good, and should be encouraged
<thelema> exceptionless, maybe a bit less so.
<thelema> but still useful.
<thelema> I still want to have `map ~f`, and I can't have it in stdlib modules by default, but I could have it in batteries modules by default
<hcarty> thelema: I'm not sure I agree with exceptionless ... I really like the "limited gotchas" results that come from having foo : ... -> 'a option and foo_exn : ... -> 'a
<hcarty> thelema: But then every Batteries user needs to know which modules are stdlib-based and which ones aren't
<hcarty> You can't provide a functor that works across both
<hcarty> If that functor requires map, for example
<thelema> who's functorizing across code that raises exceptions?
<hcarty> No no - the labeling
<hcarty> Sorry, my exceptionless comment was an aside
<thelema> on labeling, it's trivial to strip the labels - I think I'm ok buying common label usage for some friction functorizing some uncommon needs
<hcarty> How is it trivial?
<thelema> module FOut = FIn(struct include Enum let map xs f = map ~xs ~f
<thelema> end)
<hcarty> But why is Enum different than Array?
<hcarty> That feels very unpolished
<thelema> well, for the map example, we have mappable already
<thelema> we have a module interface for it.
<hcarty> But that interface can't be applied directly to both stdlib-based and Batteries-original modules
<thelema> I agree that Enum following one style and array following another style by default feels funny. I'm still looking for better solutions...
<thelema> I'm not happy with the .Labels solution as it's not default anywhere
<hcarty> It's more work initially, but I think it's better to have .Labels and .Exceptionless everywhere, then provide Batteries, BatteriesExceptionless, BatteriesLabels
<thelema> maybe making a BatteriesL which includes all the .Labels modules will fix this
<thelema> why BatteriesExceptionless? why not default exceptionless on non-stdlib modules?
<hcarty> Or, if you prefer, Batteries = BatteriesL(abels); BatteriesNolabels = stdlib-like; BatteriesExceptionless = no exceptions
<thelema> I would like that, but it would break the stdlib backwards compatibility
<hcarty> thelema: Consistency. That's one of the benefits of using Batteries.
<thelema> To have stdlib compatibility, we have to sacrifice some consistency
<thelema> I can see better and better why core made the choices they did.
raichoo has joined #ocaml
<hcarty> thelema: I agree. If I weren't already heavily invested in using Batteries in my code I would strongly consider moving to Core now that they have opened up a bit.
<hcarty> But I don't want to give up BatIO or the pervasive *.print functions or any of the other Batteries goodies
<hcarty> If stdlib compatibility is among the top priorities, then it makes sense to have "module Batteries" be stdlib-like throughout (no default labels, raise exceptions)
<hcarty> Then, additionally, provide BatteriesSomething with labels and no exceptions, BatteriesLabels with labels and exceptions, BatteriesExceptionless with no exceptions and no labels
<hcarty> If that approach isn't taken then it makes "module Batteries" a PITA to use because every module will behave differently.
<thelema> Maybe just Batteries and BatteriesNC (not compatible - with both labels and exceptionless)
<hcarty> Or that
<thelema> we might keep .Labels and .Exceptionless for those that want to customize things themselves, but having just two toplevel interfaces to support seems better than 4
<hcarty> If Batteries.Foo always have .Labels and .Exceptionless (where necessary/appropriate) then it makes is easier for users to transition to the BatteriesNC way of thinking if they want to.
<hcarty> thelema: I agree. Two is going to be easier to keep straight than 4.
<thelema> also easier to document. Which is the next challenge...
<hcarty> thelema: In that case though, you probably want BatFoo.NC only
<hcarty> thelema: Otherwise you have BatFoo.Labels.map and BatFoo.Exceptionless.map, each with a different and incompatible signature.
<hcarty> Not to mention the BatFoo.Cap modules...
<thelema> oh yeah, can't just compose the two...
<hcarty> But of .Cap sticks around it should probably be NC-only
<hcarty> s/of/if/
<thelema> hcarty: that was my thinking for the rest of the batteries modules.
<hcarty> thelema: But if you do that with BatFoo directly then you lose consistency
<thelema> maybe `Batteries` should only extend stdlib, and `BatteriesNC` includes more fun stuff
<thelema> yes, but then the consistency problems...
<hcarty> And if BatFooA acts differently than BatFooB then it grealy increases the barrier to entry.
<thelema> I'm fine not providing *all* of batteries in backwards compatibility mode.
<thelema> (I think)
<thelema> we have to provide Enum and IO there
<hcarty> thelema: I think that anything not stdlib-like should be kept out of module Batteries if that's the approach taken
<thelema> but it's probably fine if batFingerTrees have only the advanced interface
<thelema> hmmm...
<hcarty> That would reduce the development burden - no need to have BatFoo.NC anywhere but in the stdlib-like modules
<hcarty> However, that really muddies the waters when it comes to figuring out what Batteries is
<hcarty> "Hey cool! Batteries have finger trees!"
<thelema> true. Batteries may shrink a bunch because of this.
<hcarty> "No, wait, it doesn't..."
<hcarty> "No, it does! You just need to open BatteriesNC rather than Batteries!"
<thelema> we already have that with BatteriesThreads
<hcarty> Threads changes a lot more than calling conventions.
<hcarty> There is no spooky action at a distance when going from Batteries -> BatteriesNC. There is from Batteries -> BatteriesThreads.
<thelema> true.
<thelema> I'm not too happy with the core/core_extended dichotomy, I'd prefer not to have such a split in batteries
iago has joined #ocaml
ulfdoz_ has joined #ocaml
<thelema> mainly because consistency would be even more difficult - the logical result is a separate project for each unrelated module.
<hcarty> thelema: I agree
<thelema> Enum and IO bind together batteries in a way that data structures libraries don't.
ulfdoz has quit [Read error: Operation timed out]
ulfdoz_ is now known as ulfdoz
<hcarty> thelema: Quite.
<thelema> biab
letrec has quit [Ping timeout: 244 seconds]
ttamttam has quit [Remote host closed the connection]
buriedhead has quit [Ping timeout: 252 seconds]
avsm has quit [Quit: Leaving.]
jamii has joined #ocaml
sebz has joined #ocaml
<hcarty> thelema: If BatteriesNC does happen, I vote for gasche's Ord over stdlib-like compare functions in addition to the other proposed changes.
milosn has quit [Ping timeout: 240 seconds]
<flux> soo, BatteriesNC is some unified-parameter-order-interface for Batteries?
<flux> or vice versa?
sebz has quit [Quit: Computer has gone to sleep.]
milosn has joined #ocaml
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
buriedhead has joined #ocaml
_andre has quit [Quit: o.O]
Submarine has quit [Remote host closed the connection]
buriedhead has quit [Ping timeout: 276 seconds]
mdelaney has joined #ocaml
<thelema> flux: the first one. Batteries-NotCompatible
<thelema> hcarty: yes, stdlib compare will be removed from NC
taupin has quit [Ping timeout: 268 seconds]
raichoo has quit [Quit: WeeChat 0.3.4]
Drup has joined #ocaml
jamii has quit [Ping timeout: 244 seconds]
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
<hcarty> thelema: Hooray :-)
<thelema> hcarty: I strongly approve of ord (and eq)
Ptival has joined #ocaml
<Ptival> hello, I'm having trouble linking using ocamlbuild, see http://ocaml.xelpaste.org/4353
<thelema> maybe just package(bitstring),package(bitstring.syntax)?
<Ptival> thelema: seems to be working similarly
<Ptival> (or not working)
<thelema> a large part of the problem seems to be the lack of -package foo on the compilation command
<thelema> are you doing anything in your myocamlbuild.ml file?
<Ptival> I don't have one
<thelema> hmm
<Ptival> indeed it must be the problem, since when I manually put the -package it used to work
<thelema> not having a myocamlbuild file should work with 3.12
<thelema> because of -use-ocamlfind
<thelema> ocamlfind query bitstring
<thelema> what's the result of that command?
Kakadu has quit [Quit: Konversation terminated!]
iago has quit [Quit: Leaving]
mdelaney has quit [Quit: mdelaney]
<Ptival> thelema: /usr/lib/ocaml/bistring
<thelema> ok, bitstring is installed with ocamlfind...
<thelema> filename + tag + ocamlfind package should result in -package foo
<thelema> How did you compile without that?
<thelema> maybe try `true: package(...)...
<thelema> `
<Ptival> I used to compile with
<thelema> hmm, but if it were the tags, how are you getting -linkpkg...
<Ptival> ocamlfind ocamlc -package bitstring,bitstring.syntax -syntax bitstring.syntax -linkpkg file.ml -o file
<thelema> that looks right.
<Ptival> but now I have multiple files so this does not work anymore
<thelema> change the predicate for your tags to just "true"
<Ptival> ok
<thelema> wait, which version of ocaml are you using?
<thelema> 3.12.0 or .1?
<Ptival> oh, it works
<thelema> you might be running into a 3.12.0 bug with ocamlbuild... or not
<Ptival> 3.12.1
<thelema> ok, glad it works. I usually tag based on the first part of the filename, tagging on extensions isn't needed because tags do different things for different actions
<thelema> I guess tagging *.byte doesn't work. or maybe it's that "" doesn't do globbing... hmmm
<Ptival> I don't really care about the pattern for now :)
<Ptival> true is fine with my use
<thelema> great. carry on.
<Ptival> thanks
<NaCl> So, I'm looking at making a lexer/parser. What are the advantages of using ocamlyacc/ocamllex over yacc/lex?
<thelema> NaCl: you get to use ocaml
<NaCl> I see
philtor has quit [Ping timeout: 252 seconds]
ulfdoz has quit [Ping timeout: 240 seconds]
<Drakken> Anybody know why Archimedes.Viewport.layout_borders makes the plot on the parent viewport disappear?
<Drakken> layout_borders creates several child viewports. I can write onto them, but I'm not sure what happened to the plot on the original viewport.
<thelema> Drakken: I assume you can't order things so it all works?
<Drakken> thelema I tried before the plot and after.
<thelema> maybe all plots must be child plots?
<Drakken> maybe. I can't even find a general manual on wtf a viewport exactly is.
<Drakken> I thought it was the clipping region for the plot, but I can use the viewport to display text in the margin.
sebz has joined #ocaml
<thelema> viewports are usually a combination clipping region / scaling factors for each axis
<Drakken> right
<Drakken> it just seems strange that the parent suddenly disappears.
<thelema> try two children instead of parent/child
<Drakken> what do you mean? layout_borders created five children: one for each border and one for the middle.
<thelema> ok, maybe I don't understand what's going on.
<thelema> I've still not used archimedes, despite skimming your code
<adrien> NaCl: with ocaml, you have variants and that makes ASTs much nicer to create and go through
<Drakken> I could try drawing on the center child, of course, but I'm wondering why I bothered to initialize the parent with cairo/png.
<Drakken> and whether there would be new borders in the center if I initialize that.....
<thelema> adrien: very true - Variant types are awesome for ASTs
<thelema> Drakken: I have no idea.
<Drakken> thelema that's okay. I'm posting a support request to the archimedes group.
NihilistDandy has joined #ocaml
<adrien> NaCl: C: unions + enums and switch-case vs. OCaml: variants and pattern-matching
Ptival has quit [Quit: leaving]
mdelaney has joined #ocaml
willb has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
<NaCl> adrien: If I do this in ocaml, I will have to take ownership.
* NaCl isn't sure he wants that
<thelema> how complex is the thing you're parsing?
edwin has quit [Remote host closed the connection]
<ousado> NaCl: maybe you want to take a look at a few compilers written in ocaml vs. some written in C or C++ (that'd be the alternative, right?) and base your decision on that
roconnor has quit [Ping timeout: 252 seconds]
Drup has quit [Quit: Leaving.]
ztfw has joined #ocaml
pcjoby has left #ocaml []
milosn has quit [Ping timeout: 252 seconds]
milosn has joined #ocaml
Snark has quit [Quit: Quitte]
oriba has joined #ocaml
<NaCl> thelema: simple, probably just something close to s expressions
<thelema> NaCl: it may not matter
<thelema> ocaml vs. c
<thelema> for more complex grammars, ocaml is very nice
<NaCl> I think it's just going to be glorified boolean logic
<NaCl> with some easy noncomplex way to specify certian predefined function parameters
<thelema> wait, if it's got logic, that's not so trivial.
<thelema> if it's as complex as a calculator, use ocaml.
<NaCl> kk, I'll look into it
<NaCl> I was essentially told by one of my coworkers that if I used a parser generator I'd take ownership of the thing anyway.
<adrien> mmmm
<adrien> let him do it without a parser generator and see how he manages? :P
<thelema> use ocaml and have fun with parser combinators
<NaCl> mmm
<NaCl> I'll see if the guy who asked me to do this agrees with the idea
probst has quit [Quit: probst]
<NaCl> adrien: have any idea how reliable the mysql bindings are?
<adrien> NaCl: dunno; somehow I expect them to be good but I don't know why
<adrien> you should try to see what is using them
<_habnabit> well, that assumes that anything related to mysql can be 'reliable'
<NaCl> I don't have a choice in the matter.
<NaCl> MySQL is a requirement
<_habnabit> I'm sorry
<NaCl> heh
letrec has joined #ocaml
milosn has quit [Ping timeout: 252 seconds]
mdelaney_ has joined #ocaml
mdelaney has quit [Read error: Connection reset by peer]
mdelaney_ is now known as mdelaney
Morphous_ has quit [Read error: Operation timed out]
philtor has joined #ocaml
Morphous_ has joined #ocaml
NihilistDandy has quit [Quit: Linkinus - http://linkinus.com]
<Drakken> Why are record field names added to the surrounding environment if they're not bound to anything?
<_habnabit> 'bound to anything' ?
<Drakken> hmm. I guess they're not really values. nevermind.
yroeht has quit [Ping timeout: 252 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
yroeht has joined #ocaml
letrec has quit [Ping timeout: 252 seconds]
bnwr has joined #ocaml
jlouis_ has joined #ocaml
asmanur1 has quit [*.net *.split]
bnwr_ has quit [*.net *.split]
jlouis has quit [*.net *.split]
asmanur1 has joined #ocaml
fantasticsid has joined #ocaml
emmanuelux has quit [Remote host closed the connection]
emmanuelux has joined #ocaml
emmanuelux has quit [Read error: Connection reset by peer]
* dsheets bites nails nervously waiting for OCaml Forge approval
<ousado> dsheets: hey man
<ousado> how is it?
<dsheets> hi, ousado
<dsheets> It goes.
<dsheets> I need to figure out oasis and library packaging to make consumption of my library/command super-easy even for non-OCaml'ers.
<ousado> that might be non-trivial I assume
<dsheets> I have ulex, menhir, and json-tc-js/jsonoj deps
<dsheets> the json-tc-js/jsonoj dep is the one that worries me most. i think ulex and menhir are already well-known
<ousado> json-tc-js looks interesting
<dsheets> it is very minimally different from avsm/ocaml-json-tc
mdelaney has quit [Quit: mdelaney]
<dsheets> Martin Jambon has deprecated the original lib, though, in favor of atdgen
<ousado> how hard would it be to modify that for languages other than ocaml?
<dsheets> Modify which?
<ousado> yours