<hcarty>
rwmjones: What is the URL for the Fedora OCaml packaging repository? (.spec files and patches)
2009-04-04
<hcarty>
Oh my, this is unfortunate... the lead BitC person is apparently leaving the project
<mrvn>
hcarty: \ requires hitting alt-gr
<hcarty>
I don't know if that is a good idead though
<hcarty>
Yes, my intent with the above is that _ alone and \n, but not _n
<hcarty>
(\_ + \3) if you want to mix everything up terribly
<bluestorm>
hcarty: i got it first :-'
<hcarty>
thelema: They could be stacking extensions
<bluestorm>
hcarty: (\_2) would work if you use _2
<hcarty>
Versus \(_2) (if the leading _ is going to be used)
<hcarty>
Would (\_2) work?
<hcarty>
Which I think may be somewhat important, since the language changes inside of that delimiter
<hcarty>
A leading \ makes it stick out a bit more
<hcarty>
bluestorm: I still find it easier to spot
<bluestorm>
but hcarty
<hcarty>
bluestorm: It reads a little clearer IMHO -- but tuareg problems carry a lot of weight in this community :-)
<bluestorm>
hcarty: \(...) would probably be possible
<bluestorm>
hcarty: would be possible
<hcarty>
Is \( ... ) possible? That would avoid (\\1) clashes in the current pa_holes - assuming they exist as-is
<hcarty>
I don't know how this applies to keyboards in other regions, but the lazy typist in me likes that fact that \ doesn't require hitting shift, while _ does
<hcarty>
Bacta: Yes?
2009-04-03
<hcarty>
mrvn: Sorry, that's not a direct link... the module is String.Cap
<hcarty>
mrvn: I don't know, but they are there :-)
<hcarty>
Batteries has r|w|rw strings
<hcarty>
mrvn: I don't think that will work without a separate signature definition
<hcarty>
oof: It looks like you could either take snapshots of the default state using Random.get_state, or make new ones with Random.State.make or .make_self_init
<hcarty>
j_lenorm: godi_console -> Select souce package -> lablgtk2 -> configure -> use gl = no
<hcarty>
j_lenorm: You'll likely have to clear the other labl* and conf* packages godi set as dependencies by hand as well
<hcarty>
j_lenorm: I don't remember the specific options, but it's in the godi configuration for the lablgtk2 package
<j_lenorm>
hcarty: how?
<hcarty>
j_lenorm: You can disable the opengl portion of lablgtk2 and that should avoid the need for lablgl and labltk
<hcarty>
The godi/build/ dir is 110+ of that
<hcarty>
So you're likely safe there
<hcarty>
j_lenorm: I have a lot installed under my godi dir and it is only up to 454 megabytes
<j_lenorm>
hcarty: as long as its less than 500 megs, It should be ok
<j_lenorm>
hcarty: probably
<hcarty>
j_lenorm: godi is big because it includes a lot?
2009-03-30
<hcarty>
j_lenorm: It should be called "ocaml-omake"
<hcarty>
Then you may have to compile it on your own, unless you can get someone with admin rights to install it for you
<hcarty>
"yum search omake" should find it
<hcarty>
It should be in Fedora, at least for recent versions
<hcarty>
j_lenorm: As in RHEL?
2009-03-29
<hcarty>
If not, then perhaps I should remove them from Seq.Exceptionless
<hcarty>
Also nth, reduce, min, max
<hcarty>
Should List's hd, tl, first, last be added to Exceptionless?
<hcarty>
That makes sense
<hcarty>
Yoric[DT]: Ok, cool
<Yoric[DT]>
hcarty: I believe that it should be allowed to raise Invalid_arg exceptions.
<AxleLonghorn>
hcarty: how do you write one?
<hcarty>
I imagine you could go as deep with nesting as you want
<hcarty>
AxleLonghorn: Higher order functors are supported
<hcarty>
Also, Jérémie Dimino++ for the Batteries.Print module and related syntax. That thing is downright nifty.
<hcarty>
Yoric[DT]: Should Array.(make|init|get|set) be allowed to throw exceptions in the Array.Exceptionless module?
<jado>
ok hcarty thanks
<hcarty>
jado: pa-do allows one to define postfix operators (among many other things).
2009-03-28
<chahibi>
hcarty, , thanks
<hcarty>
chahibi: You can use rlwrap or ledit to gain line editing with the ocaml toplevel
2009-03-27
<hcarty>
So having a consistent and fixed exception structure for Batteries is, I think, worth focusing on
<hcarty>
I was bitten several times when switching code from the stdlib to Extlib by differing exceptions
<hcarty>
mrvn: Indeed
<hcarty>
thelema: Ok, sounds good. I didn't know how strict the API freeze would be post-beta
<thelema>
hcarty: I'd say it's something that can be fixed even in beta.
<hcarty>
thelema_: Or is this something that would be better to bring up on the list?
<hcarty>
thelema_: Is exception use consistency a Batteries pre-beta concern?
<hcarty>
You are quite welcome as well. I'm glad to be able to take part in the process.
<hcarty>
s/that/the/
<hcarty>
I'm off for that night. Thanks again for your assistance in getting setup with this thelema_ and the code review(s)
<hcarty>
thelema_: Pushed
<hcarty>
Cool, thanks
<hcarty>
Yes
<hcarty>
thelema_: All except make and init
<hcarty>
thelema_: I hope this isn't too many Batteries questions -- I don't want to overstep any boundaries
<hcarty>
thelema_: I have an Exceptionless module for Seq. Would it step on any toes to push it now?
<hcarty>
I'm not sure where though
<hcarty>
I think I have the PDF sitting around somewhere
<hcarty>
thelema_: As of now it throws an exception, along with several other similar functions
<thelema_>
hcarty If we're doing exceptionless right, Array.make will return a variant (probably polymorphic) giving (`OK of array | `Other_exception | `Exception2]
<hcarty>
thelema: Should Array.make (and other similar functions in other modules) throw exceptions on invalid arguments when using the Exceptionless module?
<hcarty>
tar_: LACAML or ocamlgsl may have something
2009-03-26
<Yoric[DT]>
hcarty: well, thanks for doing the actual job.
<hcarty>
mfp, thelema: Ok, thank you
<mfp>
hcarty: (in local) git rebase -i master git push origin local:master to rebase your patches
<thelema>
hcarty: thank you for your patch
<hcarty>
thelema, Yoric[DT]: Thank you for your assistance in getting this setup
<hcarty>
Nevermind, it seems to have worked properly
<hcarty>
I remember some discussion on here a while ago about avoiding extraneous merge messages, but I don't remember the result
<hcarty>
What is the proper localbranch -> master -> forge process? (on master) "git merge local && git push"?
<thelema>
hcarty: push onwards.
<hcarty>
If this is acceptable to both of you then I can push the changes for Array, List and Enum
<hcarty>
Foo.Labels.LExceptionless rather than Foo.Labels.Exceptionless avoids that. LExceptionless are labeled, exceptionless functions
<hcarty>
Otherwise OCaml complains about multiple modules names Exceptionless
<hcarty>
Yoric[DT]: That is it, thank you
<hcarty>
If you weren't around, thelema suggested using Foo.Labels.LExceptionless to allow "module Foo = Foo with Labels, LExceptionless" to avoid the value masking issue
<hcarty>
Yoric[DT]: For Batteries on the forge
<hcarty>
Yoric[DT]: Do you know the directory to git clone for dev access?
<hcarty>
mrvn: Ah, ok
<mrvn>
hcarty: you call that, it emidiatly returns. 10s later the kernel starts getting the data and dumps it into the string.
<hcarty>
Or perhaps I am misunderstanding the issue
<hcarty>
mrvn: Isn't that what the "if (foo = NULL) ..." deals with?
<mrvn>
hcarty: caml_named_value(n) gives you a pointer to the value. I can get a pointer to the string that way but in libaio the kernel writes directly into the string. If the GC moves it at that point then bad stuff happens.
<mrvn>
hcarty: exporting a symbol still lets the GC move it around.
<hcarty>
mrvn: Yes
<mrvn>
hcarty: you mean exporting a symbol globally?
<hcarty>
It would be nice if it were simpler though
<hcarty>
mrvn: Does the existing C callback structure not work for what you are doing?
<hcarty>
mrvn: There is an OCaml compiler patch around somewhere that adds the ability to use multiple record types with the same field names. But I think it's for an older version of OCaml
<hcarty>
itewsh: This is all covered in the OCaml manual intro and the tutorial. To sum up though, "ocamlc test.cma foo.ml -o foo" and "Test.myfunc 1 2"
<itewsh>
hcarty: okay, but when I got my ".cma" file, am I able to use it (with "ocaml -I +test.cma")? Moreover, How do I have to declare the function inside the library? (I suppose with a ".mli" file?)
<hcarty>
itewsh: I think you'd want to use "ocamlc -c test.ml" (or ocamlopt) rather than ocamlmklib though
<hcarty>
itewsh: "ocamlbuild test.cma" or "ocamlbuild test.cmxa" is one way. http://ocaml-tutorial.org/ has more information
<hcarty>
Yes
<hcarty>
Sure
<hcarty>
Yes
<hcarty>
I don't have commit access, so I'll submit it to the mailing list
<hcarty>
It compiles and seems to work cleanly here.
<thelema>
hcarty: looks good on visual inspection - assuming the compiler likes it, I'd commit.
<hcarty>
It add the Labels.LExceptionless modules to Array and List, and adds List.Exceptionless.find
<hcarty>
thelema: My proposed idea will not work, as List.Labels does not contain all of the List module functions, only the labeled ones.
<thelema>
hcarty: yes, with sufficient documentation
<hcarty>
thelema: Would "module List = List.Labels with Exceptionless" working but not "module List = List with Labels, Exceptionless" working be acceptable?
<hcarty>
I'll try to look at it again later
<hcarty>
Error: Multiple definition of the module name Exceptionless. -- when trying "module List = List with Labels, Exceptionless;;"
<hcarty>
Drat, that does not seem to work
<hcarty>
Should I submit to the list or the bug tracker?
<hcarty>
thelema_: I'm finishing up and testing the patch now. I'll submit a git-diff as soon as it's ready?
<hcarty>
thelema: Ok, will do. I just wasn't sure of the preferred way to report something like this
<hcarty>
mrvn: I would think so too, or Empty_list should go and be replaced by Invalid_argument "..."
<hcarty>
The (very) newly checked in Seq module seems to use the Failure exception in a few places. I was going to suggest or submit a patch with a different choice. But when I checked List I saw that there doesn't seem to be a clear standard
<hcarty>
(example: List.hd [] would raise Empty_list, but List.reduce [] would raise Invalid_argument "List.reduce: empty list")
<hcarty>
thelema: Should this be raised as a bug report, or some other way?
<hcarty>
thelema: There seem to be a lack of consistency in the choice of exceptions thrown in Batteries modules
2009-03-23
<hcarty>
Camarade_Tux: In bytecode, native or both?
<hcarty>
Which means what mrvn said
<hcarty>
koppology: It is probably using the same seed each run
<hcarty>
koppology: That may have changed in more recent versions though
<hcarty>
koppology: I think Batteries currently assumes some Debian and/or Gnome tools for finding the proper web browser for documentation
2009-03-21
<hcarty>
Or that!
<hcarty>
xahlee: match m with (x, y) when x = 3 && y = 4-> x + y
2009-03-19
<hcarty>
Done
<hcarty>
Yoric[DT]: Should I still submit a bug report?
<hcarty>
Sure
<hcarty>
Yoric[DT]: "ocamlfind batteries/ocaml" does not seem to use ~/.ocamlinit on my system (GODI, OCaml 3.11, latest Batteries from git as of a few hours ago)
<Yoric[DT]>
hcarty: normally, .ocamlinit should work.
<hcarty>
Is there a .ocamlinit equivalent for the Batteries toplevel?
<hcarty>
Yoric[DT]: Ok, thanks. I'll ask about the Print.* syntax on the list
<Yoric[DT]>
hcarty: for the first question, you should ask on the mailing-list, to Jérémie.
<Yoric[DT]>
hcarty: well, timeline was supposed to be one or two days ago.
<hcarty>
And why is the Exceptions module named Exceptions rather than Exception?
<hcarty>
Two questions on the Batteries details: Why are the %(list foo) arguments in the "revised syntax" order rather than standard syntax order?
<hcarty>
Yoric[DT]: Is there a current checklist and/or timeline for the Batteries beta 1 release?
<Yoric[DT]>
hcarty: pong
<hcarty>
Yoric[DT]: ping
<burton_>
hcarty: in my distribution (archlinux) there are no -dev packages, everything is in the normal
<hcarty>
burton_: You probably need the lablgtk2-dev package + dependencies as well
2009-03-17
<hcarty>
thelema: Would a reduce, min, max and sprint patch for Batteries.Array be accepted for pre-beta1?
2009-03-16
<hcarty>
For that reason, it is generally considered proper to write all operators that way ... ( + ), ( - ), etc
<hcarty>
peper: ( * )
<hcarty>
peper: A class would be more computationally expensive than a record or array
<hcarty>
thelema: ping
2009-03-15
<hcarty>
flux: I don't think the OCaml Cairo bindings come with a META file. The Debian folks wrote one, and I think Fedora based theirs off of the Debian one
<hcarty>
That may not be any better, but I think the Cairo bindings depend on the Bigarray library
<hcarty>
Cairo.move_to should be there ... you can check the sources to be sure, but unless something very strange happened it should be there
<hcarty>
I haven't used any of the OpenGL bindings with lablgtk
<hcarty>
You could try ocamlc rather than ocamlopt
<peper>
hcarty: i tried names like foo and it still didn';t
<hcarty>
The problems I have had with the Cairo bindings have all been compile time problems, and mostly with the native code compiler
<hcarty>
peper: If the compiler doesn't find the library then it should give you an error
<peper>
hcarty: hmm i can't get it working ;/ any hints on how to use opengl with lablgtk?
<peper>
hcarty: hmm, it installs the files as i showed you. not sure what;s wrong
<hcarty>
peper: You may have to play around with it a bit on your system. An official release of the bindings has never been made. The build system may have a few bugs lurking around.
<hcarty>
Yes
<peper>
hcarty: is there an example for using it with lablgtk?
<hcarty>
In the tests (or maybe test) directory in the source tree
<peper>
hcarty: which examples do you have in mind?
<hcarty>
If you go with Cairo, the included examples should help you out
<peper>
hcarty: i want to make a simple boids simulation
<hcarty>
But it makes very nice looking graphics and you can easily switch between different rendering targets
<hcarty>
Cairo is the slowest
<hcarty>
peper: Depends on the application and your purpose in writing it. All of them are useful.
<peper>
hcarty: which one would you choose?
<hcarty>
peper: You could use the Cairo, SDL or OpenGL bindings
<hcarty>
But if you have a value with the same name as a label, then you can use that shorthand
<hcarty>
peper: ~a:foo would pass foo as the ~a argument instead
<hcarty>
peper: Yes
<peper>
hcarty: so ~a, is short for ~a:a ?
<hcarty>
peper: Labeled arguments. ~a is an argument with the label "a"
2009-03-14
<mrvn>
hcarty: a value has a size and can be stored in a buffer or read from it.
<hcarty>
I am curious, not doubting
<hcarty>
mrvn: Why classes? What do they buy you that "type value_t = Foo_v | Bar_v | Baz_v | Buzz_v" and appropriate matching does not?
<hcarty>
mrvn: I don't know if there is a type system level way of enforcing something like that in OCaml. If there is I'd be interested in hearing about it.
<hcarty>
mrvn: 4 trees, one for each of the key types?
<hcarty>
If individual libraries are not remaining consistent then coming up with a standard is probably a good thing.
<hcarty>
I'm a much bigger fan of names_like_this than namesLikeThis, so such an outcome fits my taste
<hcarty>
If an official Batteries naming style is put in place then perhaps other projects will follow
<hcarty>
Break from how modules are named, that is
<hcarty>
As long as it's consistent then I suppose it's ok. My main concern was the break from what module naming in several popular OCaml libraries (stdlib, labl*, extlib)
<hcarty>
thelema: So the Caps_then_underscore form will hold for Batteries module naming?
<hcarty>
It doesn't mean they are right, but they are (somewhat?) prominent
<hcarty>
mfp: I have seen ALLCAPS more often as you said though
<hcarty>
mfp: The example on the caltech page is ORDERED_TYPE
<mfp>
hcarty: anyway camel + underscore makes no sense, it's either one or the other: OrderedType or Ordered_type (or ORDERED, which I thought was more common)
<thelema>
hcarty: you're right - they are strictly saying that lc-identifiers shouldn't have cap letters in them
<hcarty>
mfp: That's from the caltech style page thelema linked
<hcarty>
thelema: I agree - I'm speaking only about module naming here
<hcarty>
It seems clear in the opposite direction to me :-) It specifically mentions that capitalization is reserved for module and constructor names
<hcarty>
I think that refers to values though, correct?
<hcarty>
s/types/signatures/
<hcarty>
And camel+underscores for module types
<hcarty>
The caltech page seems to suggest camelcase for module names though
<hcarty>
thelema: I saw that as well. And the official OCaml guidelines don't mention module names specifically
<hcarty>
Though that may reflect more on the libraries I've looked at than the general case
<hcarty>
For values yes, but modules seem to be camelcase more often than not
<hcarty>
Yoric[DT], thelema: Regarding Batteries module names - is there a reason for not staying with CamelCase for module names? It seems to be what the standard library and ExtLib use
2009-03-13
<hcarty>
mrvn: preludeml has some wrapper functions which support forking for parallel map/iter/etc
<hcarty>
I'm off for the night though. Best of luck.
<hcarty>
omake should have support for that more or less automatically. I have not personally used it for my own projects though.
<hcarty>
palomer: I've always taken the wimpy way out and used OCamlMakefile or ocamlbuild. The manual and man pages should have the information you need though.
<hcarty>
palomer: The archive file is the .cmo, .cmx, .cma or .cmxa for the library