2009-11-11

<hcarty> mrvn: I think Smoke supports 3D, though I may be wrong. But yes, in the end it reduces to (x, y)
<hcarty> mrvn: Vector as in (x,y,z) - thing SVG and PS vs PNG or GIF.
<hcarty> rwmjones: He talked about releasing the code for Smoke at one point.

2009-11-10

<hcarty> tuple: Though I can't comment on how well or poorly it works on OSX
<hcarty> tuple: Camarade_Tux's suggestion of looking in to GODI is a good one, just for future reference!
<yziquel> thelema, hcarty: include doesn't work...

2009-11-09

<hcarty> yziquel: You could try with a simple a.ml and b.ml to test.
<hcarty> yziquel: I'm not sure.
<yziquel> hcarty: but can I leave out rstdenv.cmo from the .cma file?
<hcarty> yziquel: If I understand what you are trying to do correctly.
<hcarty> yziquel: In r.ml: "module StdEnv = struct include Rstdenv end" should do that.
<hcarty> Yeah. Anything more than just hiding the include'd module name would probably be accomplished best with b.mli
<hcarty> thelema: Sorry - mistyped. "prevents the generated module name from _showing up in_ the module interface"
<thelema> hcarty: prevents?
<hcarty> yziquel: In PLplot, a large portion of the code is generated at compile time. "include Foo" prevents the generated module from the interface.
<yziquel> hcarty: not sure what you mean by the interface staying fixed. "include A" seems fine?
<hcarty> yziquel: Will the interface stay fixed? "include A" is one option. Providing b.mli is another.

2009-11-04

