2011-01-20

<hcarty> thelema: Does it make sense to provide .seq (and possibly .of_seq) functions in Batteries? Enum is nice, but the consumtion of Enum.t values can give surprising results at times.
<hcarty> thelema: I can test in more detail tomorrow, but it looks like it does prevent Batteries from triggering that bug
<hcarty> thelema: I have a self-patched Batteries which I was testing against, and it does fix the bug there
<thelema> hcarty: no problem. I'm kinda done hacking on batteries for the moment
<hcarty> thelema: Ah, ok. I may not be able to test today, but I'll hopefully be able to tomorrow.
<thelema> hcarty: the module type bug you reported - https://github.com/ocaml-batteries-team/batteries-included/issues#issue/88
<hcarty> jonafan: Bitstring if you need more detailed support
<hcarty> jonafan: Bigarray can mmap files?
<hcarty> thelema: What's the bug?
<hcarty> thelema: You're welcome. It's too bad there isn't a cleaner solution, or at least a known cleaner solution.
<thelema> hcarty: got it. thanks for digging that up and testing it.
<hcarty> thelema: https://forge.ocamlcore.org/plugins/scmdarcs/cgi-bin/darcsweb.cgi?r=estring/estring;a=commitdiff;h=20090214215704-c41ad-4d4ed74190ec2e9edbf294304f29d0607416e321.gz -- this is the direct link, for reference
<hcarty> thelema: Ok, cool. Sorry - I thought I had linked to the patch directly
<thelema> hcarty: found it, it was the first patch in the list you linked to
<hcarty> thelema: Let me check...
<hcarty> thelema: IIRC, it was the patch in the link I provided
<thelema> hcarty: unless it's this first patch
<thelema> hcarty: can you find the patch to fix the types in the toplevel again? Your link doesn't go to a specific patch

2011-01-19

<hcarty> elehack: Ah, agreed then :-)
<elehack> hcarty: absolutely. what I was thinking of with the table is more of a comparative table for data structures themselves as one piece of an introductory/survey document.
<hcarty> elehack: I think Batteries' IO module is key, though perhaps not a key data structure.
<thelema_> hcarty: I agree on the pleac front
<hcarty> And/or Rosetta Code
<hcarty> PLEAC for Batteries could be a useful interim goal
<hcarty> A Batteries Book
<hcarty> elehack: Paulo Donadeo wrote a few intro blog posts
<hcarty> jonafan: The OCaml community is perhaps a bit more Perl-like than Python-like... there are often better ways to do something, but rarely "the one true way"
<hcarty> kaustuv: The requisite portion of camlzip could probably be exposed with a patch submitted to the forge
<hcarty> kaustuv: https://lists.forge.ocamlcore.org/pipermail/batteries-devel/2010-December/thread.html -- The relevant thread it here, with some potentially useful links
<hcarty> kaustuv: Never mind. It looks like one is or was planned, but hasn't happened yet.
<hcarty> kaustuv: There was a blog post about this recently...

2011-01-11

