<hcarty>
derdon: I haven't used Python enough to be familiar with its backtraces, but OCaml supports this already
<hcarty>
WTDD
* hcarty
seconds adrien's wishful thinking
2010-06-03
<hcarty>
alexyk: Your best bet would be to search on the GODI mailing list
<hcarty>
I'm not sure, it's been a while since I upgrade OCaml itself in GODI
<hcarty>
alexyk: If you are doing a fresh install then you would get 3.11.2
<alexyk>
hcarty: right, last time I tried to update ocaml, I ran into some issues
<hcarty>
So you just need to refresh the package list if you have GODI installed already :-)
<hcarty>
Yes, it is
<hcarty>
alexyk: Actually, isn't GODI up to 3.11.2 already?
<hcarty>
alexyk: I don't remember the specific steps, but there is information about this on the mailing list and GODI's web site
<alexyk>
hcarty: how do I do it?
<hcarty>
alexyk: You need to select the development package branch
2010-06-02
<hcarty>
m00npirate: I don't think that's possible
<m00npirate>
hcarty: what if im trying to rename a constructor in a variant?
<hcarty>
m00npirate: Or - let thing_func = Module.Thing.func in
<hcarty>
m00npirate: let module Thing = Module.Thing in
<hcarty>
flux: Spooky...
2010-05-29
<gildor>
hcarty: upstream of camomile told me that thing you'll be able to create your custom defaultconfig with camomile in the next release
<hcarty>
thelema: But either way, thank you and I will test it. And if it works then Batteries should be ready to go once the fixed version of Camomile is released
<hcarty>
thelema: According to the Camomile author it sounds like it may not work until some changes are made to Camomile itself, due to automatic checks of the default path(s)
<hcarty>
thelema: Thanks, I should be able to try it out either this evening or tomorrow
<thelema>
hcarty: I just pushed a change that should (untested) try $CAMOMILE_BASE/* to look for camomile files
<hcarty>
Environment variable would be preferable
<hcarty>
thelema: Either
<hcarty>
adrien: Ideally :-) Or /opt/godi/share/ or similar. But I can't do that (yet)
<hcarty>
thelema: Yes
<hcarty>
The directory structure is, sadly, not easily replicable across the two systems
<hcarty>
thelema: I don't have admin access on both systems and I'm using GODI
<hcarty>
It sounds like, in the short term at least, the only real option is to recompile the software stack on each system
<hcarty>
thelema: Ok thanks.
<thelema>
hcarty: batteries as currently written contributes to this fiasco, as it just uses the default config of camomile with no option to point to a different dir
<hcarty>
gildor: That is certainly a disappointing response. Is there any way to work around this now, or do we need to wait for a new Camomile release (or modify Camomile manually)?
2010-05-28
<gildor>
hcarty: in a recent exchange of mail with him, he told me that he will give a way to use Main.Make with whatever you want
<gildor>
hcarty: the comment explain why this is hardcoded (but I don't agree on the reason)
<hcarty>
I have a Batteries-using binary I would like to copy from one system to another without rebuilding the entire toolchain, but the binary fails on the new system because the old system's Camomile directory structure does not exist.
<hcarty>
Has a fix/workaround been found for Camomile's hard-coded data file paths?
<hcarty>
thelema: Thanks - I've only recently had a reason to use the Buffer module
<thelema>
hcarty: building a string character by character is exactly buffer's intended purpose
2010-05-27
<hcarty>
travisbrady: You could also filter the map to contain only the data you want and then fold over the result
<hcarty>
travisbrady: It is a little hackish, but it should be fairly efficient.
<travisbrady>
hcarty: Ahh, ok. I'd thought of that but it seemed slightly hackish. thanks.
<hcarty>
travisbrady: You could raise an exception containing the result and catch that
<hcarty>
Though I don't know if that is it's intended purpose..
<hcarty>
It allows you to more efficiently build a string character-by-character
<hcarty>
See the Buffer module
<hcarty>
A buffer would be a more efficient way to do this though
<hcarty>
You could use ^ with the resulting value then if you like
<hcarty>
You'd want something like (String.make 1 ' ')
<hcarty>
Batteries may provide a function to do something like this. Or you could use ropes
<hcarty>
That's completely untested, but something like that would have to be done
<hcarty>
String.init (String.length s + 1) (fun i -> if i < String.length s then s.[i] else c)
<hcarty>
krankkatze: You would need to create a new string
<hcarty>
neorab: Using OCamlMakefile or ocamlbuild would be very helpful in that case
<hcarty>
travisbrady: It is likely from Batteries or Core, and whichever library provides it is not being linked in
<kmkaplan>
hcarty: OK, thank you.
2010-05-26
<hcarty>
kmkaplan: And if you want it to be abstract, then you would only put the type's name (ex. "type t") in the .mli
<hcarty>
kmkaplan: If you want it to be hidden, no
<hcarty>
kmkaplan: If you want that type to be visible from the outside, yes
<mehdid>
hcarty: +1 :)
<hcarty>
thelema: Feature request on Mantis?
2010-05-25
<hcarty>
wvd: It's worth grabbing. It should be the first result from a search on Google for "jason hickey ocaml"
<wvd>
hcarty, oh ok, maybe it's just my internet, thanks :)
<hcarty>
wvd: Really? That's odd ... it works here
<mrvn>
hcarty: not yet. Still hoping someone might offer a suggestion why it actualy complains
<hcarty>
reported that is
<hcarty>
mrvn: I've run in to what seems to be the same bug. I can't offer any further suggestions, but I would like to track its progress if it's been reporte.
<hcarty>
mrvn: Have you reported the a bug on Mantis related to your recent mailing list thread?
2010-05-24
<gildor>
hcarty: thanks
<hcarty>
Or, perhaps more appropriately, incr gildor;
<hcarty>
Hooray! gildor++
<derdon>
hcarty: said more detailed, I am developping with PIDA with vim as the editor
<hcarty>
derdon: Still, learning new tools can be useful even if they aren't kept around
<hcarty>
derdon: I'm pretty happy with vim + OCaml in general. There are some indentation things I wish it would handle better, but it does well enough
<derdon>
hcarty: I gave emacs already 3 shots :D
<hcarty>
I've used vim for a long time, and wanted to give emacs another shot
<hcarty>
Which I see is what you have in your file :-)
<hcarty>
mehdid: I did, but didn't find anything beyond the default/example .emacs lines included in the distribution
<hcarty>
Does anyone here have an OCaml-friendly .emacs file handy? I would like to take a look at the new Tuareg release and haven't used emacs in a long time
<hcarty>
th0br0: Are the outside libraries being linked properly? (For some definition of "properly" that I don't know...)
2010-05-23
<hcarty>
flux: Oooh, nice toplevel trick
2010-05-19
<hcarty>
Apparently packing has something to do with it
<hcarty>
Oh no... I have a "Values do not match: val a : t is not included in val a : t" during compilation
2010-05-18
<hcarty>
And stand-alone programs as native
<hcarty>
It is generally reasonable to compile libraries as both byte and native
<hcarty>
Yes
<hcarty>
There is an unsupported native code toplevel, but findlib does not work with it so it is significantly harder to work with
<hcarty>
The biggest benefit of bytecode in my experience is that you can use it from the toplevel
<hcarty>
jdavis_: You're welcome
<hcarty>
jdavis_: With recent OCaml versions, both provide stack traces when exceptions are raised
<hcarty>
jdavis_: IIRC the OCaml debugger works with bytecode, while you would use gdb with native code
<jdavis_>
hcarty: ok, what about debugging, crash analysis, etc?
<hcarty>
Less than ocamlopt that is
<hcarty>
jdavis_: I've heard that it's less work to port the bytecode compiler to a new platform.
<hcarty>
jdavis_: Greater portability of the runtime, faster compilation
<ReachingFarr>
hcarty: How do I tell which modules need to be given to ocamlc and which don't?
<hcarty>
Str is another that requires it
<hcarty>
ReachingFarr: Unix and Bigarray both do, for example
<hcarty>
ReachingFarr: No, though there are a few modules shipped with OCaml which do require this
<hcarty>
I agree. It seems remarkably verbose.
<hcarty>
The last time I looked at ATS on the shootout the code was very difficult to follow due to lots of C mixed inline
<hcarty>
mfp: More straight ATS code than what I had previously seen
<hcarty>
mfp: Thanks for the link - that's much easier on the eyes
<hcarty>
I haven't checked since to see if it has improved
<hcarty>
mfp: When I last looked (several months ago), the ATS shootout code looked like it contained more C than ATS
<hcarty>
orbitz: HN?
2010-05-17
<derdon>
hcarty: ah, ok
<hcarty>
derdon: procedural or imperative were the two I meant :-)
<derdon>
hcarty: functional and imperative are rather different!
<hcarty>
imperative - whatever the proper term is
<hcarty>
as the functional, module and procedural parts of OCaml
<hcarty>
Type issues (not bugs, but added complexity) is at least part of why the object system is not as popular
<hcarty>
jonafan: You may need to do some manual type casting
<mehdid>
hcarty: ok, I'll subscribe then
<hcarty>
And thank you again for your time and help on this
<hcarty>
Otherwise, feel free to subscribe and follow along
<hcarty>
You can send me the patch to forward along if you don't want to subscribe
<hcarty>
I don't believe it does
<hcarty>
That makes sense.
<hcarty>
mehdid: Yes, it's my understand that it's not normal. But I'm not very familiar with Debian packaging methodology
<mehdid>
hcarty: hum... I see... the debian/ directory is included in upstream sources
<hcarty>
One of our developers is the Debian maintainer
<hcarty>
mehdid: Thanks - if you submit it to the PLplot dev list I'm guessing it would be happily accepted.
<mehdid>
hcarty: I wasn't efficient :) I started by giving him some advices, without looking at the code. But, that wasn't a good idea. I ended up compiling it on my computer to see what the problem was.
<hcarty>
mehdid: Thanks for helping the user who asked about PLplot!
<hcarty>
We're going to make a development/testing release some time soon, at which point I'll put out a request for testers and comments on the OCaml API.
<hcarty>
mehdid: :-) Yes - that's exactly why I wanted to update the Google Code page. The code and build method has changed more or less completely.
<mehdid>
hcarty: please ignore what I just said :)
<mehdid>
hcarty: isn't ocaml-plplot now integrated in plplot itself? and thus, officially supported?
<hcarty>
Hmm. I apparently need to make the message on the ocaml-plplot Google Code page more clear - that code is, and has been for a long while, old and unsupported.
<hcarty>
That's my understanding of env anyway
<hcarty>
animist: orbitz is likely correct. You could change you #! line to "#!/usr/bin/env ocaml" which will load the first "ocaml" found in $PATH
2010-05-15
<adrien>
hcarty should know but I guess he's currently away
2010-05-14
<derdon>
oh, I see hcarty has already answered your question ;)
<mehdid>
hcarty: true.
<hcarty>
mehdid: It likely has to be evaluated before whatever causes the backtrace
<hcarty>
derdon: Good point - thanks
<derdon>
hcarty: the environment variable doesn't need to be set if "Printexc.record_backtrace true" is written at the top of the file which has to be debugged
<hcarty>
orbitz: And OCAMLRUNPARAM=b in the environment
<hcarty>
orbitz: Yes
<hcarty>
derdon: Everything needs to be compiled with debugging enabled in order to get useful messages.
<orbitz>
hcarty: doyou ened debug symbols or somethign?
<hcarty>
derdon: (to address a comment from yesterday)
<hcarty>
derdon: Backtraces should work fine with compiled files, both byte and native code on 3.10.0 and newer
2010-05-13
<derdon>
hcarty: but not when the reference is declared locally in a function
<hcarty>
Insanity and despair lie down that road though :-)
<hcarty>
derdon: Passing values is generally the cleaner approach. You can modify a global reference if you really want to though.
<hcarty>
derdon: Excellent, glad to hear it
<hcarty>
flux: Probably so
<hcarty>
derdon: The easiest way to think about it is that the Print module is a replacement for the Printf module, but rather than using using OCaml's built-in printf-like string interpolation, it uses the pa_string syntax extension to create a more flexible/more easily extensible printing mechanism
<hcarty>
derdon: Yes, there is definitely a lot of overlap
<hcarty>
That's the error then :-)
<hcarty>
You need to use Print.printf and from the look of the error you are using Printf.printf
<hcarty>
derdon: Are you using Print.printf or Printf.printf?
<hcarty>
If you enter [1;2;3] in the toplevel, it will tell you it's a list int rather than an int list (if you are using a syntax extension)
<derdon>
hcarty: oh, nerver mind
<hcarty>
derdon: :-) - No, I meant the type reported by the toplevel gets changed
<derdon>
hcarty: I have to write "string list array" as the type, even in the ml-file
<derdon>
hcarty: ha! you lied! :P
<derdon>
hcarty: the error messages appear after executing the bash script
<hcarty>
derdon: Yes, or include the packages together as "-package batteries,batteries.pa_string.syntax"
<hcarty>
derdon: Can you pastebin your new compilation script?
<hcarty>
Though it doesn't seem to for this
<hcarty>
I suppose the order of arguments may matter
<hcarty>
This works for a simple test file on my system: "ocamlfind c -syntax camlp4o -thread -package batteries,batteries.pa_string.syntax -linkpkg test.ml"
<hcarty>
I thought that the "-syntax camlp4o" would do that part...
<hcarty>
derdon: I'm not sure - I normally do this with ocamlbuild :-)
<hcarty>
I think that is what you need
<hcarty>
Try adding this to your ocamlfind lines: -package batteries.pa_string.syntax -syntax camlp4o
<hcarty>
Nevermind
<hcarty>
derdon: Strange - that site isn't resolving for me
<hcarty>
:-)
<hcarty>
Ah, ok - if you paste the bash script to a pastebin that should help
<hcarty>
derdon: Are you using ocamlbuild?
<hcarty>
And camlp4o is needed
<hcarty>
The syntax extension is defined in the batteries.pa_string.syntax
<hcarty>
How are you compiling your program?
<derdon>
hcarty: do I have to pay attention to anything when I compile the file because of the use of syntax extensions?
<hcarty>
You're very welcome, glad it works!
<hcarty>
derdon: But only the types reported by the toplevel are affected - not the code you enter
<hcarty>
derdon: Not sure - it's a bug in some part of the system, either the toplevel, camlp4, findlib or the method Batteries uses to load the extensions
<hcarty>
derdon: Something along the lines of "Print.printf "%{string list array}\n" my_value"
<hcarty>
when syntax extensions are loaded
<hcarty>
derdon: You probably want "string list array" -- the toplevel gets messed up and uses revised syntax
<derdon>
hcarty: but I don't know how to specify the type "array (list string)"
<derdon>
hcarty: your example works well
<hcarty>
Most Batteries modules should support this (List, Hashtbl, etc.)
<hcarty>
The "p" before the string is what tells the syntax extension to dig in and do its thing
<hcarty>
derdon: Then you should be able to do "Print.printf p"%{int array}\n" [|1; 2; 3|];;" and get something very similar to "[|1; 2; 3|]" as output
<derdon>
hcarty: oh yes, the extensions are loaded in the toplevel
<hcarty>
Or if you use the Batteries-provided toplevel initialization code that should provide you with the syntax extensions as well
<hcarty>
derdon: You need to use camlp4 and the batteries.pa_string.syntax findlib package to enable the extension I think
<hcarty>
derdon: How are you using batteries? In the toplevel or from compiled code?
<hcarty>
derdon: This part of the estring syntax extension allows you to define your own printers for your own types and use them relatively easily
<derdon>
hcarty: I installed ocaml-batteries with apt-get in ubuntu 10.04
<derdon>
hcarty: I don't know whether the Batteries syntax extensions are enabled
<hcarty>
(BatPrint = Print if you "open Batteries" in your code, of course)
<hcarty>
derdon: If you have the Batteries syntax extensions in use (specifically estring) then you can type "BatPrint.printf p"%{int array}\n" [|1; 2; 3|]" to have nice array printed output.
<hcarty>
derdon: The BatFoo.print functions are for use with the BatPrint.*printf functions.
2010-05-12
<hcarty>
The toplevel can be helpful for things like this - if you see a lot of '_a where you expect 'a then it may be this same problem
<hcarty>
Adding the arguments explicitly to mem and possibly memm should get you closer at least :-)
<hcarty>
There's a FAQ about this somewhere ... the compiler, in effect, does not make functions polymorphic enough in some situations
<hcarty>
krankkatze: I think you need to add in the function arguments explicitly, rather than relying on currying
2010-05-11
<hcarty>
travisbrady: Good luck either way
<travisbrady>
hcarty: Yeah I saw that but I'm under a pretty tight timeline so I'm just going to use java. Thank you though
<derdon>
hcarty: thanks for the explanation, will try it out later
<hcarty>
derdon: Either using the value (RefList.add ref_list 1) or specifying the type in the definition (let ref_list : int RefList.t = RefList.empty ()) will fix the error.
<hcarty>
The value is not truly polymorphic, so the compiler is looking for more context to determine what the type should be. That is my non-scientific understanding.
<hcarty>
derdon: This would give the same error - "let hash = Hashtbl.create 1"
<hcarty>
derdon: This error doesn't have anything to do with Batteries
2010-05-07
<hcarty>
Lor: GSL provides a variety of PRNG schemes. I don't know how splittable any of them are though.
2010-05-06
<hcarty>
rovar_: Int32.t and Int64.t values are boxed
<hcarty>
rovar_, thelema: Indeed - it's much harder to ask "what was the previous month?" from a bare number
<hcarty>
It does make life just a little easier!
<hcarty>
It does tend to do a good job of being safe and internally self-consistent though.
<hcarty>
rovar_: But yes, the Calendar library does have a fairly significant initial learning curve, particularly if you are new to OCaml.
<hcarty>
rovar_: Module aliases are also a nice way to shorten what you have to type - "module C = CalendarLib.Calendar"
<rovar_>
hcarty, that seems to make sense from the API docs, I guess that just wasn't apparent because noone's bothered to actually document anything. at the high level
<hcarty>
rovar_: Calendar is built on functors from what I understand. So there is a lot of repetition in the interface to allow for customized representations of date/time information.
<hcarty>
rovar_: You can pattern match on all of the examples given so far
<rovar_>
hcarty, that would be more accurate, yes
<hcarty>
Or a "type a = B | C | ..." with a function "let int_of_a match x with | B -> 2 | C -> 5 | ..."
<hcarty>
The content of the message may be a little syntax-specific. But it will likely point to the correct place.
<hcarty>
Pointing to the code you wrote, rather than the underlying, transformed code.
<hcarty>
pozic: I'm not sure as I haven't used it. But it seems to be fairly well regarded, and most well-written syntax extensions still provide good error messages.
<pozic>
hcarty: pa_monad looks quite nice. How does that interact with error messages?
<hcarty>
pozic: Lwt is apparently monad-like in its design. There is a syntax extension called pa_monad which provides some extra syntax sugar for monads in general.
<hcarty>
pozic: I'm not familiar with it, but people do.
<hcarty>
Anyone here interested in a Google Wave invitation? I have several and no current use for them.
2010-05-05
<hcarty>
diml: Thanks!
<hcarty>
diml: Is there any special setup required for these completions? I'm only getting completion on keywords.
<hcarty>
It looks very interesting, but I haven't been able to try/test it properly yet.
<hcarty>
diml: Does the Lwt toplevel complete on anything beyond keywords?
<hcarty>
nfrs: Also look at the BatPrint module and the related syntax extension. It allows for wonderful things like (Print.printf p"%{int list}" [1; 2; 3])
<nfrs>
hcarty: I guess I'll stick with toplevel, if it's complex to do right
<hcarty>
nfrs: There is a "dump" function which will provide a generic string representation of a value
<nfrs>
hcarty: thanks
<hcarty>
nfrs: However, Batteries has some nice functions to help out
<hcarty>
nfrs: There is no fully generic printer in OCaml - the toplevel's printers are not directly available from user code as types are lost when code is compiled.
<hcarty>
Sounds good
<hcarty>
thelema: Thanks. I may be able to work on it, but I'm not sure if it would be before the release.
<thelema>
hcarty: if you want to finish the rest of the options, it should be straightforward (but tedious) to complete along the lines of the new printer_f/F
<hcarty>
I have thanked the original author before, but if they are around I would be happy to thank them again - I've found it to be a very useful tool.
<hcarty>
mehdid: Yes, but thelema fixed the float printing
<hcarty>
thelema: Woo! Thank you for the extra estring magic :-)
2010-05-04
<hcarty>
It does work for integers : (Print.printf p"%04d" 1) will print "0001"
<hcarty>
It is a long-standing issue with the estring syntax extension
<hcarty>
thelema: Yes - it is documented in the BatPrint documentation
<thelema>
hcarty: now I understand the request - you need parameterized float printing using Print.*
<hcarty>
The documentation said (says?) that it should work though, and it would need to in order to replace Printf.*
<hcarty>
mfp: It does work, but not with "% 5.2f" and similar directives
<mfp>
hcarty: p"..." is already supported
<hcarty>
Should bugs be reported on github or the forge?
<hcarty>
thelema: I'd like the consistent magic of Print.* :-) But it's beyond my current knowledge / time to take on at the moment.
<hcarty>
Though, writing that, I wonder if it is in the bugtracker... It was discussed on the list at some point, but that was pre-AAA.
<hcarty>
thelema: Any chance that the estring magic could be completed by 1.2 or 2.0? I don't know camlp4 well enough to do it myself, but it would be nice to have (Print.printf p"%05.2f" 1.234567) work correctly.
<mehdid>
hcarty: let me know if you make it work correctly :-) I think it could make an intesting useful package for newbies (if fixed correctly).
<thelema>
hcarty: no problem.
<hcarty>
thelema: Ah, thank you! I knew I was missing something.
<thelema>
hcarty: if the type actually has constructors in the implementation, but is presented in the interface as an uninhabited type in the spec, then it's an abstract type
<hcarty>
mehdid: Thanks for the patch. I'll take a look at it and see if I can get it to work.
<hcarty>
th5: I believe it's "abstract type"
2010-05-03
<mehdid>
hcarty: and then, you'll have to copy a space " " somewhere because otherwise, it would pop up a non working module menu :)