<hcarty> mrvn: Congratulations then on a successful OCaml hack!
<mrvn> hcarty: It already seems to work perfectly.
<hcarty> mrvn: When you get it all working correctly, submitting a patch against ocaml-svn would likely go over well.
<hcarty> mrvn: Very nice
<hcarty> mrvn: Cool
<mrvn> hcarty: wrong. The compiler knows about bigarrays and generates asm code for it directly. Makes it really fast.
<hcarty> mrvn: As far as I know, the only bigarray material in OCaml sits in the C stubs, the Bigarray module code and the syntax definitions
<hcarty> flux: Ah, understood
<hcarty> flux: The C stubs are generated by the camlp4 extension
<flux> hcarty, uh, yes, I mixed ciml with cil
<hcarty> flux: That's what ciml does
<mrvn> hcarty: no, the primitives. Not the C stubs.
<flux> hcarty, like write it inside an .ml-file and have the c-file generated while you compile it
<hcarty> mrvn: otherlibs/bigarray/bigarray_stubs.c
<hcarty> flux: Mix what with other ml code?
<hcarty> flux: My guess is that the base wouldn't need a lot of changes. Most of the benefit would come from extending it to support more types.
<flux> hcarty, except the part where you mix them with other ml-code.. ?
<hcarty> So that part exists now
<hcarty> mrvn: That's what ciml does
<flux> hcarty, CIL.. not that simple anymore :)
<hcarty> flux: I think FrontC uses CIL internally. I tried to get it to build, but it was a monster.
<hcarty> mrvn: Not sure.
<hcarty> If you want to see truly ugly bindings, check out Swig-generated bindings for OCaml
<hcarty> mrvn: Most data, unless you want to leave them opaque, require copies between C and OCaml
<hcarty> mrvn: It does a decent job of sharing data between C and OCaml. But when in doubt, it copies.
<mrvn> hcarty: Too me it looked like it generates 2 stubs. First it copies all ocaml types into C structs and calls the second stub. The second then glues to the actual C function.
<hcarty> mrvn: The large volume of "simple" functions made it worth the effort.
<hcarty> mrvn: I've been very happy with the efficiency of the generated code. But I've been able to reuse a lot of my effort between generating bindings for PLplot and HDF4.
<hcarty> mattiase: Extlib, Core, Batteries, aaa,...
<mrvn> hcarty: I gave up on camlidl. The use is complicated, the code looks horrible and seems awfully inefficient.
<mattiase> hcarty: Instead, there are N different regexp libs, interface libs, marshalling libs...
<mattiase> hcarty: It really does - there has perhaps been too little collaboration to come to an agreed "best" solution to many problems
<hcarty> mattiase: At times, it feels like 1/2 of my time spent with OCaml is spent evaluating what other people have done :-) Particularly for something like camlidl vs ciml vs ...
<mattiase> hcarty: I really should make a serious comparative evaluation of what other people have done, instead of tackling it on my own each time
<hcarty> Would CIL do that? ASTs are getting outside of my realm of experience.
<flux> hcarty, yeah, I remember now seeing ciml earlier.. I wonder if it's been developed further..
<hcarty> flux, mrvn: It generates a separate C file which needs to be compiled
<hcarty> flux: It allows one to embed C in OCaml, sort of.
<hcarty> mattiase: Then camlidl is probably the way to go?
<flux> hcarty, ciml?
<hcarty> flux: ciml?
<hcarty> mrvn: Yes, a sexplib-like extension for C representations of types would be pretty cool
<hcarty> And, of course, the newcomer ocaml-gir
<hcarty> I don't think either provide validation of the results though.
<hcarty> mattiase: ciml does a bit of that. camlidl takes another approach.
<hcarty> Ah, right - http://www.cs.umd.edu/~furr/saffire/ - I started using OCaml after the latest release.
<hcarty> flux: :-) I looked at it a while ago, but it seemed to require a large amount of extra per-project effort to utilize.
<hcarty> mattiase: I know a University of Maryland student wrote an OCaml FFI validation tool, but I don't know if it is maintained or if it ever even worked.
<hcarty> Nothing else has caught my eye in that way though. Pure seems interesting, but you seem to lose many of the static checks.
<mattiase> hcarty: If there were, I wouldn't be here... I like ocaml a lot, but there are clearly some low-hanging fruit
<hcarty> That what I thought was so interesting about BitC. It seemed to be heading in that general direction.
<hcarty> mattiase: Is there a language which provides what OCaml provides, along with these extra goodies?
<mattiase> hcarty: It depends on whether it can be isolated in one spot or if the rule leaks out all over the place.
<hcarty> mattiase: It's not too bad when you don't have to maintain the compiler :-)
<hcarty> mrvn: Ah, of course.
<mrvn> hcarty: pointers have a 0 tag
<mrvn> hcarty: they are taged with 1.
<hcarty> mrvn: How would you identify 1, 3, 5 as something other than a pointer?
<hcarty> mrvn: Is that all? :-)
<mattiase> hcarty: INTEGER*8
<hcarty> mattiase: Fortran's an option!
<mattiase> hcarty: But BitC was more intended for system-level implementation. I don't really have such needs.
<mattiase> hcarty: BitC was perhaps a little too ambitious.
<hcarty> mattiase: Something like BitC would have suited your needs I imagine. Sadly, it seems to be a dead project now.
<mrvn> hcarty: or run 64bit on 32bit cpus too, slowly.
<hcarty> mrvn: Ah, of course :-) I forgot about that one.
<mrvn> hcarty: only to kill all 32bit cpus. :)
<hcarty> mrvn: No, not bytecode friendly. But I don't think that there is a truly bytecode friendly option here.
<mrvn> hcarty: You need to copy the right int63_on_32.ml or int63_on_64.ml to int63.ml in the Makefile.
<hcarty> flux: Yes, Richard Jones has one implementation and pa-do has another one which is strictly camlp4.
<flux> hcarty, although there is a small problem still left: operator == will work differently when it's a real int or when it's an object in 32-bit land..
<mrvn> hcarty: not bytecode friendly.
<flux> hcarty, nice, so that exists
<hcarty> It would be nice if that were included in OCaml. Probably too much standard library growth for their taste though.
<hcarty> flux: The Int63 module or pa-do extension are meant to handle those cases
<hcarty> mrvn: I have the same issue - one of the main workhorse systems I have access to has a 64bit CPU but is stuck with a 32bit kernel, due to reasons beyond my control.
<mrvn> hcarty: if only I didn't have a 32bit cpu left.
<hcarty> Until some point in the future when it is not.
<hcarty> mattiase: 63bits is plenty reasonably large for me :-)
<hcarty> I remember reading a mailing list post from a while ago stating that the special case for double arrays/records is somewhat due to inertia from prior work.
<hcarty> mrvn: No, no more than Double_array_tag. But it's still another special case.
<mrvn> hcarty: no more so than Double_array_tag
<hcarty> Adding all of these special cases could potentially speed things up. But it would also make the compiler and its C FFI more difficult to maintain and work with.
<mattiase> hcarty: Would we? And if so, why not different tags for them then?
<mrvn> hcarty: just like Double_array_tag
<hcarty> mattiase: Yes, so you would need to have special-cases in all code to know "is this Native_word_tag array int32 or in64?"
<mrvn> hcarty: due to not being boxed.
<mattiase> hcarty: No, but it's not the native-word array that's important, but Int32 or Int64 where they coincide with native word size.
<hcarty> mrvn: Right, due to the internal representation of the bigarray (a flat C array)
<hcarty> mattiase: Right - but a native-word array would not be.
<mrvn> hcarty: an int32 Bigarray is 4 times smaller an int32 array on 64bit.
<mattiase> hcarty: So is an Int32, or an Int64.
<hcarty> mattiase: What is the benefit to this though? An OCaml float is the same size on all supported platforms
<mattiase> hcarty: Yes, I thought so too, but sadly it isn't.
<hcarty> mattiase: It could be special-cased like float arrays are
<mattiase> hcarty: arrays of word-sized integers
<hcarty> mattiase: Bigarray hacks for what?
<mattiase> hcarty: Not in records or arrays - they are special-cased
<hcarty> mattiase: floats are boxed in OCaml
<mrvn> hcarty: int8, uint8, int16, uint16 generate direct asm code. surprisingly int generates a C call as do int32 and int64.
<hcarty> Perhaps not most. But the basic ones are.
<hcarty> mrvn: Most of the Bigarray module functions are C
<mrvn> hcarty: better the bigarray primitives in the compiler. Shouldn't call a C function at all.
<hcarty> mrvn: I'm pretty sure that could be done with some modification to the Bigarray C stubs
<mrvn> hcarty: It is anyoing in the int31 case as they always fit into an int. The Bigarray just needs a way to restrict itself to 4 byte on 64bit systems.
<hcarty> mrvn: Otherwise it sounds like you'll have to dig in to C.
<hcarty> mrvn: I'm not sure if there is a good-for-bytecode implementation that isn't int32
<mrvn> hcarty: I see how you can do that but again not good for bytecode.
<hcarty> Sorry about that - wrong window.
<hcarty> :q
<hcarty> mrvn: pa-do also has some int63 magic in one of its examples.
<mrvn> hcarty: any url for the Int63 module?
<hcarty> Similarly for 64bit -> 32bit?
<hcarty> Does 32bit bytecode run on 64bit ocamlrun?
<hcarty> mrvn: Int63.t is along the lines of the "type integer = int32 or int" you mentioned earlier.
<mrvn> hcarty: Bigarray already knows about int64.
<hcarty> mrvn: There is the Int63 module. But you would have to write the appropriate Bigarray glue to go along with it.
<mrvn> hcarty: I still haven't solved my problem of how to handle 31bit ints nicely yet. I hate having to pipe them through int32 for the sake of Bigarray.
<hcarty> mrvn: Very good point
<hcarty> I don't think it would in this particular module. I'm not certain of that though.
<mrvn> hcarty: The problem I see with your current one is that IF cleanup throws an exception then it is executed twice. Imagine if it calls a C function with free(p).
<hcarty> mrvn: Never in the cases I've used
<hcarty> mrvn: Thank you for the suggestions. I'll work with them and see which fits better.
<hcarty> mrvn: That's true - any suggestions for a better way to handle that case?
<mrvn> hcarty: your try_finally is broken if cleanup throws an exception
<hcarty> thelema: Does Deriving provide something like that?
<hcarty> mrvn: http://0ok.org/cgit/cgit.cgi/ocaml-hdf/tree/hdf.ml -- lines 88 - 117 show how I have used it
<hcarty> It's kind of ugly, but it seemed like the best solution at the time.
<hcarty> create *values of* the private type
<hcarty> mrvn: I've used small sub-modules (followed by an "include") to isolate the functions which need to be able to create the private type.
<hcarty> mrvn: You can do the same thing for private types
<mrvn> hcarty: I did a little "test.ml" to play with phantom types for read-only/read-write stings and I could happily write to a read-only string. Nothing worked till I moved the phantom type into a module with signature hiding the type.
<hcarty> mrvn: Yipes - yes, I've run up against that several times.
<mrvn> hcarty: only way to get phantom types to work even inside the module itself.
<mrvn> hcarty: done that. :)
<hcarty> mrvn: You could kind of do that with "module M : sig ... end = struct ... end include M"
<hcarty> Dodek: Or you can put the signature in a separate .mli file
<hcarty> Dodek: http://codepad.org/FVfxWbAL -- you need something like this
<hcarty> Dodek: Ah, an emacs-ism.
<Dodek> hcarty: well, when emacs runs repl processes, it calls them "inferior foo"
<hcarty> Dodek: Inferior caml?
<hcarty> It's a C library which provides Perl-like regular expression support. There is a very nice set of bindings for OCaml as well.
<hcarty> Perl Compatible Regular Expressions
<hcarty> There is a Batteries package for GODI. So getting that up and running should be very simple.
<hcarty> And more integrated
<hcarty> infoe: Sort or
<hcarty> infoe: If you are using Arch, using GODI may be easier than using the Arch packages
<hcarty> flux: Wow ... they added both let open M in e and M.(e)? That's excellent.

