2011-11-04

<hcarty> thelema: I get what look like server side errors (Lwt-related)
<hcarty> thelema: Can you get to the oasis-db/odb site?

2011-11-03

<hcarty> HaikuUser: Obj.magic is always the wrong answer :-)
<hcarty> If they want feedback on reasoning they are free to ask of course
<hcarty> The reason is up to HaikuUser to decide :-)
<hcarty> This is only possible if those types are somehow wrapped
<hcarty> HaikuUser wants to define a function that can return multiple types
<hcarty> It sounds reasonably well specified
<hcarty> _habnabit: Doubt...?
<hcarty> HaikuUser: Where "something similar" would probably be more verbose than using a variant
<hcarty> HaikuUser: You would need to create a variant with all of the possible options or something similar.
<hcarty> HaikuUser: 'a -> 'b is only possible with Obj.magic and similar type system-breaking functions

2011-11-02

<hcarty> adrien: I think ocamlfind's destdir interpretation is the second version
<hcarty> adrien: I'm only asking you to wait for you to write it :-D
<adrien> hcarty: concatenation of heredocs works but is quite verbose because one has to close the first here-doc, put the conditional, open a here-doc, close it, put an else, an empty string, open another here-doc
<hcarty> adrien: Concatenation of heredocs should work out of the box I think
<hcarty> adrien: Without that the c_sources block would need to be pulled out into a prior interpolated string.
<hcarty> adrien: Of course, xstrp4 could be expanded to support templates or template support could be built on top of xstrp4.
<hcarty> adrien: I think I agree with thelema at this point. You would probably be better off with some form of templates.
<hcarty> caaakeeey: files.metaprl.org/doc/ocaml-book.pdf is a somewhat more modern OCaml book
<adrien> hcarty: or concatenation of here-docs
<adrien> hcarty: about conditionals in here-docs for xstrp4, do you think a syntax like http://pastebin.slackadelic.com/p/s9vCMy51.html is possible?

2011-11-01

<thelema> hcarty: maybe just conditional printing: "%{BuildDepends:}" (Option.is_some dec)
<hcarty> I've had instances where I've wanted to do something similar, so it's probably a reasonable addition if it can be done cleanly.
<hcarty> adrien: If you have a suggestion for how to do it and a clean patch I'll certainly take a look :-)
<hcarty> Ah. You could do something more complicated to make it work inline, but you may be better off lifting that out of the interpolation.
<hcarty> adrien: If you are using Batteries then you will want to use Batteries-like %a printers, if you are not then you will want stdlib-like %a printers.
<adrien> hcarty: but I have the "BuildDepends: " prefix that I only want to print if the option is Some x
<hcarty> adrien: Or you can create some similar, shorter equivalents.
<hcarty> adrien: ex. "${foo, Option.print String.print}"
<hcarty> adrien: If you use Batteries then you can use the Batteries printing functions
<adrien> hcarty: about xstrp4, I have a "string option" and I want to write "BuildDepends: ${library.build_depends}" inside a here-quotation (library.build_depends is of type "string option")

2011-10-30

<adrien> you need xstrp4 (haven't tested it with hcarty's version yet)

2011-10-29

<hcarty> s/for/few/
<hcarty> adrien: The first for bytes may tell you, if it's not a library.
<hcarty> Sorry, wrong window
<hcarty> ls
<adrien> hcarty: right; I realized odb wouldn't be fine for distrbution packages as I was writing my questions ;-)
<hcarty> adrien: Or a switch to oasis as a build system
<hcarty> adrien: There is no lablgtk2 package for odb yet. This would be eased if lablgtk2 were to have native ocamlfind support when ./configure && make && make install'ing it
<hcarty> adrien: odb is probably not appropriate for creating Linux distribution packages, but oasis is/will be/can be.
<hcarty> adrien: :-) that is
<hcarty> adrien: The odb quickstart guide is waiting for your contributions :-

2011-10-26

<thelema> _habnabit: I or hcarty have to promote it

2011-10-21