<hcarty> jm_ocaml: The types and type errors can become huge and complex without manual annotations.
<hcarty> thelema: I haven't tested it extensively though, so I don't know what other implications it has
<hcarty> thelema: Applying the inverse of this patch against estring in Batteries seems to fix the problem of incorrectly printed types - https://forge.ocamlcore.org/scm/browser.php?group_id=61&repo_name=estring
<adek> hcarty and adrien, once again thank you so much, my algoryth works pretty well now :)
<hcarty> adek: Good luck with your test
<adek> thank you for your great help adrien and hcarty
<hcarty> adek: It's the same thing you would have to do in C, but with different syntax
<hcarty> adek: Array.init n_i (fun i -> Array.init n_j (fun j -> ...
<hcarty> adek: Why not used nested Array.init calls? Then you would have the same kind of access as you talked about (a.(i).(j).(k))
<hcarty> adek: Lists aren't mutable
<hcarty> adek: That could be used to make your own make_3d_array function as suggested by adrien
<hcarty> adek: You can use nested Array.init calls
<mrvn> hcarty: no. SHA uses strings. I want Bigarrays. That completly changes the signature so you can't just switch.
<hcarty> mrvn: I misunderstood then. I thought the goal was to be able to switch between the two relatively transparently.
<mrvn> hcarty: then you get problems when you need both.
<hcarty> Each would provide a Sha module
<hcarty> mrvn: If it's installed with findlib then there could be sha and sha.bigarray packages
<mrvn> hcarty: with threads you have compiler option and then ocaml picks a different object file for your module if you so desire. I was hoping one could have something like that.
<hcarty> mrvn: What avoid Bigarray then in the first place?
<hcarty> I think this is how cothreads worked. I never used it beyond toying with the examples, but I think it was intended as a replacement for the OCaml-provided thread support
<hcarty> mrvn: The user, or the build system
<hcarty> mrvn: I think you would have to provide a dummy bigarray.ml with empty/invalid_arg stubs for all of the Bigarray functions you use
<mrvn> hcarty: how do I do that?
<hcarty> mrvn: And then link the actual Bigarray library when it is requested
<hcarty> mrvn: It's ugly, but you could link a dummy Bigarray library for cases where Bigarray isn't wanted (Sha_bigarray)
<hcarty> npouillard: Regardless - thank you very much! Sleep well :-)
<hcarty> npouillard: Ok, thank you! I'll poke around to see what I can find. Any suggestions for other modules to try?
<npouillard> hcarty: yes you may want to load some other modules to restore the original syntax
<hcarty> npouillard: This is how estring registers itself with the toplevel. I'm not sure if the bug is with estring or camlp4.
<hcarty> npouillard: Loading Camlp4Top.cmo after camlp4 has been loaded/activated in the toplevel causes all types to be reported in revised syntax
<hcarty> npouillard: If you're off to sleep, no rush. Just checking on a estring and/or camlp4 bug. I'm trying to figure out which program is causing the issue.
<npouillard> hcarty: pong (but was about to go sleeping)
<hcarty> thelema: Either that or estring is not initializing itself with the toplevel properly. I don't know enough about camlp4 to know which.
<hcarty> thelema: http://vpaste.net/OkeQ3? -- These steps reproduce the bug for me, so it seems to be a camlp4 bug
<hcarty> thelema: Sorry, errant paste
<hcarty> thelema: 16:02 < ezyang> YEah, that'll be fine.
<hcarty> npouillard: ping
<hcarty> thelema: Loading Camlp4Top.cmo after camlp4 has been loaded/activated in the toplevel seems to cause the problem
<hcarty> thelema: Yes
<hcarty> let foo =\nbar\nin\nblah -- for a sufficiently long bar
<hcarty> ezyang: It seems to vary. I usually put them on a new line. Others put them on the end of the previous line

2011-01-10

<hcarty> toplevel. I need to check my typing fingers for proper function.
<hcarty> thelema: Starting a fresh topleve + findlib, "#camlp4o;;" then "#require "estring";;" -> the printed types are in revised syntax
<thelema> hcarty: really? interesting
<hcarty> thelema: As opposed to (or perhaps in addition to?) pa_string itself
<hcarty> thelema: For what it's worth - the pa_string toplevel printing problem seems to be introduced by the pa_estring extension
<ezyang> hcarty: Normal arguments are poor because it leads to float -> (float, float, float)
<hcarty> ezyang: Why not normal arguments, or labeled/optional arguments as appropriate?
<hcarty> I don't think the compiler supports it
<hcarty> ezyang: OCaml might
<hcarty> noisymouse: Emacs can apparently do some nifty tricks with the interactive toplevel as well
<hcarty> noisymouse: Use rlwrap or ledit to get history and line editing
<hcarty> ezyang: Thanks! I think it is Rosetta Code
<hcarty> name of that site/project
<hcarty> IIRC, there is a project like PLEAC which has implementations of multiple simple tasks in several programming languages. Does anyone here know the/a name?
<hcarty> decaf: preludeml provides some parallel list and array processing functions which use fork internally
<hcarty> It may not use fork internally. I'm not sure if it has external tools to setup the processes (think MPI) or forks on its own.
<hcarty> decaf: It provides communication between processes
<hcarty> Which is a bummer
<hcarty> adrien: With 2.1 and earlier, the completion only works for fully-pathed names
<hcarty> Yes, that would be ideal
<hcarty> With the latest verion (2.2.0). "open Batteries;;" then "Enum." brings up an appropriate list of functions for completion
<hcarty> The lwt completion goes beyond readline support - it has some knowledge of what values/modules/etc are visible
<hcarty> Terminal incompatibilities like this are terrible, evil things.
<hcarty> Could be
<hcarty> adrien: What OS? It works here in an xterm on Ubuntu and CentOS/RHEL 5
<adrien> hcarty: xterm
<hcarty> adrien: I lost it in the backlog - what terminal are you using that has trouble with lwt-toplevel?
<ymasory> hcarty: worked like a charm, thanks
<hcarty> ymasory: rlwrap or ledit

2011-01-08

<ezyang> hcarty: The file you have to place in your directory for Batteries to work. I guess it does.
<hcarty> ezyang: It does provide a sample myocamlbuild.ml file, which should come with the Ubuntu package
<hcarty> ezyang: What is the "myocamlbuild thingy"?

2011-01-07

<hcarty> ezyang: What do you mean by full quantification?
<hcarty> Combining is certainly not best for everything
<ezyang> hcarty: Hm, I guess I could
<hcarty> ezyang: It is potentially less checked at compile-time, but you could combine them in to one function and use optional arguments
<hcarty> thelema: Yes... every time I have to bring C in, it's a struggle to decide between the OCamlMakefile and ocamlbuild
<hcarty> If GSL + ocamlgsl is pre-canned enough
<hcarty> ezyang: GSL maybe?
<hcarty> OCamlMakefile and ocamlbuild (and now/soon oasis) help smooth over the difficulty, but I still don't think I have a solid handle on the details of OCaml compilation + linking
<hcarty> thelema: I had a heck of a time getting the linking correct for the OCaml portion of PLplot, from the confines of CMake. The documentation seemed clear as mud at that time.
<thelema> hcarty: okay then. I guess it is possible to create simple .cma files without ocamlmklib
<hcarty> thelema: According to the ocamlc documentation, it looks like you can build a cma without ocamlmklib. I don't know what the differences are in output between the two though.
<hcarty> alexyk: thelema has corrected a few typos for me recently. I don't want to become dependent :-)
<alexyk> hcarty: sounds like a great excuse for every situation! :)
<hcarty> thelema: Sorry - I apparently can't read or type. I misread your message, then mistyped my response...
<hcarty> thelema: I think think ocamlmklib is used?
<hcarty> roconnor: Or a functor which takes multiple modules as arguments
<hcarty> roconnor: Yes
<hcarty> roconnor: See Map.Make in the stdlib for an example
<hcarty> roconnor: Yes
<hcarty> The order of files matters for OCaml
<hcarty> alexyk: Try putting binary_graph.cmo before common.cmo in the lib: line
<gildor> hcarty, edwin: yes but take into account that patches are also welcome
<hcarty> edwin: It's probably worth submitting a bug report/feature request
<notk0> hcarty, thank you
<hcarty> notk0: The standard library? "ocamlc -where"
<gildor> ygrek, hcarty: it is too much needed to be ignored
<gildor> ygrek, hcarty: more than a promise, I'll do it ;-)
<hcarty> diml: Thank you for the lwt toplevel. It's very nice.
<hcarty> But that's a small price to pay for such a wonderful tool :-)
<hcarty> There printing of the completion bar gets mixed up a little bit during a window resize
<hcarty> diml: That seems to be the problem. I removed that line and now everything seems to work.
<diml> hcarty: note that you must not have '#use "topfind"' in you ocamlinit if you use the lwt toplevel
<hcarty> Let me try removing that
<hcarty> thelema: But I also turn off/on Sys.interactive
<hcarty> thelema: #thread and #require "batteries"
<thelema> hcarty: what's in your ocamlinit (other than batteries?)
<hcarty> diml: I may have spoken too soon. I had a .ocamlinit file. If I remove that, then it does not seem to freeze on a resize
<hcarty> diml: If I resize a window with an Lwt toplevel running in it, the toplevel appears to freeze
<hcarty> ygrek: Ok, that's good to know. I thought I had heard something about that.
<edwin> hcarty: ccopt seems to work for that too: ocamlfind ocamlc -ccopt -DFOO -c foo2.c
<hcarty> For a C library which is not under /usr or /usr/local
<hcarty> edwin: C sources
<edwin> hcarty: field in _oasis
<hcarty> edwin: Would that be set as an environment variable, or would I have to edit the _oasis file?
<hcarty> diml: Thank you, defining/updating C_INCLUDE_PATH and LIBRARY_PATH appropriately does exactly what I need
<hcarty> diml: Ok, thank you! I'll give it a try.
<diml> hcarty: you can use the environment variables C_INCLUDE_PATH and LIBRARY_PATH
<hcarty> diml: Is there a way to do this with Lwt's build system?
<hcarty> diml: You may be able to help. I would like to be able to specify the libev include and lib locations when building/configuring Lwt 2.2.0
<hcarty> gildor: Is there a consistent way to provide extra flags to the C compiler for a project using oasis? An equivalent to CFLAGS, for example.
<hcarty> thelema: Yes, thanks
<thelema> hcarty: s/and/are/
<hcarty> ocamlp3l, preludeml/fork, jocaml, ocamlnet and ocamlmpi and the main options for true parallelism in OCaml
<hcarty> Yes, only one thread at at time, and only one "real" thread
<alexyk> hcarty: so 1 effective thread running at a time?
<hcarty> alexyk: That said, I've only really used it for it's super-spiffy custom toplevel :-)
<hcarty> alexyk: Neither, it is for non-parallel concurrent programming
<alexyk> hcarty: BTW, is Lwt real parallelism or preemptive?
<hcarty> val flip : ('a -> 'b -> 'c) -> 'b -> 'a -> 'c
<hcarty> maybe that is
<hcarty> alexyk: flip maube?
<hcarty> I don't remember the name
<hcarty> There is a an equivalent to the swap function you want
<hcarty> Probably in the main Batteries module
<hcarty> alexyk: I think so
<hcarty> Is there a way to pass C compiler flags to the oasis build process? Specifically for telling Lwt's build system where to find libev.
<hcarty> alexyk: Not in the standard library. You could just define compare_desc once and reuse it...

2011-01-06

<hcarty> It appears it is. I was reading an old README, rather than the 2.2.0 README
<hcarty> Is this the proper libev for use with Lwt? http://software.schmorp.de/pkg/libev.html
<hcarty> Which are in the process of being improved...
<hcarty> ezyang: PLplot has OCaml bindings as well
<hcarty> thelema: For some definitions of correct :-)
<ezyang> hcarty: 63-bits of randomness for 64-bit int
<hcarty> ezyang: What has no one done before?
<hcarty> thelema: Indeed
<hcarty> ezyang: Yes, though at this point it is 1 for every implementation.
<ezyang> hcarty: Isn't the number of cannabilized bits implementation dependent?
<hcarty> And "Random.int ((max_int / 2) * 2) + 1"
<hcarty> For your definition of int_size
<hcarty> ezyang: You can use "Sys.word_size - 1"
<ezyang> hcarty: Savvy.
<hcarty> ezyang: With the extra gotcha that "...;" can not be used at the top level
<hcarty> ezyang: "let _ =" ignores any return value; "let () =" will give a type error at compile time if the return type isn't unit; "...;" will give a warning if the return type isn't unit
<hcarty> ezyang: ; is a sort of half-way compromise between let _ = and let () =
<hcarty> ezyang: http://pastebin.com/VsiNh8ZP -- only the end has been changed
<hcarty> "
<hcarty> ezyang: You can do "let () = let x = ... in foo; bar; baz
<ezyang> hcarty: Ah, ok.
<hcarty> Unless you really mean to ignore the result
<hcarty> ezyang: A minor point, but "let () = ..." is generally a bit safer than "let _ = ..."