2009-11-02

<mrvn> hcarty: It is only through the clever encoding that add/sub is the same. anything else differs.
<hcarty> Well, I suppose I did learn that at some point. But it's not something I've thought about in a very long time.
<hcarty> mrvn: Ah, I did not know that. I should read up on various integer representations and the underlying math.
<mrvn> hcarty: The problem is that mul is different for signed and unsigned.
<hcarty> thelema: Ok, thanks for the clarification. I think I misread/misunderstood an earlier comment.
<thelema> hcarty: but without phantom types, it'd need a monomorphic type for code generation, but it wouldn't know which one until it was used
<thelema> hcarty: that's what it'd be for the phantom type case
<hcarty> > 'a int ?
<hcarty> Wouldn't ( * ) be (I'm not sure of the syntax) ([`unsigned | `signed] as 'a) int -> 'a int -
<hcarty> thelema: Why do phantom types seem like a bad choice to you?
<hcarty> Phantom types seem like a very interesting approach to unsigned int values in OCaml. Either method (phantom types or a new uint type) could be masked with pa-do.
<hcarty> Yes, that's it.
<hcarty> mrvn: Sys.word_size or something like that I think.
<hcarty> mrvn: Native int :-) As in, whatever is native to the system's arch (31 or 63).
<mrvn> hcarty: yep.
<hcarty> mrvn: Then 31 vs 63 bit OCaml int?
<mrvn> hcarty: that is boxed.
<hcarty> mrvn: Native int?
<hcarty> Ah, I see
<hcarty> mrvn: It should be easy enough to share the data and avoid the copy
<hcarty> mrvn: Yes
<mrvn> hcarty: that changes a int array to int64 array and the like?
<hcarty> mrvn: IIRC it makes a copy of the bigarray though, so it's likely not what you have in mind.
<hcarty> mrvn: I have a "Bigarray.Genarray.cast" function if you're interested.
<hcarty> I think that binaries without the interpreter embedded start with a #! ... ocamlrun line
<hcarty> dfjoerg: You could check if the first line in the file is a #! line
<mrvn> hcarty: if you support 12 archs you have to put some thought into it
<hcarty> mrvn: That makese sense. The Debian OCaml packaging scheme seems to be very well thought out in general.
<dfjoerg> hcarty: I mean the correct approach would be to build a binary that includes the bytecode as loadable section
<hcarty> Native code binaries can be stripped without ill effects.
<mrvn> hcarty: that is what debian does.
<hcarty> dfjoerg: The less hackish behavior is probably to ship the bytecode and runtime (ocamlrun) separately.
<duryodhan> hcarty: I still get reference to undefined global Str
<hcarty> duryodhan: or "ocamlc -I /usr/lib/ocaml/3.10.2/extlib extLib.cma 1.ml"
<hcarty> duryodhan: Try "ocamlc -I +extlib extLib.cma 1.ml"

