chickenzilla has quit [Read error: 113 (No route to host)]
chickenzilla has joined #ocaml
Ppjet6_ is now known as Ppjet6
wsmith85 has joined #ocaml
authentic has quit [Remote closed the connection]
authentic has joined #ocaml
ofaurax has joined #ocaml
Associat0r has joined #ocaml
Associat0r has quit [Read error: 104 (Connection reset by peer)]
bzzbzz has joined #ocaml
Camarade_Tux has quit ["Quitte"]
Camarade_Tux has joined #ocaml
ttamttam has joined #ocaml
ttamttam has left #ocaml []
OChameau has joined #ocaml
wsmith85 has quit [Read error: 110 (Connection timed out)]
bhampkl has joined #ocaml
<bhampkl>
A compilation error occurs when godi tries to build
<bhampkl>
godi-ocaml-labltk (too few arguments to function Tk_PhotPutBlock). I
<bhampkl>
am unable to remove the package godi-ocaml-labltk. Does anyone know
<bhampkl>
how to put godi back in a "proper" state?
slash_ has joined #ocaml
<thelema>
bhampkl: sorry - I'm not a godi expert
<thelema>
what version of tk do you have installed?
<thelema>
IIRC, labltk wants 8,4, even though the latest is 8.5
<bhampkl>
8.5
<thelema>
try 8.4
<bhampkl>
ok, I will see if it is possible to downgrade arch.
<bhampkl>
thanks
<thelema>
n/p
wsmith85 has joined #ocaml
smimram has joined #ocaml
Camarade_Tux has quit ["Quitte"]
smimou has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has joined #ocaml
angerman has quit []
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
wsmith85 has quit [Read error: 110 (Connection timed out)]
ched_ has joined #ocaml
Ched has quit [Read error: 110 (Connection timed out)]
kaustuv has joined #ocaml
OChameau has quit [Read error: 113 (No route to host)]
Fulax has quit ["Out of Memory: Killed process [9823] xchat."]
<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
<thelema>
the ocaml naming conventions definitely go towards non_caml_case
<thelema>
as to stdlib, I dunno why *Labels are camelcase
<hcarty>
For values yes, but modules seem to be camelcase more often than not
<hcarty>
Though that may reflect more on the libraries I've looked at than the general case
<Camarade_Tux_>
most probably because List already has an uppercase letter, List_labels seems a _bit_ weird (but not more than a tiny bit)
ramenboy has quit [Read error: 104 (Connection reset by peer)]
ramenboy has joined #ocaml
<hcarty>
thelema: I saw that as well. And the official OCaml guidelines don't mention module names specifically
<hcarty>
The caltech page seems to suggest camelcase for module names though
<hcarty>
And camel+underscores for module types
<hcarty>
s/types/signatures/
<thelema>
Separate words by underscores: (int_of_string, not intOfString)
<thelema>
Case modifications are meaningful in Caml: in effect capitalized words are reserved for constructors and module names in Objective Caml; in contrast regular variables (functions or identifiers) must start by a lowercase letter. Those rules prevent proper usage of case modification for words separation in identifiers: the first word starts the identifier, hence it must be lower case and it is forbidden to choose IntOfString as the
<thelema>
(sorry for big paste)
<hcarty>
I think that refers to values though, correct?
<thelema>
it seems to be pretty clear - "Separate words by underscores" (within the "how to choose identifiers" section)
<hcarty>
It seems clear in the opposite direction to me :-) It specifically mentions that capitalization is reserved for module and constructor names
<mfp>
<hcarty> And camel+underscores for module types s/types/signatures/ > aren't sigs usually module type WHATEVER = ... ?
<thelema>
which is why one shouldn't use capital letters variable names unless they're module or constructor names
<mfp>
hmm the INRIA stdlib has got OrderedType though
<hcarty>
thelema: I agree - I'm speaking only about module naming here
<hcarty>
mfp: That's from the caltech style page thelema linked
Camarade_Tux_ has quit ["Leaving"]
<thelema>
hcarty: you're right - they are strictly saying that lc-identifiers shouldn't have cap letters in them
<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)
<mfp>
Ordered_Type isn't an option, is it?
<hcarty>
mfp: The example on the caltech page is ORDERED_TYPE
<mfp>
that corresponds to what I believed to be the most common style
<mfp>
(_TYPE feels redundant in this case, though)
<hcarty>
mfp: I have seen ALLCAPS more often as you said though
<hcarty>
It doesn't mean they are right, but they are (somewhat?) prominent
<mfp>
according to caltech's exception InternalError
<mfp>
yet Internal_error is well-established
<mfp>
(Invalid_argument, etc.)
chickenzilla` has joined #ocaml
chickenzilla has quit [Nick collision from services.]
chickenzilla` is now known as chickenzilla
wsmith85 has joined #ocaml
Demitar has quit [Remote closed the connection]
ttamttam has joined #ocaml
wsmith85 has quit [Read error: 110 (Connection timed out)]
ttamttam has left #ocaml []
oriba has joined #ocaml
th5 has joined #ocaml
roliba has joined #ocaml
oriba has quit [Read error: 104 (Connection reset by peer)]
* thelema
hasn't changed his mind on naming. Internal_error is better than InternalError
<Camarade_Tux>
by default I was in favor of InternalError but I haven't been able to easily read that in your message, I had to read Internal_error again and then translate it to camelcase, Internal_error is definitely easier to read
roliba is now known as oriba
<mrvn>
Does batteries have a module to convert int, int32, int64 to a bit pattern and add it to a buffer or string (and reverse of that)?
<Alpounet>
Good night.
Alpounet has left #ocaml []
Snark has quit ["Ex-Chat"]
tclineks has joined #ocaml
<thelema>
mrvn: yes - our IO library has functions for outputting various ints as bit patterns to a channel, which can be a string or buffer, as well as reading the same.
<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>
Break from how modules are named, that is
<hcarty>
If an official Batteries naming style is put in place then perhaps other projects will follow
<hcarty>
I'm a much bigger fan of names_like_this than namesLikeThis, so such an outcome fits my taste
<thelema>
maybe. Even lablgtk has many modules using _ instead of camlcase
<thelema>
and I expect the camlcase makes conversion from C easier
<hcarty>
If individual libraries are not remaining consistent then coming up with a standard is probably a good thing.
<thelema>
oops, I was just looking at the dir listing in src/ and there's lots of _, but most of them are .c / .h
<mrvn>
I've run into a little design problem. I want to store (key, value) pairs in a B-Tree. The Key has one of 4 types plus some type specific data. The value also has 4 types corresponding to the 4 key types. How do I express that the key and value types correspond?
<hcarty>
mrvn: 4 trees, one for each of the key types?
<mrvn>
I have type key = Foo of int | Bar of int*int | Baz of int64 | Buzz of Hash.t
<mrvn>
So it is not really 4 ocaml types.
<mrvn>
The on-disk format also has only one tree so I'm stuck with that.
oriba has quit [Read error: 110 (Connection timed out)]
wsmith85 has joined #ocaml
<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.
<mrvn>
I think I need classes for this. A virtual keyValue class and then 4 derived classes.
<mrvn>
And a function to get the generic key from a keyValue.
<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>
I am curious, not doubting
<mrvn>
hcarty: a value has a size and can be stored in a buffer or read from it.
<mrvn>
values aren't uniform size and the B-tree needs to know when the block is foverflowing and needs to be split.
<mrvn>
Keys are alwys 16 byte though.
chickenzilla` has joined #ocaml
th5 has quit []
<mrvn>
Maybe I should just have type value = string and convert it to the specific type when it gets used.
chickenzilla has quit [Nick collision from services.]
chickenzilla` is now known as chickenzilla
<mrvn>
On disk I have struct Key { uint64_t type : 8; uint64_t inode/dev : 56; uint64_t offset/hash; } and struct Value { uint16_t len; char data[len] }