2011-01-04

<hcarty> adrien: I may be wrong about that though. The necessary components may be included in the output generated by SWIG
<hcarty> I think all of the C.* wrappers and casts used by SWIG require a run-time library
<hcarty> :-)
<hcarty> So to answer your first question - yes. Please use caution.
<hcarty> adrien: Both, I believe

2011-01-03

<hcarty> adrien: Thanks :-) I'll let you know if I am able to try it out
<adrien> hcarty: ok, good luck ;-)
<hcarty> adrien: I'll read through the packaging tutorial
<hcarty> adrien: Probably Linux, thought Windows is an eventual possibility
<hcarty> adrien: OCaml itself would be interesting :-) Possibly PLplot (and cmake, since PLplot needs it)
<adrien> hcarty: also, I'll change the format a bit, especially the version field since "binutils-2.20.51.0.1" definitely doesn't have a "x.y.z" version scheme
<adrien> hcarty: I've just written http://yypkg.forge.ocamlcore.org/tutorial/makeypkg-tutorial/makeypkg.html , it should provide a good intro and I'll be happy to answer anything not mentionned there
<hcarty> adrien: A bit - some local packages for GODI primarily
<adrien> hcarty: are you used to making packages in general? (setting DESTDIR and others)
<hcarty> adrien: Is there a reference for creating packages for yypkg?
<hcarty> Axioplase_: Batteries is a library + a few optional camlp4 extensions. It sits on top of OCaml, it doesn't modify the language/compiler itself.