2009-10-29

<hcarty> Something like that
<hcarty> BigJ:
<hcarty> BigJ: You still need the ; in there
<hcarty> BigJ: When in doubt, wrap multi-line expressions in an if/else with () or begin...end
<hcarty> if ( ... ) else if ( ... ) else ...
<hcarty> BigJ: So you need to wrap that with ( ... ), begin ... end or use "let () = ... in ..." rather than ";"
<hcarty> BigJ: No need to paste here :-)
<hcarty> BigJ: ";" often (though not always...) breaks a if/else expression
<hcarty> spicey: You need to cast them all to the parent class - http://codepad.org/8uh0N61a

2009-10-27

<hcarty> BigJ2: I don't know
<hcarty> BigJ2: You want a function which compares (vec_mag a) with (vec_mag b) and then returns an appropriate value, according to the specs in the Array.sort documentation.
<hcarty> BigJ2: I'm not sure - it would be a while before I'm able to look at it in detail. But Array.sort may do what you want with less work on your part.
<BigJ2> hcarty: is my logic correct in the sort_vec_store function for odering vectors by magnitude from smallest to largest?
<Camarade_Tux> hcarty: it creates the C stubs, the .ml files full of "external" keywords and the .ml file which puts everything in classess
<BigJ2> hcarty: k, I forgot about that constraint in imperative style
<Camarade_Tux> hcarty: of course ;)
<hcarty> Camarade_Tux: Similar to camlidl?
<hcarty> Camarade_Tux: Does ocaml-gir create both C stubs and OCaml code?
<hcarty> BigJ2: Moving the definition above the definitions of the functions which call sort_vec_store should solve your problem.
<hcarty> BigJ2: You need to define sort_vec_store before you call it.
<hcarty> BigJ2: It's probably because, in the toplevel, it's using previous definitions of sort_vec_store