<hcarty> This is mostly guessing, but you can probably replace any instance of fun with function + some extra code; the same is likely true in reverse.
<hcarty> But let and fun are limited to a single match case, while function and match allow for multiple cases.
<hcarty> Dasuraga: fun can do pattern matching in some forms (the same way let can). For example, (fun (a, b) -> a + b) is pattern matching.
<hcarty> everyonemines: I don't think so, but you'd have to look at the assembly/intermediate code to be sure
<gildor> hcarty, thelema: oasis remains my top priority project, if I had choice to make, it'll be the last project I'll discard
<gildor> hcarty: I start on 1st November
<hcarty> gildor: That's good to hear. And have fun at Google :-) When do you start?
<gildor> hcarty, thelema: I will even resume my work on it while at google
<gildor> hcarty, thelema: I REALLY don't plan to drop it
<gildor> hcarty, thelema: my new job means 'almost' nothing to oasis
<hcarty> kuscotopia: I think OCamlMakefile can automate most of the process if you have trouble getting it working for your code
<hcarty> I'm fairly sure the oasis-db server code is available. It may be reasonable to continue using that as the primary metadata creation system.
<hcarty> It may make sense to split the .tar.gz repository from the metadata repository
<hcarty> thelema: All packages could be managed under a single repository if you want to go all-out. That repository could be cloned anywhere, providing a mirror.
<thelema> hcarty: other option is to get vcs support in odb - ocaml odb.ml github/batteries
<hcarty> thelema: Agreed. Particularly low-tech/dumb mirrors.
<hcarty> thelema: That's what I would guess as well
<hcarty> gildor: And congratulations on whatever your new job is!
<thelema> hcarty: I'm guessing that we the community will have to pick it up where he left off
<hcarty> gildor: What does this mean for the future development of oasis?

2011-10-20

<hcarty> eikke: But it Batteries is an acceptable dependency then its printing functions tend to be quite useful and simple to extend.
<hcarty> eikke: There are a few camlp4 extensions which provide something similar - deriving, one for s-expressions, one or more for JSON

2011-10-18

<hcarty> limited subset *of what is presented in* those two articles
<hcarty> thelema: pa-do's macro extension looks like a limited subset of those two articles
<hcarty> thelema: pa-do may be something to point someone to as an implementation example, particularly if macros are the goal
<thelema> hcarty: hacker news
<hcarty> thelema: HN?
<hcarty> rgrinberg: It is common to see all operators passed that way ( + ) ( - ) ( / ) for consistency
<hcarty> rgrinberg: The required work-around is to use ( * ) instead of (*)
<rgrinberg> thanks hcarty
<hcarty> rgrinberg: They also work nicely with the Printf.* functions: Printf.printf "%a" (List.print Int.print) [1; 2; 3]
<hcarty> rgrinberg: The Batteries printing functions are intended to be composable. So you can print a list with: List.print Int.print stdout [1; 2; 3]
<hcarty> _habnabit: Yes, that too :-)
<hcarty> rgrinberg: Followed by where you want the output - stdout for example
<rgrinberg> thanks hcarty, let me try that out
<hcarty> rgrinberg: Hashtbl.print Key.print Value.print

2011-10-17

<hcarty> thelema: Which one will 2.0 end up with? inter or intersect?
<hcarty> I don't want to make an announcement without hearing back from Gerd and hopefully pushing the changes upstream.
<hcarty> adrien: Let me know if it works :-)
<hcarty> adrien: No announcement - I haven't heard from Gerd
<adrien> hcarty: where is your xstrp4 fork? and have you announced it?
<adrien> hcarty: thanks
<hcarty> adrien: You could try sub-packages. I think there is an example in the oasis source tree illustrating their use. My xstrp4 fork uses them as well.
<hcarty> adrien: I'm guessing it's because you are effectively asking oasis to create three META files in the same location

2011-10-16

<hcarty__> thelema: odb + windows
<thelema> hcarty__: biggest challenge to what? replacing godi with odb?
<hcarty__> adrien: :-)
<hcarty__> adrien: The biggest challenge is probably providing the external dependencies or replacing them with libraries used in a static odb binary

2011-10-14

<hcarty> devinus: Have fun!
<devinus> emmanueloga, hcarty thanks, will check these out tonight
<hcarty> Jason Hickey's book is well written and the chapters on modules and the object/class system are particularly helpful.
<hcarty> devinus: There were publication complications, from what I understand
<hcarty> devinus: And a second to emmanueloga's comment about the manual - it's generally quite accessible

2011-10-09