2011-01-02

<hcarty> notk0: You could use pattern matching - let x, y, z = if ... then 1, 2, 3, else 4, 5, 6
<hcarty> Ok, thanks
<hcarty> rather
<hcarty> any reasonable chance, rahter
<hcarty> npouillard: Do you think there is any chance it will be implemented before 3.12.1?
<hcarty> Ah, ok
<hcarty> npouillard: Is it a smaller bug then? Anything I can do to help test/isolate/fix it?
<npouillard> hcarty: after a second look it seems completely implemented, I rembember delaying waiting for other devs to pick it up
<hcarty> npouillard: It seems that way - it works without camlp4, but fails with it. I'm not sure if it's a complete lack of support, or a smaller bug somewhere.
<npouillard> hcarty: oh, there is zero-support for "module type of"?
<hcarty> npouillard: Do you know of a work-around for http://caml.inria.fr/mantis/view.php?id=5172 ("module type of" does not work with camlp4)?
<npouillard> hcarty: it was fun to watch indeed
<hcarty> npouillard: The "OCaml history using Gource" video you put up looks quite cool
<hcarty> gildor: Yes, I thought the arrangement of the video worked wonderfully. It made it easy to follow what was going on in the talk.
<gildor> hcarty: thanks for watching does the video arrangement ok for you (slides + windows for the speaker + speaker full screen from time to time)
<hcarty> gildor: I finally got a chance to watch the video of X. Leroy's talk from 2010's OCaml meeting. It was very interesting to watch - thank you very much for putting it together.

