Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
tree: 77723be902
Fetching contributors…

Cannot retrieve contributors at this time

258 lines (257 sloc) 20.241 kb
02:18:40 <NaCl> adrien: haha
02:18:56 <NaCl> Is there any way to slice a BatVect?
02:19:06 <thelema> NaCl: sub?
02:19:22 <NaCl> yes!
02:19:32 <thelema> same as array
02:19:54 <NaCl> I didn't know that existed!
02:20:11 <thelema> vect is good, vect is wise
02:21:51 <NaCl> what tends to be more efficient, tail recursion or loops?
02:21:54 <NaCl> in ocaml, anyway
02:22:07 <companion_cube> they are compiled the same
02:22:26 <companion_cube> afaik
02:22:32 <NaCl> You monster!
02:23:55 <companion_cube> No, me cube.
02:31:20 <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
03:24:13 <NaCl> thelema: Array.sub and Vect.sub have different signatures
03:24:21 <NaCl> thelema: is that intentional?
03:40:09 <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?
03:43:28 <NaCl> ecc: there are bindings to xlib out there, but I'm not exactly sure they'll do what you want
03:44:22 <ecc> I can't even see how to get the low-level info (like X window id, display connection, etc.) via the ocamlsdl interface
03:44:55 <NaCl> :/
09:59:04 <adrien> is there no tool to generate a C header file from ocaml type definitions?
09:59:29 <adrien> having to use indices for all the macros is simply too brittle
10:04:37 <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?
10:08:22 <adrien> my current issue is rather that C stubs are quite unreadable and typos are quite likely
10:09:19 <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 :)
10:11:12 <adrien> might try it some day; with the standalon ecamlp4 parser, it shouldn't be too hard
10:11:32 <flux> until a case you hadn't considered comes along ;)
10:12:36 <adrien> yup ='(
10:13:01 <newbie26> I am writing a parser in lex and yacc. What does `fun i -> Parser.IF i` construct mean?
10:13:32 <adrien> but I think that something like "type t = { foo : int; bar : int }" -> #define T_FOO 0, #define T_BAR 1
10:13:37 <adrien> would already be nicer
10:15:07 <adrien> (I need a dice to find out how many new bugs there are in the modified C stubs)
10:15:14 <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
10:17:34 <newbie26> @flux somethi9ng like a type cast?
10:33:09 <flux> newbie26, not really
10:33:25 <flux> Parser.IF is a like a case of a tagged union
10:33:57 <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.
10:35:56 <newbie26> @flux Thanks a lot! I think I need to RTFM more on this.
11:23:38 <ttamttam> adrien: ping
11:23:53 <adrien> ttamttam: pong
11:24:16 <ttamttam> Did you already check odll?
11:24:56 <ttamttam> It did not evolve, but was interesting.
11:25:21 <adrien> I actually did but that was years ago and had forgotten about it
11:25:51 <adrien> I'll have to try it, thanks
11:25:53 <ttamttam> If I remember correctly, it was generating a DLL from a module.
11:26:11 <ttamttam> I don't think it will work out of the box.
11:26:13 <adrien> "Simply run ODLL with you CMA/CMXA and one or several CMI interfaces"
11:26:39 <ttamttam> But it is some OCaml versions back.
11:26:50 <ttamttam> And using com
11:27:01 <ttamttam> compiler code to analyse modules.
11:27:35 <ttamttam> → should certainly be adapted
11:29:21 <adrien> it won't be useful for my current (as in "*right* now") but it could be useful for yypkg
11:30:12 <adrien> current projects*
12:36:35 <Kakadu> Qrntzz: hi!
12:38:08 <Kakadu> Does anybody has cygwin nearby?
12:39:02 <Kakadu> can you call `grep stack_t /usr/include/* -r` ?
12:44:38 <f[x]> Kakadu, nothing
12:45:15 <Kakadu> f[x]: I suppose that you'll fail to compile lwt on cygwin :D
12:45:51 * f[x] dunno
12:56:13 <thelema> NaCl: unlikely - I'll fix
12:58:04 <thelema> NaCl: ah, it was done for ease of implementation
14:52:31 <NaCl> thelema: I noticed a few interface differences between DynArray and Array and other types as well.
14:52:46 <NaCl> And that DynArray was in some places 2x faster than Vect
15:01:06 <thelema> dynarray has the advantage that it's not chunked like vect, but I'm a little surprised at 2x faster
15:01:20 <thelema> (vect is a tree of short arrays)
15:10:16 <thelema> NaCl: let me know the other interface differences; batteries is going through a "great standardization" right about now
15:33:03 <hcarty> thelema: Which is more important in Batteries during this standardization process - consistency within Batteries, or compatibility/consistency with stdlib?
15:37:52 <NaCl> thelema: DynArray has "get" whereas everything else I've seen has "at". index_of instead of findi. No "mem".
15:37:57 <NaCl> thelema: thoes are the ones at the top of my head
15:39:30 <hcarty> NaCl: My guess is that DynArray.get is meant to match Array.get
15:40:12 <NaCl> ah
16:05:22 <thelema> hcarty: compatibility with stdlib is first priority, but consistency within batteries can often be achieved by extending stdlib modules
16:06:23 <thelema> NaCl: only list has at... index_of is fixable, mem can be added
16:06:32 <thelema> NaCl: do you recall the performance problem?
16:08:49 <NaCl> thelema: not particularly. It just went "faster". I won't be able to profile it until tonight
16:12:46 <hcarty> thelema: I'm thinking along the lines of labeled arguments and raising/not raising exceptions.
16:13:21 <hcarty> thelema: I've been happy with the BatFoo.Exceptionless and BatFoo.Labels approach
16:13:39 <thelema> NaCl: ok.
16:14:03 <thelema> hcarty: I think batteries original modules should be exceptionless and labeled
16:14:34 <hcarty> thelema: I'm ok with that, it just make it harder to use Batteries with non-Batteries code.
16:15:00 <thelema> stdlib-extended libraries should be stdlib-compatible by default and have Exceptionless and Labels
16:15:01 <hcarty> thelema: Functors, for example, which expect stdlib-like modules
16:15:17 <hcarty> That's horribly inconsistent within Batteries
16:15:35 <hcarty> Why should there be that big of a difference between BatArray and BatEnum?
16:15:47 <thelema> hmm...
16:15:53 <thelema> you're right...
16:16:36 <thelema> functor parameters probably shouldn't be named
16:16:46 <thelema> err, labelled
16:17:18 <thelema> I think labeled arguments are very good, and should be encouraged
16:17:36 <thelema> exceptionless, maybe a bit less so.
16:17:43 <thelema> but still useful.
16:18:26 <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
16:18:33 <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
16:18:58 <hcarty> thelema: But then every Batteries user needs to know which modules are stdlib-based and which ones aren't
16:19:07 <hcarty> You can't provide a functor that works across both
16:19:17 <hcarty> If that functor requires map, for example
16:19:23 <thelema> who's functorizing across code that raises exceptions?
16:19:34 <hcarty> No no - the labeling
16:20:10 <hcarty> Sorry, my exceptionless comment was an aside
16:20:12 <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
16:20:30 <hcarty> How is it trivial?
16:21:05 <thelema> module FOut = FIn(struct include Enum let map xs f = map ~xs ~f
16:21:07 <thelema> end)
16:21:25 <hcarty> But why is Enum different than Array?
16:21:39 <hcarty> That feels very unpolished
16:21:44 <thelema> well, for the map example, we have mappable already
16:21:51 <thelema> we have a module interface for it.
16:22:21 <hcarty> But that interface can't be applied directly to both stdlib-based and Batteries-original modules
16:22:22 <thelema> I agree that Enum following one style and array following another style by default feels funny. I'm still looking for better solutions...
16:22:41 <thelema> I'm not happy with the .Labels solution as it's not default anywhere
16:23:11 <hcarty> It's more work initially, but I think it's better to have .Labels and .Exceptionless everywhere, then provide Batteries, BatteriesExceptionless, BatteriesLabels
16:23:15 <thelema> maybe making a BatteriesL which includes all the .Labels modules will fix this
16:24:03 <thelema> why BatteriesExceptionless? why not default exceptionless on non-stdlib modules?
16:24:05 <hcarty> Or, if you prefer, Batteries = BatteriesL(abels); BatteriesNolabels = stdlib-like; BatteriesExceptionless = no exceptions
16:24:26 <thelema> I would like that, but it would break the stdlib backwards compatibility
16:24:31 <hcarty> thelema: Consistency. That's one of the benefits of using Batteries.
16:25:07 <thelema> To have stdlib compatibility, we have to sacrifice some consistency
16:25:39 <thelema> I can see better and better why core made the choices they did.
16:26:31 <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.
16:26:54 <hcarty> But I don't want to give up BatIO or the pervasive *.print functions or any of the other Batteries goodies
16:27:43 <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)
16:28:33 <hcarty> Then, additionally, provide BatteriesSomething with labels and no exceptions, BatteriesLabels with labels and exceptions, BatteriesExceptionless with no exceptions and no labels
16:29:30 <hcarty> If that approach isn't taken then it makes "module Batteries" a PITA to use because every module will behave differently.
16:30:11 <thelema> Maybe just Batteries and BatteriesNC (not compatible - with both labels and exceptionless)
16:30:26 <hcarty> Or that
16:31:10 <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
16:31:42 <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.
16:31:55 <hcarty> thelema: I agree. Two is going to be easier to keep straight than 4.
16:32:06 <thelema> also easier to document. Which is the next challenge...
16:32:07 <hcarty> thelema: In that case though, you probably want BatFoo.NC only
16:32:37 <hcarty> thelema: Otherwise you have BatFoo.Labels.map and BatFoo.Exceptionless.map, each with a different and incompatible signature.
16:32:50 <hcarty> Not to mention the BatFoo.Cap modules...
16:32:57 <thelema> oh yeah, can't just compose the two...
16:33:07 <hcarty> But of .Cap sticks around it should probably be NC-only
16:33:15 <hcarty> s/of/if/
16:33:26 <thelema> hcarty: that was my thinking for the rest of the batteries modules.
16:33:55 <hcarty> thelema: But if you do that with BatFoo directly then you lose consistency
16:34:01 <thelema> maybe `Batteries` should only extend stdlib, and `BatteriesNC` includes more fun stuff
16:34:08 <thelema> yes, but then the consistency problems...
16:34:28 <hcarty> And if BatFooA acts differently than BatFooB then it grealy increases the barrier to entry.
16:35:25 <thelema> I'm fine not providing *all* of batteries in backwards compatibility mode.
16:35:33 <thelema> (I think)
16:35:52 <thelema> we have to provide Enum and IO there
16:36:11 <hcarty> thelema: I think that anything not stdlib-like should be kept out of module Batteries if that's the approach taken
16:36:15 <thelema> but it's probably fine if batFingerTrees have only the advanced interface
16:36:44 <thelema> hmmm...
16:36:53 <hcarty> That would reduce the development burden - no need to have BatFoo.NC anywhere but in the stdlib-like modules
16:37:15 <hcarty> However, that really muddies the waters when it comes to figuring out what Batteries is
16:37:33 <hcarty> "Hey cool! Batteries have finger trees!"
16:37:35 <thelema> true. Batteries may shrink a bunch because of this.
16:37:39 <hcarty> "No, wait, it doesn't..."
16:37:58 <hcarty> "No, it does! You just need to open BatteriesNC rather than Batteries!"
16:38:10 <thelema> we already have that with BatteriesThreads
16:38:32 <hcarty> Threads changes a lot more than calling conventions.
16:39:45 <hcarty> There is no spooky action at a distance when going from Batteries -> BatteriesNC. There is from Batteries -> BatteriesThreads.
16:39:54 <thelema> true.
16:41:22 <thelema> I'm not too happy with the core/core_extended dichotomy, I'd prefer not to have such a split in batteries
16:41:57 <thelema> mainly because consistency would be even more difficult - the logical result is a separate project for each unrelated module.
16:42:14 <hcarty> thelema: I agree
16:42:40 <thelema> Enum and IO bind together batteries in a way that data structures libraries don't.
16:44:28 <hcarty> thelema: Quite.
16:46:01 <thelema> biab
17:52:53 <hcarty> thelema: If BatteriesNC does happen, I vote for gasche's Ord over stdlib-like compare functions in addition to the other proposed changes.
18:02:33 <flux> soo, BatteriesNC is some unified-parameter-order-interface for Batteries?
18:02:57 <flux> or vice versa?
19:33:36 <thelema> flux: the first one. Batteries-NotCompatible
19:34:10 <thelema> hcarty: yes, stdlib compare will be removed from NC
20:05:45 <hcarty> thelema: Hooray :-)
20:07:17 <thelema> hcarty: I strongly approve of ord (and eq)
20:14:28 <Ptival> hello, I'm having trouble linking using ocamlbuild, see http://ocaml.xelpaste.org/4353
20:15:25 <thelema> maybe just package(bitstring),package(bitstring.syntax)?
20:17:11 <Ptival> thelema: seems to be working similarly
20:17:22 <Ptival> (or not working)
20:17:41 <thelema> a large part of the problem seems to be the lack of -package foo on the compilation command
20:17:52 <thelema> are you doing anything in your myocamlbuild.ml file?
20:17:58 <Ptival> I don't have one
20:18:36 <thelema> hmm
20:18:40 <Ptival> indeed it must be the problem, since when I manually put the -package it used to work
20:19:00 <thelema> not having a myocamlbuild file should work with 3.12
20:19:09 <thelema> because of -use-ocamlfind
20:19:33 <thelema> ocamlfind query bitstring
20:19:39 <thelema> what's the result of that command?
20:23:54 <Ptival> thelema: /usr/lib/ocaml/bistring
20:25:49 <thelema> ok, bitstring is installed with ocamlfind...
20:28:39 <thelema> filename + tag + ocamlfind package should result in -package foo
20:28:46 <thelema> How did you compile without that?
20:28:58 <thelema> maybe try `true: package(...)...
20:29:00 <thelema> `
20:30:41 <Ptival> I used to compile with
20:31:05 <thelema> hmm, but if it were the tags, how are you getting -linkpkg...
20:31:18 <Ptival> ocamlfind ocamlc -package bitstring,bitstring.syntax -syntax bitstring.syntax -linkpkg file.ml -o file
20:31:28 <thelema> that looks right.
20:31:38 <Ptival> but now I have multiple files so this does not work anymore
20:32:01 <thelema> change the predicate for your tags to just "true"
20:32:09 <Ptival> ok
20:32:33 <thelema> wait, which version of ocaml are you using?
20:32:40 <thelema> 3.12.0 or .1?
20:32:51 <Ptival> oh, it works
20:32:59 <thelema> you might be running into a 3.12.0 bug with ocamlbuild... or not
20:33:02 <Ptival> 3.12.1
20:33:37 <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
20:34:04 <thelema> I guess tagging *.byte doesn't work. or maybe it's that "" doesn't do globbing... hmmm
20:34:32 <Ptival> I don't really care about the pattern for now :)
20:34:39 <Ptival> true is fine with my use
20:34:45 <thelema> great. carry on.
20:34:48 <Ptival> thanks
20:48:19 <NaCl> So, I'm looking at making a lexer/parser. What are the advantages of using ocamlyacc/ocamllex over yacc/lex?
20:50:27 <thelema> NaCl: you get to use ocaml
20:53:28 <NaCl> I see
21:17:44 <Drakken> Anybody know why Archimedes.Viewport.layout_borders makes the plot on the parent viewport disappear?
21:18:27 <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.
21:18:28 <thelema> Drakken: I assume you can't order things so it all works?
21:18:48 <Drakken> thelema I tried before the plot and after.
21:18:50 <thelema> maybe all plots must be child plots?
21:19:15 <Drakken> maybe. I can't even find a general manual on wtf a viewport exactly is.
21:19:49 <Drakken> I thought it was the clipping region for the plot, but I can use the viewport to display text in the margin.
21:20:17 <thelema> viewports are usually a combination clipping region / scaling factors for each axis
21:20:31 <Drakken> right
21:20:57 <Drakken> it just seems strange that the parent suddenly disappears.
21:21:13 <thelema> try two children instead of parent/child
21:22:39 <Drakken> what do you mean? layout_borders created five children: one for each border and one for the middle.
21:22:57 <thelema> ok, maybe I don't understand what's going on.
21:23:08 <thelema> I've still not used archimedes, despite skimming your code
21:23:24 <adrien> NaCl: with ocaml, you have variants and that makes ASTs much nicer to create and go through
21:23:33 <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.
21:24:07 <Drakken> and whether there would be new borders in the center if I initialize that.....
21:28:40 <thelema> adrien: very true - Variant types are awesome for ASTs
21:29:02 <thelema> Drakken: I have no idea.
21:29:40 <Drakken> thelema that's okay. I'm posting a support request to the archimedes group.
21:31:17 <adrien> NaCl: C: unions + enums and switch-case vs. OCaml: variants and pattern-matching
22:03:52 <NaCl> adrien: If I do this in ocaml, I will have to take ownership.
22:04:00 * NaCl isn't sure he wants that
22:04:11 <thelema> how complex is the thing you're parsing?
22:12:17 <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
23:08:04 <NaCl> thelema: simple, probably just something close to s expressions
23:08:16 <thelema> NaCl: it may not matter
23:08:21 <thelema> ocaml vs. c
23:08:40 <thelema> for more complex grammars, ocaml is very nice
23:10:05 <NaCl> I think it's just going to be glorified boolean logic
23:10:42 <NaCl> with some easy noncomplex way to specify certian predefined function parameters
23:11:17 <thelema> wait, if it's got logic, that's not so trivial.
23:11:38 <thelema> if it's as complex as a calculator, use ocaml.
23:12:38 <NaCl> kk, I'll look into it
23:13:15 <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.
23:15:50 <adrien> mmmm
23:16:06 <adrien> let him do it without a parser generator and see how he manages? :P
23:16:23 <thelema> use ocaml and have fun with parser combinators
23:17:49 <NaCl> mmm
23:18:08 <NaCl> I'll see if the guy who asked me to do this agrees with the idea
23:22:04 <NaCl> adrien: have any idea how reliable the mysql bindings are?
23:26:21 <adrien> NaCl: dunno; somehow I expect them to be good but I don't know why
23:26:37 <adrien> you should try to see what is using them
23:27:44 <_habnabit> well, that assumes that anything related to mysql can be 'reliable'
23:28:52 <NaCl> I don't have a choice in the matter.
23:29:23 <NaCl> MySQL is a requirement
23:31:36 <_habnabit> I'm sorry
23:34:50 <NaCl> heh
Jump to Line
Something went wrong with that request. Please try again.