<hcarty> thelema: But I'm not certain about that
<hcarty> thelema: The forge SSH key
<hcarty> thelema: I think it did change some number of months ago

2011-10-08

<hcarty> thelema: It may be a good idea to make the Batteries wiki pages more visible. They cover a lot of getting started questions like sheleh's.

2011-10-05

<adrien> hcarty: and rebase, amend commits, rewrite history, delete branches and replace them with different ones which only share the name
<hcarty> gildor: Of course :-)
<hcarty> adrien: I think you do need to add FindlibName if you want one. I think this is in part to support nested findlib names.
<gildor> hcarty, adrien: oh, and of course, when I see some tags missing, I fix the generation process directly in oasis ;-)
<hcarty> gildor: That's an even better plan :-) Thanks for the tip!
<hcarty> adrien: Branch, but immediately after branching delete the original branch. Burning bridges, all the cool kids are doing it.
<hcarty> :-) They do serve a purpose from time to time
<hcarty> adrien: With several repetitions of the last two steps in order to get everything working properly
<hcarty> My oasis conversions have generally gone along the lines of: git checkout -b oasis && rm build_system_files && oasis quickstart && vim _oasis && oasis setup
<hcarty> As long you have a backup, yes. oasis will generate one which you may need to modify, depending on your project.
<hcarty> oasis would hopefully allow for easier future growth.
<hcarty> adrien: Or you could wrap a thin Makefile around your ocamlbuild setup.
<hcarty> adrien: oasis, as long as it supports what you need
<hcarty> adrien: Just to provide another data point :-)
<hcarty> adrien: odb is still on typeconv 2.3.0 by default at least in part to keep odn (and oasis) compatibility

2011-10-04

<f[x]> hcarty, see the first comment in http://ocaml.janestreet.com/?q=node/79
<hcarty> f[x]: My understanding of rank-2 polymorphism extends about as far as knowing the name, so I may be way off.
<hcarty> I wouldn't be surprised if first class modules opened up something here as well since they can include record types and classes
<hcarty> f[x]: It is supported with classes as well according to http://alaska-kamtchatka.blogspot.com/2009/05/rank-2-polymorphism-and-non-uniform.html
<hcarty> f[x]: This is the explanation I received when I ran into the same issue
<hcarty> f[x]: I think the record restriction is due to rank-2 polymorphism only being supported through records(?) in OCaml
<f[x]> hcarty, yes, this is the way I've discovered, except that it has to be 'a. 'a T.t -> unit for some reason

2011-10-03

<hcarty> f[x]: It may not be the only 3.11-able approach, but wrapping f in a record will work: type f_t = { f : 'a. 'a -> unit }
<hcarty> f[x]: I had to do something similar for ocaml-hdf
<hcarty> f[x]: Got it :-)
<hcarty> But it is not likely be a trivial task.
<hcarty> everyonemines: Not to discourage you from trying!
<hcarty> everyonemines: Integer sizes, separate compilation, first class modules, the class/object system
<everyonemines> hcarty: I'd be interested in info about those kind of differences.
<hcarty> s/language's/languages/
<hcarty> everyonemines: The language's make different assumptions about how the internals work. There was a presentation from the mlton folks which (jokingly?) mentioned ocamlton.

2011-10-02

<hcarty> thelema: Any luck tracking down the oasis-db bugs/issues you were seeing a few days ago?
<hcarty> thelema: I added an odb-installable ocamlscript package if you get a chance to test

2011-09-30