2011-01-01

<hcarty> thelema: Did that work? It looks like it's what you'd want
<thelema> hcarty: More specifically, -DFOO - is this at all compatible with how findlib works?
<hcarty> thelema: I just tried it in the toplevel (GODI, OCaml 3.12.0) and it works here
<hcarty> If you need patches for findlib support, Debian and Fedora are both excellent places to look
<hcarty> You best bet may be to patch the offending package to use/support findlib
<hcarty> You're welcome - good luck!
<hcarty> If I understand the question correctly
<hcarty> Something like "ocamlc -I /path/to/the/module ..."
<hcarty> thatch_: I think you want the "-I" compiler flag
<hcarty> If you install with "ocamlfind install ..." then you can be pretty sure that findlib will know how to access them later.
<hcarty> Precisely
<hcarty> thatch_: Yes, that is probably best
<hcarty> thatch_: Fedora installs system and user packages to the same location (or it did last time I checked)
<hcarty> thatch_: For example, using Debian's packages, a user-installed library ends up in a different location than a Debian-installed library. Both are still found by findlib.
<hcarty> thatch_: I think Fedora and Debian both use findlib with all of their packages. You can configure findlib to install/look in various locations.
<hcarty> adrien: :-)
<hcarty> banisterfiend: That's... a sad statement about you?
<banisterfiend> hcarty: i blame women
<hcarty> There have been some grumpy people in #ocaml over the last several hours...
<alpounet> thelema, dark, hcarty, i was indeed saying that :: can't be used as a function like the other operators, and that value constructors in OCaml, more generally, are not functions, whereas they are, in Haskell
<hcarty> There may be a camlp4 extension somewhere which automatically creates constructor functions...
<hcarty> dark: I agree - it's too bad that it's not available in OCaml