2009-10-26

<hcarty> There is a "letopenin" branch in the OCaml Subversion repository as well. Record syntax shorthand, first class modules and some sort of open ... in construct (maybe). 3.12 is looking very cool.
<hcarty> flux: I'm wondering the same thing.
<hcarty> I'm looking forward to playing with it to find out more at some point, but that may be a while from now.
<hcarty> Does anyone know enough about the implementation to know if using these first-class modules has a run time performance impact?
<flux> hcarty, I think it mostly eliminates the needs of pmap, for example
<hcarty> flux: I'm curious to hear real-world uses for this shiny new functionality - it looks cool, but what does it provide that wasn't there already?

2009-10-25

<hcarty> Camarade_Tux: Ah, right
<Camarade_Tux> 17:54 hcarty : Camarade_Tux: Congratulations on the first ocaml-gir announcement
<hcarty> Camarade_Tux: You're welcome! For what? :-)
<Camarade_Tux> hcarty: btw, thanks :)
<hcarty> mjonsson: I second ocamlfind

2009-10-24

<hcarty> thelema: So at this point, I think the issue needs to be taken up with the GODI maintainers, and either an extra "zip-compat" package could be added or the package name can be changed entirely
<hcarty> thelema: The work-around I use is to install a "zip" package on GODI which only contains a META file which requires "camlzip"
<hcarty> Camarade_Tux: Congratulations on the first ocaml-gir announcement
<hcarty> thelema: The Debian folks still think that GODI should change its name for the package

2009-10-23