<hcarty> Have a good evening
<hcarty> thelema: I'll check the logs later to see if there is anything I can do to help with the odb trouble
<hcarty> Not bad
<hcarty> Ack... I can't type. s/the/they/
<hcarty> thelema: The files in testing/pkg/info/ look like the have the correct content for hdf4
<hcarty> Odd. "ocaml odb.ml hdf4" works here
<hcarty> Although I thought I had put in the original URL when I uploaded it.
<hcarty> thelema: What's the problem with hdf4? I only see one source for the .tar.gz on the oasis-db site.
<hcarty> Only when I notice a new package and am able to test it
<hcarty> I haven't done it with many packages
<hcarty> s/testing/tested/...
<hcarty> s/packaged/testing/
<hcarty> I've promoted packages to testing as well, but also only ones I've packaged.
<hcarty> I haven't tried installing any of them before now
<hcarty> thelema: Did these work in the past?
<hcarty> benchmark could probably be uploaded again. Which others are failing?
<hcarty> thelema: It looks like it isn't downloading properly
<hcarty> thelema: Failure "Could not extract tarball for benchmark(benchmark-1.0.tar.gz)".
<thelema> hcarty: can you `odb.ml benchmark`?
<thelema> hcarty: I should announce such a thing on the mailing list. And I should merge any commits to the 1.x branch to the v2 branch
<hcarty> thelema: Do you have any thoughts/plans on what is required before a Batteries 2.0 release?
<preyalone_> hcarty: Noted.
<hcarty> preyalone_: The comment stands, but is not directly applicable to this topic :-)
<hcarty> thelema: Ah, oops.
<thelema> hcarty: try ... with _ -> ()
<hcarty> Or, rather, let you know if you are ignoring a non-unit value
<hcarty> preyalone_: It will let you know if you're ignoring something you don't intend to.
<hcarty> preyalone_: let () = ... is generally safer than let _ = ...
<hcarty> thelema: Thanks for updating the package!
<hcarty> thelema: Done.
<thelema> hcarty: I'll promote gsl to testing.
<thelema> hcarty: great. Can you put a comment in oasis-db about that?
<hcarty> thelema: I was able to install ocamlgsl through odb.ml
<preyalone_> hcarty: Thanks.
<hcarty> thelema, preyalone_: -linkpkg should be sufficient
<hcarty> It's an odd approach to a relatively odd task
<hcarty> I like it
<hcarty> thelema: True re: the instructions
<thelema> hcarty: not if compiled as instructed
<hcarty> thelema: It could be scriptedmain.ml or scriptedmain.exe...
<hcarty> _habnabit: Still perhaps non-standard code, but a bit easier on the eyes
<hcarty> _habnabit: I removed the ... non-standard indentation and "rec" from main
<kizzx2> adrien, hcarty: to answer my own question, OcalIDE (like its Java counterpart) builds continuously, i need to go to Project -> Properties and add the ocamlbuild targets there
<hcarty> Ah, of course.
<hcarty> thelema: It doesn't? I thought toplevel phrases were evaluated in the linked module(s).
<hcarty> thelema: On the topic of premature optimization - I was going to grumble about always requiring threading IO-overhead in Batteries before the recent module split you made for 2.0. Then I realized I've been using threaded Batteries almost exclusively without trouble.
<hcarty> There are btree implementations on github if not in Batteries.
<hcarty> Not that I would complain if functors suddenly became performance-hit-free in OCaml :-)
<hcarty> It also makes the compiler more complex and makes performance less predictable
<hcarty> thelema: Right
<hcarty> Or, OCaml doesn't do that in general.
<hcarty> OCaml doesn't do that. MLton does for SML.
<hcarty> everyonemines: Polymorphism as it exists in polymorphic comparison goes against how most of OCaml works
<hcarty> Core may
<hcarty> I don't think Batteries has anything like that yet.
<hcarty> I guess you could write type-specialized min and max functions using type-specific compare
<thelema> hcarty: nope, min and max are plain ocaml functions, no special optimization
<hcarty> thelema: There aren't many more grossly polymorphic functions in OCaml
<hcarty> thelema: No - I had thought min and max might be, but maybe not.
<thelema> hcarty: do you know of any other functions improved by type knowledge?
<thelema> hcarty: anything else?
<hcarty> thelema: That's my understanding
<thelema> hcarty: the builtin polymorphics, compare and (=), are improved by knowing types
<thelema> hcarty: not true for most functions. Compare is special because the compiler will insert specialized code for a few types.
<hcarty> Polymorphic comparison is slow in part because it dives into the underlying structure of values. Most other functions involving polymorphism don't need to do that.
<hcarty> I doubt List.map suffers terribly. But <, >, =, compare, etc. all dig into the dirty underbelly of OCaml to do what they do
<hcarty> Every polymorphic function that is
<hcarty> Is that true for every function?
<hcarty> everyonemines: I don't know how well it's advertised in general, but there are a fairly large number of blog posts, mailing list posts and other sources talking about optimizing inner loops in OCaml by eliminating polymorphic comparison
<hcarty> everyonemines: Polymorphic comparison is one example
<hcarty> everyonemines: Some are slow relative to optimized type-specific versions
<hcarty> kizzx2: I haven't used it in a long time, but I think the simplest approach is to create a project with OcaIDE's ocamlbuild support and then compile however Eclipse does its compilation