2010-12-31

<hcarty> In the example, that is
<hcarty> dark: I think that was part of alpounet's intention
<hcarty> dark: I'm fairly certain you can't use ( :: ) as a function
<hcarty> banisterfiend: It may be fancy talk, but it's rather important and somewhat surprising to newcomers fancy talk

2010-12-30

<hcarty> Hopefully gildor will be around to answer your question. If not, it's probably worth emailing or submitting a bug report.
<hcarty> tautologico: A repository you own or are a member of?
<hcarty> tautologico: Or you can use the newly added bug report link in the footer of the forge pages if it's a bug :-)
<hcarty> tautologico: He may not be around, but gildor is who you want

2010-12-29

<hcarty> unkanon_: Often terse, but friendly.
<hcarty> unkanon_: Community-wise, we have our trolls but the most active folks tend to be very friendly.
<Znudzon> hcarty: thank you
<hcarty> Znudzon: Without the *
<unkanon_> hcarty: using that link you gave me, I like ocaml better
<hcarty> In SML I would have had to use MLton for compiled code and something else for a REPL
<hcarty> So I could write C bindings once and share them between the two
<hcarty> unkanon_: One very big factor is and was that the official OCaml distribution includes an interactive toplevel and native code compiler
<hcarty> unkanon_: Speed, particularly the fact that it's predictable; At the time the community felt more lively and friendly; Library availability may have played a roll.
<unkanon_> hcarty: can you tell me one of the decisive factors?
<hcarty> unkanon_: Yes
<unkanon_> hcarty: and then you decided to go with ocaml?
<hcarty> gildor: Nice work on the updates!
<hcarty> unkanon_: http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html -- I found this page interesting when I was first looking at SML and OCaml
<gildor> hcarty: don't hesitate to use it
<hcarty> gildor: I would hope so too.
<hcarty> unkanon_: And, of course, OCaml is better :-) This is #ocaml after all.
<hcarty> unkanon_: Chances are that learning SML or OCaml will be similarly beneficial for you. One may be better than the other for specific projects, but if you are learning for the sake of learning a language then both are fun.
<gildor> hcarty: no, I added it, and indeed I hope it will make the *.ocamlcore.org websites more "participative"
<hcarty> gildor: I don't remember if this was there before, but I like the "Report a bug" link in the forge footer. I haven't had an opportunity to use it yet, but now it doesn't require digging to find :-)
<hcarty> unkanon_: The existing OCaml implementation seems to be pretty "bare-metal" when compared with GHC and MLton. So it is missing some optimizations those compilers provide, but its performance tends to be very easy to predict.
<edwin> hcarty: ah ocaml_revised
<hcarty> edwin: It looks like "ocaml_revised" from the highlighting source, using Markus Mottl's vim files
<hcarty> edwin: For vim, I think you need to define a value to tell the highlighter you're using revised syntax
<hcarty> Gallium wiki, rather.
<hcarty> The camlp4 wiki (brion.inria.fr) is too
<hcarty> edwin: It is here
<hcarty> gildor: Not at all
<gildor> hcarty: you don't mind the sponsor link in the footer ?
<hcarty> gildor: It's nice looking, I like it.
<gildor> hcarty: not only the forge
<hcarty> Oh my, the forge received a fresh coat of paint.
<adrien> hcarty: yes, I'm cross-compiling on a linux machine and everything is built from source, and thanks =)
<hcarty> adrien: It looks like a nifty project. Maybe something like rootless Gobo
<hcarty> adrien: Are packages built from source under Linux/BSD?
<adrien> hcarty: yup, completely portable, tried unded linux, openbsd, windows
<hcarty> julm: Thanks. I've been reading through the tutorial and I wasn't sure.
<hcarty> adrien: Is yypkg specifically for Windows, or is Windows support just one of it's features?

2010-12-28

<edwin> hcarty: no, it is all written in original syntax
<hcarty> edwin: Are you using any syntax extensions? They may be able to mix up position reporting.

2010-12-27

<hcarty> gildor: Thanks for the update :-) Yes, everything looks good here now.
<gildor> hcarty: just fix
<gildor> hcarty: problem arise around 17:00 PM
<hcarty> gildor: Yes - is it a problem on my end, or something server-side?