<hcarty> travisbrady: You're welcome
<travisbrady> hcarty: thank you
<hcarty> travisbrady: You can use the map_file functions in the various bigarray modules.
<hcarty> orbitz: I'm sure they were talking about C.
<hcarty> mattiase`: That's good to know. OMake seems like a very nice project.
<mattiase`> hcarty: I'm not sure how the new release is going, but they seem to be fairly responsive in general
<hcarty> pmurias: Unix is not considered part of the standard library. it is included with the compiler.
<hcarty> The pre-release promised semi-automated C binding generation, among other things.
<hcarty> mattiase`: Is omake still maintained? I remember an announcement for a pre-release of omake with a lot of cool new features, but I haven't heard anything about it since.
<hcarty> meld is a very nice tool, even if it is written in Python :-)
<hcarty> The tools available for OCaml are certainly not perfect. But what we have does work well as long as each tool is used for its intended purpose.
<hcarty> pmurias: But you have to say which library you want it to use. There may be multiple libraries which provide the same interface, for example.
<hcarty> pmurias: If you use ocamlfind, it will.
<hcarty> A myocamlbuild.ml or using OCamlMakefile will help a lot with handling those trickier cases.
<hcarty> ocamldep and/or ocamlbuild provide dependency resolution. Things get trickier when you start to include external libraries, C, etc.
<hcarty> pmurias: One tool for one job
<hcarty> pmurias: Right - the same philosophy applies in most Linux distributions.

2009-10-22

<hcarty> razel: Unless you simply want to replace that element, in which case Array.set or "my_array.(i) <- new_value" will do what you want.
<hcarty> razel: You would have to re-create the array with that specific element removed.
<hcarty> thelema: Incomplete matches I think? I don't remember what the specific error was, but I ran in to it a few times when I was starting out with OCaml and using ;; after all of my functions.
<hcarty> thelema: That is very true
<hcarty> ;; can hide other errors
<hcarty> thelema: This is not a good excuse - but an editor's automatic indentation helps a lot with that sort of problem.

2009-10-21

<hcarty> thelema: Agreed. But better to use findlib, which exists and is well tested, rather than recreating the same functionality in a new tool.
<thelema> hcarty: a "community" distribution of ocaml with all sorts of things built in and just working.
<thelema> hcarty: as to findlib in default ocaml install, that's the job of packages.
<hcarty> It would be very nice to be able to use the findlib API from myocamlbuild.ml or, better, have findlib as a part of the default OCaml install so that it's part of stdlib and integrated by default with ocamlbuild.
<gildor> hcarty: agreed
<hcarty> META files are much simpler than trying to create a plugin-per-library
<hcarty> thelema: I don't understand why you would want to recreate findlib functionality in ocamlbuild, rather than just using findlib
<hcarty> thelema: But ocamlbuild doesn't track anything outside of the project
<hcarty> thelema: Maybe, but wouldn't it be better to just use the ocamlfind API directly?

2009-10-18

<hcarty> Are there any OSX users here? A PLplot user is getting some odd linking errors on OSX and I don't have Mac to test on.
<hcarty> Between the Lwt efforts and Cameleon's toplevel GUI wrapper there are some very nice toplevel enhancements around right now.
<hcarty> I don't know what license issues may come up. I think the Top* modules are under the delightfully archaic QPL.
<hcarty> I have only toyed with it a little bit so far though.
<hcarty> Camarade_Tux: I think it is, within the Lwt codebase and installed packages.
<hcarty> It's similar to rlwrap's support, and it supports tab-completion. The code to hook in to the completion routines looks fairly straightforward so it may provide a nice base for (semi)intelligent tab-completion in the toplevel.
<hcarty> Camarade_Tux: The ocaml-text module and some of the Top* modules
<Camarade_Tux> hcarty: do you know how they achieve this?
<hcarty> s/side/outside/
<hcarty> thelema: Without the need for out side tools - just '#require "lwt.top";;' once Lwt is installed.
<hcarty> thelema: Lwt 2.0 has line editing + history support for the toplevel

2009-10-16

<hcarty> Anonymous591: You're welcome
<Anonymous591> hcarty: ahh i see. thanks!
<hcarty> operator
<hcarty> Anonymous591: Or ~-1, where ~- is the prefix negation
<hcarty> Anonymous591: You need (-1) rather than -1
<hcarty> BigJ: In this case, it looks like f is the function you want to take the derivative of.
<BigJ> hcarty, I have this function
<hcarty> BigJ: Symbolic or numeric? If you do a search for "derivative ocaml" several mailing list and blog posts should come up
<BigJ> hcarty, now I am wondering how I can take a derivative
<hcarty> BigJ: Yes
<hcarty> BigJ: To properly constrain the types you would need to add a module signature and/or use a record type instead of a tuple
<BigJ> hcarty, at the else statement?
<hcarty> BigJ: (x, y) would give you the negated vector
<BigJ> hcarty, right so I need to break up each value
<hcarty> ( *. ) is specifically for float values
<hcarty> BigJ: You need to multiple each component of "a" separately

2009-10-15

<hcarty> rlwrap's line editing and completion may be a bit better at this point, but the Lwt result is impressive.