kaustuv changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.1 out now! Get yours from http://caml.inria.fr/ocaml/release.html
smimram has quit ["bli"]
<hcarty> thelema: It seems that another user tracked down the Batteries OSX problem to a specific commit. I added an Gzip module alias/entry to the Legacy module and that seems to be what kills it.
<hcarty> thelema: That is rather confusing though, since the gZip.ml code has not been referenced at that point in the file. So it should not, as I understand, interfere.
sporkmonger has quit ["Poof!"]
<thelema> yes, I noticed that bug report.
* thelema thinks we should try reverting that commit - why do we need Gzip in Legacy?
<hcarty> Without that alias, there is no way to reach the original Gzip module under default Batteries use.
<erickt> hcarty: that was me! :)
<hcarty> The Batteries Gzip does not (or did not at the time of the commit) cover the full range of functionality in the parent module
<hcarty> erickt: Wonderful!
<hcarty> erickt: Care to try a little experiment? :-)
<erickt> i'm good at breaking things
<erickt> sure
<hcarty> Reported breakage is quite appreciated.
<erickt> thelema: I did revert that commit I mentioned and got batteries to compile
<hcarty> Could you try changing the "module Gzip = Gzip" lines to "module Gzip_original = Gzip"?
<thelema> thank you erickt for tracking that down.
<hcarty> And my apologies for commiting a compilation-breaking change.
<erickt> s'ok :)
<thelema> hcarty: no apologies necessary - that change shouldn't have broken anything.
<hcarty> thelema: It seems like this is either a build system bug (ocamlbuild or myocamlbuild.ml) or a bug in ocaml(c|opt). It really should not be looking for gzip.cmi in the build tree at that point.
<hcarty> Or, ever I suppose.
<thelema> yes, that's exactly what I'm thinking.
<erickt> well since osx/hfs is case insensitive, it may be finding another file named gzip.cmi on it's search path
<erickt> and hcarty, that rename doesn't fix it
* thelema guesses that possibly our gzip and the builtin gzip are colliding
<thelema> and only if the builtin gzip is included does this problem surface
<erickt> rename src/libs/camlzip/gZip.* to extGZip?
<thelema> yes, that's the workaround
<thelema> if I'm right.
<hcarty> erickt: Thanks for trying. It was something of a stab in the dark :-)
<hcarty> erickt: The rename could be to extGzip.*, which would keep with the existing ExtFoo naming convention used in the rest of Batteries. Regardless, it would be wonderful if that would work.
<hcarty> I suppose this could be an issue on Windows as well.
<erickt> hcarty: that seemed to work
<erickt> though now I need to install ocamlnet...
<hcarty> erickt: Thank you very much for your detailed testing and reporting on this.
<erickt> no problem :)
<thelema> erickt: send me something I can "git am" to give you credit.
<erickt> unfortunately I'm probably not going to be able to use batteries, at least until it becomes common. the head guy on my programming language, felix, doesn't want to link with LGPL stuff, just BSD stuff :(
<erickt> telling him that the ocaml standard library is LGPL didn't convince him either
<erickt> now, would you prefer extGzip, or extGZip?
<hcarty> erickt: extGzip.* and "module Gzip = ExtGzip" would probably be best. The other ExtFoo modules are named that way to match upstream.
<hcarty> erickt: Or, rather, "module Gzip = Gzip" in Legacy and "module Gzip = ExtGzip" in the main Batteries module.
<erickt> what about innerGZip?
<erickt> I can rename that too
<hcarty> erickt: Sounds reasonable, as long as the build holds together.
<thelema> erickt: innergzip -> innerextgzip? ick.
<Modius> Is there the concept of identity equality (reference comparison/check if something is the same instance) in OCaml? How do I do it? Is it possible to have a hashtable based upon this?
<hcarty> I was thinking innerGzip. I'm not sure which would be appropriate.
<thelema> Modius: == does identity equality
<thelema> Modius: = does value comparison, recursing into complex structures)
<hcarty> Though perhaps innerGZip.ml should be included as a module in extGzip.ml and hidden by extGzip.mli.
<hcarty> erickt: Not that you should do have to do all of that :-)
<thelema> hcarty: if that was reasonable, why would innergzip exist in the first place?
* thelema recalls innerGzip being created because something outside gzip needed it.
<hcarty> thelema: Ah, ok. That would make sense.
<hcarty> In that case, innerGzip.(ml|mli) is probably a reasonable name. Though that could break whatever code depends on it.
<erickt> thelema: was it something outside batteries?
<erickt> because only gZip.ml references InnerGZip
<erickt> inside the source tree
<thelema> it would have been inside batteries.
<thelema> hmm, maybe I'm misremembering...
<thelema> maybe it's just mirroring IO / InnerIO
<thelema> but I thought there was a technical need for it...
<thelema> -- a forced design choice, not a stylistic choice
<hcarty> Commit ac7abc14658150f3065cbe03c54107dcd4996943 - according to the commit comment, it was a style choice. The module was originally called ExtGzip.
<thelema> hcarty: thanks for finding that. Ok, let's go ahead with renaming it
<Modius> thelema: Is there a way to have a hashtable based upon reference as the key rather than object equality?
<hcarty> A safe first step should be GZip -> ExtGzip and InnerGZip -> InnerGzip. We can move file contents around after that, if there's reason to do so.
<erickt> I'm just running a full recompile, then I'll mail in the patch
<thelema> Modius: do you want to hash the pointers?
<Modius> thelema: Basically.
<thelema> Modius: may I ask why?
<erickt> hcarty: mailed to batteries-devel
<Modius> thelema: Something I'm playing with where identity is the key. It's actually in F#, I'm hoping there's an equivalent for what you will tell me in F#.
<thelema> erickt: sorry, but I don't approve of the whitespace cleanup in your first patch - lining up equals signs doesn't make for good code, imnsho
<erickt> i agree, but i was just matching the style in that file
<thelema> the reasoning is the same as "No beastly alignment of the -> symbols in pattern-matching clauses. " from http://caml.inria.fr/resources/doc/guides/guidelines.en.html
<erickt> i noticed that some of the whitespace was off, so i fixed it
<erickt> feel free to ignore it :)
<hcarty> We unfortunately don't have the equivalent of perltidy for OCaml.
<erickt> did you get the other patch?
<thelema> not yet. too big for list?
<erickt> yeah
<erickt> I could put it on pastebin.com
travisbrady has quit []
<erickt> ping hcarty
<erickt> also, have you guys looked into the ocamllex problem I was having?
<thelema> gimme a sec to reproduce it - I saw it, but don't use ocamllex much.
<thelema> hmm, I'm getting a wierd git error...
<thelema> Applying: Rename camlzip files to work on OS X.
<thelema> fatal: git apply: bad git-diff - expected /dev/null on line 26
<thelema> hmm, I don't reproduce your ocamllex bug...
<erickt> oh thats right I couldn't test it against the head of git
jeddhaberstro has joined #ocaml
<erickt> thelema: do you know how I can test with dev version of batteries?
<thelema> you mean like [make reinstall]-ing the git head?
<thelema> or you mean without wiping out your current install of batteries?
<erickt> well, do I have to install it in order to test it?
<erickt> yeah, the second one?
<thelema> yes, you have to install it.
<thelema> we're working on running from the source tree's copy (for testing pre-install), but not yet.
<erickt> oh that's too bad. hard to test that way
<thelema> findlib doesn't do much for non-installed packages.
<erickt> hrm, ocamlfcore.org's git server is slow
<thelema> if you have any suggestions, the admins are reasonably responsive, even if they're not experts at every version control system out there.
<erickt> oh I'm sure it's just overloaded
* thelema is surprised there'd be that much load - OCaml isn't *that* popular.
<thelema> plus it's early morning in the part of the world that OCaml is most popular
<erickt> maybe the server's in france?
<thelema> it is. but git should be pretty good over high latency connections
<hcarty> erickt: If this doesn't get resolved now, could you post the information and patch you have (with a note that it is not against the latest git) to this bug: https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=235&group_id=17&atid=151
<hcarty> thelema: If you are able to continue on this please do. I have a few things to finish up this evening and likely won't be able to get back to this for a few days.
<thelema> ok.
<thelema> erickt: attach files below "related tasks"?
<erickt> I don't have that
<erickt> maybe it's only turned on for developers?
<thelema> maybe...
<erickt> anyway, I made a separate bug with the patchfile here: https://forge.ocamlcore.org/tracker/index.php?func=detail&aid =241&group_id=17&atid=153
* thelema tries applying
<thelema> and then building
<erickt> oh neat, the ocamllex bug was fixed
<erickt> I'll reply to my email
<thelema> ok, your patch compiles fine - I'll commit it.
<thelema> pushed.
<erickt> great!
<thelema> grr, bad commit
<erickt> how odd
<erickt> where'd my files go...
<thelema> no, my fault - patching modified existing files, and I just did [git commit -a]
<thelema> which didn't add the new files.
<erickt> oh and you probably should sign off on those commits
<thelema> as the committer, I think there's an implicit signoff
<thelema> we don't really use the commit signing, as there's a central repo, and signing doesn't need to move from one repo to another.
<erickt> oh lookie there
* thelema would rewrite the history if that weren't pretty much guaranteed to break someone.
peddie has joined #ocaml
jeddhaberstro has quit [Client Quit]
peddie_ has quit [Read error: 113 (No route to host)]
mpwd has quit [Read error: 110 (Connection timed out)]
sgwizdak has quit [Read error: 104 (Connection reset by peer)]
<erickt> thelema or hcarty, either of you still around?
<hcarty> erickt: Somewhat
<erickt> Oh, I noticed that Scanf.fscanf takes an in_channel instead of an IO.input
<erickt> and I was wondering what's the deal between the too :)
<erickt> is in_channel/out_channel being kept for legacy purposes?
<hcarty> erickt: I havne't worked with the IO or Scanf modules, but if you post to the list and add a bug report it should be addressed.
<hcarty> My guess is that it was an oversight. But it's possible that there is some other reason for this.
<erickt> I was in the middle of writing a bug report when you came back :)
<hcarty> erickt: Ah, then don't let me stop you :-)
<erickt> cool, got all of felix, dypgen, and ocs to compile with batteries
<erickt> of course, it doesn't work though :(
<erickt> code doesn't properly handle the changes in exceptions yet
<hcarty> erickt: Yes, the changes to raised exceptions are something of a barrier.
<hcarty> That said, the Batteries exceptions tend to be clearer and more consistent. Also, the Exceptionless modules are quite when you can use them.
<erickt> ah, another bug: Unix.descr_of_output doesn't work with stdout
<hcarty> Clearer and more consistent than the OCaml stdlib that is. And that is, of course, an opinion.
<hcarty> Hooray for expanded testing!
<hcarty> I'm off for the night. Best of luck erickt, and thanks again for your reports and debugging.
<erickt> gnight :)
Submarine_ has joined #ocaml
animist has quit [Remote closed the connection]
<gildor_> thelema, erickt, hcarty: load average on the server is 0.00
<gildor_> (on forge.ocamlcore.org)
<gildor_> thelema, erickt, hcarty: but ovh.net seems to have network trouble since a few day
<gildor_> thelema, erickt, hcarty: maybe they are doing some work at night (in france) that make the server less responsive
<gildor_> gildor_: we have also identified some DNS problem that I don't know how to solve (DNS delegation to secondary server doesn't seem to work)
<gildor_> thelema, erickt, hcarty: this kind of DNS problem can lead to some problem (but it should be something like no connectivity at all)
animist_ has joined #ocaml
tsuyoshi_ is now known as tsuyoshi
animist_ has quit [Read error: 110 (Connection timed out)]
<erickt> thanks gildor_
<erickt> sweet, once I hacked around batteries's stdin not working with Unix.get_descr_for_input, felix actually compiles and runs
sciendan has quit [Read error: 113 (No route to host)]
<gildor_> erickt: 3-4 hour in the morning could also be the time where cron job start (backup, backup transfer to other host)
animist has joined #ocaml
X-Scale has quit ["Time left until the Epochalypse: 28yrs 26wks 5days 19hrs 8mins 2secs"]
<hoffa_> Functionnal programming is very hard to catch and get used to for a C programmer, should I-
smimou has joined #ocaml
<hoffa_> leave OCaml for the moment, or ?
<schme> hoffa_: That is not likely to make you catch it faster ;)
<hoffa_> Before I answer that, is functionnal programming a big deal in OCaml ?
<hoffa_> I guess so
<schme> hoffa_: You can do your best to avoid it, but it is better to just enjoy it :)
hkBst has joined #ocaml
<hoffa_> Hmm, yes, or no. Well I guess I won't continue OCaml anymore, but it's fine for me, wanted to try something new, but this didn't taste really good.
<hoffa_> Functionnal is not really my thing
<hoffa_> Ok I'm off, bye
hoffa_ has left #ocaml []
<schme> heathen!
LeCamarade|Away is now known as LeCamarade
sramsay has joined #ocaml
BiDOrD has quit [Read error: 110 (Connection timed out)]
BiDOrD has joined #ocaml
ulfdoz has joined #ocaml
Submarine_ has quit [Client Quit]
sramsay has quit [Remote closed the connection]
X-Scale has joined #ocaml
smimou has quit ["bli"]
tsuyoshi has quit ["Lost terminal"]
animist has quit [Remote closed the connection]
animist has joined #ocaml
<sgnb> erickt: it's LGPL with an exception that lets you do pretty much anything
th5 has joined #ocaml
Amorphous has quit [Read error: 113 (No route to host)]
Spiwack has joined #ocaml
Amorphous has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
hkBst has joined #ocaml
_andre has joined #ocaml
cygnus_ has quit [hubbard.freenode.net irc.freenode.net]
amuck_ has quit [hubbard.freenode.net irc.freenode.net]
jimmyb2187 has quit [hubbard.freenode.net irc.freenode.net]
acatout has quit [hubbard.freenode.net irc.freenode.net]
mattam has quit [hubbard.freenode.net irc.freenode.net]
mattam has joined #ocaml
acatout has joined #ocaml
cygnus has joined #ocaml
jimmyb2187 has joined #ocaml
<rwmjones> # let world' = "large" ;;
<rwmjones> val world' : string = "large"
<rwmjones> # `Hello world' ;;
<rwmjones> - : [> `Hello of string ] = `Hello "large"
<rwmjones> hmmmmmm
<thelema> heh. That'd be amusing for some kind of obfuscated ocaml
<kaustuv> type 'a world' = unit
<kaustuv> let x : 'hello world' = ()
<kaustuv> let f : 'hello world' -> 'goodbye world' = failwith "adieu"
komar_ has quit [Read error: 60 (Operation timed out)]
aklt has joined #ocaml
<thelema> kaustuv: ricards' is better for obfuscation - it actually does something. yours... is just types, which only can cause a program not to compile.
<kaustuv> fine:
<kaustuv> let f : 'hello' -> 'goodbye' = function
<kaustuv> | "hello" -> "goodbye"
<kaustuv> | _ -> invalid_arg "not a hello"
<thelema> I admit your last example is pretty.
<thelema> okay, you get some points for a false signature...
<rwmjones> we were just discussing the fact the ' is a little-known alternative for :: in Perl
<rwmjones> eg:
<rwmjones> use Data'Dumper;
<kaustuv> strictly speaking, anything is an anything in OCaml if you allow Camlp4
<thelema> built-in != pre-processed
<kaustuv> But since Perl is homoiconic, what is the difference?
<thelema> homoiconic because it has eval?
<kaustuv> I might be misremembering, but can't you do the LISP-equivalent of '(...) in Perl?
<thelema> "print $foo"?
<kaustuv> Well, what I mean is, can you write Perl code that extends the syntax of Perl? It must be possible because there is the famous example that changes the syntax of Perl to look like Latin...
<thelema> yes, there's apparently some ways to change the parser on the fly, as well as some other hooks... http://search.cpan.org/~ash/Devel-Declare-0.005007/lib/Devel/Declare.pm
komar_ has joined #ocaml
animist_ has joined #ocaml
willb has joined #ocaml
animist has quit [Read error: 113 (No route to host)]
Submarine_ has joined #ocaml
bombshelter13_ has joined #ocaml
th5 has quit [Read error: 104 (Connection reset by peer)]
Associat0r has joined #ocaml
verte has joined #ocaml
leondz has joined #ocaml
<leondz> hi! i am a complete newbie, trying to get a toolkit to run, and a little lost. I'm stumped by "Reference to undefined global `Bigarray'"
<Camarade_Tux> leondz: what are you doing : compiling (ocamlc or ocamlopt) or using the toplevel (ocaml)
<leondz> i'm using the toplevel
<leondz> although I've used the makefile that comes with the toolkit, i'm really not sure where to start
<leondz> sorry to trouble you with such a trivial thing
<Camarade_Tux> leondz: which toolkit is it btw?
<Camarade_Tux> and for bigarrays, you need to load the corresponding modules : for you the best thing is probably to type : #load "bigarray.cma";;
<leondz> carafe; http://sourceforge.net/projects/carafe/ - i'm trying to get maxeml working
<kaustuv> leondz: carafe 0.9.2.1 builds for me on a vanilla OCaml 3.11.0 release on Debian unstable. You just have to edit the Makefile to make OCAMLBIN point to /usr/bin and OCAMLBUILDLIB to /usr/lib/ocaml/3.11.0/ocamlbuild
X-Scale has quit [Connection timed out]
<leondz> thanks! yes, i managed to build it too. the #load statement is very helpful too, although there appear to be a number of cases, when executing (in maxeml/) ocaml mtrain.ml, where various source files are failing to pick up references to other classes/objects in the local directory
<leondz> do you think it's simply code that i need to barge in and fix, or a badly set up environment, or something else?
<leondz> (i'm running 3.10.2 on ubuntu 9.04)
Lomono has joined #ocaml
<kaustuv> I am pretty sure running "ocaml maexml/mtrain.ml" won't do anything sensible. I think you are meant to use one of the *.native programs that is produced by running "make native"
<hcarty> leondz: If other files are used, they need to be somehow explicitly referenced. They will not be picked up automatically by the toplevel.
<Camarade_Tux> 'ocaml myfile.ml' will (almost) silently execute myfile.ml
<leondz> maxeml isn't part of the main package
<leondz> i think i should probably embarrass myself in front of the author for support, rather than trouble you guys
<kaustuv> leondz: I think I've managed to build maxeml/mxtrain.ml. You need to create a file named _tags in the maxeml directory containing the following lines:
<kaustuv> <*.byte> : use_str, use_bigarray
<kaustuv> <*.native> : use_str, use_bigarray
<kaustuv> then run "ocamlbuild maxeml/mxtrain.native"
<kaustuv> This will produce a binary named mxtrain.native in the current directory
<kaustuv> If you have access to the author, bug him about adding the maxeml/ programs to the default "make all" target.
TR2N has joined #ocaml
<leondz> aha, fantastic! thank you very much
<leondz> i certainly will document these steps
<leondz> very kind of you all to help :)
TR2N is now known as X-Scale
<leondz> right, I've forwarded on the comment. thanks to you all again.
leondz has left #ocaml []
<kaustuv> (Why do people insist on torturing ocamlbuild so much? 99% of the Makefile in that project is redundant.)
mpwd has joined #ocaml
amuck_ has joined #ocaml
Associat0r has quit []
Submarine_ has quit [Remote closed the connection]
LeCamarade is now known as LeCamarade|Away
Lomono has quit ["Don't even think about saying Candlejack or else you wi"]
mpwd has quit []
Submarine has joined #ocaml
verte has quit ["~~~ Crash in JIT!"]
travisbrady has joined #ocaml
_zack has joined #ocaml
AxleLonghorn has joined #ocaml
Spiwack has quit ["Leaving"]
julm has quit [".."]
_zack has quit ["Leaving."]
AxleLonghorn has left #ocaml []
sramsay has joined #ocaml
julm has joined #ocaml
oc13 has joined #ocaml
oc13 has left #ocaml []
<erickt> sgnb: oh I know, just the head guy doesn't want to depend on anything that a commercial person couldn't modify without releasing
<Camarade_Tux> there's the caml consortium too :)
<erickt> I'm not sure if batteries would be covered by that
aklt has quit [Read error: 110 (Connection timed out)]
<Modius> In idiomatic pretty professional OCaml, what (if any) casing convention is used for a union type where the same name is used for the discriminator and the type? E.g. type Something = | Blah of blah <-- is that the casing convention?
<Modius> Sorry if this sounds naive, I just want to know how this sort of thing is handled in "normal" code. FWIW I'm asking about F# but assume it's an issue from OCaml
<hcarty> Modius: What do you mean by "casing convention"?
<Camarade_Tux> Modius: an identifier that starts with an uppercase letter *has* to be an union member
<Camarade_Tux> erickt: not really likely
<Modius> Comrade_Tux: Well that settles THAT :)
<hcarty> No, the Batteries license would not be changed a consortium membership. I certainly hope not anyway :-)
<Camarade_Tux> Modius: and the other way round : an union member name has to start with an uppercase letter
<Camarade_Tux> polymorphic variants (like `my_variant or `My_variant) don't obey this rule afaik
<Modius> Camarade_Tux: But a type can start with a cap too can't it? Or is a type itself just a discriminator in a wider context?
<Camarade_Tux> Modius: you can try in the toplevel :
<Camarade_Tux> # type A = B of int;;
<Camarade_Tux> Error: Syntax error
<Modius> Camarade_Tux: Sorry, this may be an F# idiosyncracy. Is there a page where I can see either the casing rules of OCaml, "best practices" cosmetics guide for OCaml, or maybe some good/reference code?
<hcarty> Camarade_Tux: My understanding is that `foo is not supposed to be accepted, but is currently due to a bug somewhere in OCaml.
<hcarty> I don't know if/when it will be fixed though, as it has been around for quite a while.
<Camarade_Tux> hcarty: good to know
<Modius> http://www.cs.caltech.edu/~cs20/a/style.html <-- There's a style guide here - is there a better one or is this generally the road to pretty OCamlish code?
<Camarade_Tux> hopefully I've always used the capitalized version :)
<jonafan> i wanna write ocaml code
<Camarade_Tux> ocaml code : '()' =)
_andre has quit ["*puff*"]
Associat0r has joined #ocaml
mgodshall has joined #ocaml
slash_ has joined #ocaml
jeddhaberstro has joined #ocaml
<hcarty> julm: Good find.
komar_ has quit ["WeeChat 0.2.6.3-ohshi"]
bombshelter13_ has quit []
Lomono has joined #ocaml
Submarine has quit [Remote closed the connection]
Associat0r has quit []
hkBst has quit [Read error: 104 (Connection reset by peer)]
ulfdoz has quit [Read error: 110 (Connection timed out)]
sramsay has quit [Remote closed the connection]