2011-09-29

<hcarty> flux: I think there is a Jane St blog post or two on that topic
<hcarty> ohwow: The OCaml standard library isn't meant to cover every possible use case - it's meant to be enough to get by, with the intent that more general functions/libraries will be developed externally
<hcarty> thelema: Removing the syntax extensions, or at least moving them to a separate project seems like a reasonable step in 2.0 or 3.0.
<thelema> hcarty: good to know. I wonder who will complain if the next batteries has no camlp4
<hcarty> thelema: I stopped trying to use estring and extensions derived from it after running into too many edge cases and unexpected incompatibilities.
<hcarty> ohwow: "let f = function Some x -> true | None -> false" is like writing "let f x = match x with Some x -> true | None -> false"
<hcarty> "function" is kind of like "match"; "fun" is useful when creating anonymous functions
<hcarty> ohwow: fun and function do two different things

2011-09-27

<thelema> hcarty: I guess I should use markus's version - I got this one off the original author's site
<thelema> hcarty: yes, lots of bugs still.
<hcarty> Rather than ocamlgraph
<hcarty> ^^ "ocamlfind remove gsl"
<hcarty> thelema: Also, the uninstall command should probably be
<hcarty> I think Markus Mottl's version fixes several bugs in the original 0.6.0 release
<hcarty> thelema: Which ocamlgsl package did you use as the source for your oasis'd version?

2011-09-24

<thelema> hcarty__: yes, this is what I'd like to understand better. Maybe it's a misunderstanding based on older batteries
<hcarty__> The external dependencies are pretty limited, more so with 2.0 and the elimination of Camomile requirement
<hcarty__> thelema: I'm not sure I understand the heavyweight argument against Batteries, particularly since each piece can be picked individually. There are of course some dependencies between modules.

2011-09-22

<hcarty> Cool, thanks for the pointer
<hcarty> Ok, so internally it is similar to what I described earlier - accumulate the bytes in a buffer, then get the bytes when the reading is done.
<hcarty> thelema: If I write ten megabytes of data to the output returned by IO.pipe, what happens to those bytes between writing and reading from the IO.pipe's input?
<hcarty> kurtosis: Or in a module in a function
<hcarty> thelema: Thanks, I'll give it a shot. Is any buffering performed by IO.input/IO.output streams?
<hcarty> thelema: With the output created internally in the function
<hcarty> thelema: So a function of source_t -> input?
<hcarty> Yes
<hcarty> I don't think so, since I don't have a IO.input value to work with
<hcarty> The input comes one string at a time
<hcarty> With the buffer implementation then becoming a wrapper around the IO-based form.
<hcarty> It currently uses Buffer.add_string and I'd like to move to IO.nwrite
<hcarty> I'd like to make something more flexible so the input can be held in a value or piped directly to some other location.
<hcarty> This is for file reading/copying. The previous implementation used a Buffer.t to hold the input data temporarily.
<hcarty> thelema: Ah, right. That may make sense in this context...
<hcarty> thelema: For example, Foo.get : source_t -> string vs. Foo.get_? : source_t -> IO.output -> unit
<hcarty> thelema: Is there a Batteries standard or semi-standard for naming functions which write to output streams?
<hcarty> Sounds reasonable
<hcarty> Is this coming in 2.0?
<hcarty> Mutex and friends live in Batteries_thread in this case?
<thelema> hcarty: that's a findlib limitation as far as I can tell
<hcarty> Manual intervention on each compilation and toplevel use, that is.
<hcarty> The only pain is that "-thread" needs to be manually specified somehow. Can that be addressed in the META file, without requiring manual intervention?
<hcarty> thelema: re: threads or no threads
<hcarty> thelema: I've been away for a while, but I'm happy to see that some conclusion was reached on how to unify the Batteries module.

2011-09-20

<hcarty__> everyonemines: That has it
<hcarty__> The documentation for one of the components includes a description of the bytecode format
<hcarty__> And there are some other pieces as well
<hcarty__> Another is a replacement for ocamlrun
<hcarty__> Ack, ocamlc rather
<hcarty__> One is a replacement for oca lc
<hcarty__> everyonemines: There are several pieces
<hcarty__> everyonemines: In the documentation for one of the sub projects I think
<hcarty__> everyonemines: I think there is information somewhere in this project on the bytecode format - http://ocamljava.x9c.fr/

2011-09-11

<adrien> and preferably hcarty's updated version

2011-09-09

<adrien> hcarty: I first tried emacs on a laptop which had Ctrl and Fn keys inverted, making Ctrl even harder to reach (it also taught me that my fingers didn't like contortionism at all, even with a properly placed Ctrl key)
<larhat> hcarty: first of all, i highly recommend you to use el-get ( https://github.com/dimitri/el-get ) which simplifies package management.
<hcarty> adrien: That's why I stopped my last emacs experiment and came crying back to vim :-)
<hcarty> larhat: I'm only slightly familiar with emacs and have been meaning to give it a try again
<hcarty> larhat: An example .emacs (or whatever the default emacs local configuration file is) with caml-mode and tuareg enabled
<adrien> hcarty: you didn't know about mmap and writing? that was mentionned on the caml-list some time ago (less than a year ago, probably in 2011) but I haven't tried it nor have much knowledge of it
<larhat> hcarty: what do you mean by "ocaml-friendly"? tuareg-mode is pretty useful and has many features. And you can use utop as emacs-toplevel
<hcarty> ?
<hcarty> Does anyone here have pointers to example OCaml-friendly emacs configurations
<hcarty> adrien: I did not know that... I'll have to look up why that is the case
<adrien> hcarty: they do work on windows (well, there is windows-specific code for them) but mmap() on *nix is not a good way to write data afaik so I avoided that
<hcarty> adrien: Maybe not any better than Marshal though, depending on your specific use case.
<hcarty> adrien: Do the mmap functions in the Bigarray modules work in Windows? That may provide a simple way to serialize groups of integers.

2011-09-08

<hcarty> Oh cool... utop supports completion on labeled function arguments.
<hcarty> I'd love to figure out camlp4's internals well enough to make a perltidy-like tool for OCaml
<hcarty> Maybe they will pick up something like ocamleditor or OcaIDE and add polish
<hcarty> adrien: Agreed
<hcarty> It's nice to see these somewhat secondary tools getting attention.
<hcarty> There have been a large number of smaller camlp4 and ocamlbuild bug fixes over the past few months.
<hcarty> adrien: Ah, I misunderstood the version number.
<hcarty> adrien: There were a number of camlp4 changes wrt the new 3.12 syntax over the course of 3.12.1's development. It could be a bug which was fixed between your snapshot and 3.12.1final
<adrien> hcarty: ok, going to do so but didn't want to duplicate things in case you had already done it
<hcarty> adrien: I haven't done anything with it beyond test it with my own code, where it seems to work. If you get a chance a bug report on the forge would probably be best.

2011-09-07

<adrien> hcarty: did you do anything with that possible fix for cairo_gtk so far?

2011-09-06

<adrien> hcarty: I tried testing for memory leaks by triggering lots of redraws (resizing or moving the window)
<adrien> hcarty: =)
<hcarty> adrien: Thanks for testing that!
<hcarty> adrien: I tried your patch and it works well here. I haven't checked for memory leaks or anything of that sort, but the assert not longer happens.
<hcarty> adrien: That makes sense. I recall reading something along those lines in the Cairo documentation.
<adrien> hcarty: that solves the issue but I don't know if it's the best way to do it (although #gtk+ seemed to say so)
<hcarty> adrien: If you have a patch I can try to get the change in as well. I have commit access but I'm not likely to get to it before the end of the week either.
<adrien> hcarty: no, not yet: I tried that last change right before going to bed
<hcarty> adrien: Have you sent a bug report or patch to the cairo2 project?
<adrien> hcarty: cairo2's cairo_gtk C stubs should increase the reference count of the surface associated with the cairo context

2011-09-05

<hcarty> adrien: Bug confirmed in ocaml-cairo2 (OCaml), Cairo (C), or through some other path?
<adrien> hcarty: ok, bug confirmed
<hcarty> NaCl: I'm off for now, but good luck!