_ry has quit [Read error: 110 (Connection timed out)]
seafood_ has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
yangsx has joined #ocaml
hsuh has quit [Connection reset by peer]
seafood_ has quit []
seafood_ has joined #ocaml
jlouis_ has quit ["leaving"]
jlouis has joined #ocaml
Axioplase has quit ["bed"]
thermoplyae has quit ["daddy's in space"]
johnnowak has joined #ocaml
vincenz has joined #ocaml
johnnowak has left #ocaml []
pants1 has joined #ocaml
Morphous_ has quit [Read error: 110 (Connection timed out)]
thermoplyae has joined #ocaml
yangsx has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
mwc has joined #ocaml
yangsx has joined #ocaml
Morphous has joined #ocaml
coucou747 has quit ["bye ca veut dire tchao en anglais"]
coucou747 has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
AxleLonghorn has joined #ocaml
middayc has quit []
coucou747 has quit ["bye ca veut dire tchao en anglais"]
<palomer>
hello!
<palomer>
I just had a huge meal
<palomer>
konnafa and everything
dwmw2 is now known as dwmw2_gone
jlouis_ has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
hsuh has joined #ocaml
<palomer>
the only problem with using classes is that you can't make classes and normal types mutually recursive
<palomer>
I'm a little confused as to how to interpret key inputs from users
<palomer>
entry#event#connect#key_press ~callback: takes a function GdkEvent.Key.t -> bool
<palomer>
GdkEvent.Key.keysym takes a GdkEvent.Key.t and returns an integer representing that keypress
<palomer>
how am I supposed to interpret that integer?
<hcarty>
palomer: I haven't used it, but I would guess that it is listed somewhere in the GTK documentation. It could be a key code or something similar.
<palomer>
good point
<palomer>
is there some syntactic sugar for
<palomer>
if a then b else if d then e else if f then g .. ?
<palomer>
like a case statement?
<palomer>
case pred1 -> a; | pred2 -> b; pred3 -> c ....
<hcarty>
Sorry, should start with: match (something) with ...
<hcarty>
let exclamation = match a = b with true -> "Hooray!" | false -> "Nooooo!";;
goalieca has joined #ocaml
<palomer>
err
<palomer>
well, I have a bunch of strings
<palomer>
and I'd like to do
<palomer>
if str == "foo" then a else if str =="bar" then b else if ....
<hcarty>
match str with "foo" -> a | "bar" -> b | ...
<hcarty>
The | is the separator between cases
<palomer>
you can match strings?
<palomer>
cool!
<hcarty>
match works with just about anything
<palomer>
strings, ints, algebraic datatypes
<palomer>
anything with Eq, right?
<palomer>
which brings me to another question
AxleLonghorn has quit [Remote closed the connection]
<palomer>
match searches linearly, right?
AxleLonghorn has joined #ocaml
<hcarty>
I am not sure of the exact restrictions or the implementation
<hcarty>
match some_list with [] -> "empty" | hd :: [] -> "one" | hd :: tl -> "more" --- There is a lot you can do with match
ulfdoz has quit [Read error: 101 (Network is unreachable)]
hsuh has quit [Remote closed the connection]
AxleLonghorn has left #ocaml []
<palomer>
let current_node = (ref t : node ref) in (*error This expression has type Top.top ref but is here used with type Node.node ref *) <--but Top inherits node!
<palomer>
err
<palomer>
top inherits node (bad capitalization)
seafood_ has quit []
<palomer>
Only the first object type has a method get_children
jlouis_ has quit [Read error: 110 (Connection timed out)]
schme has quit [Remote closed the connection]
pango- has joined #ocaml
schme has joined #ocaml
schme has quit [Remote closed the connection]
schme has joined #ocaml
pango has quit [Remote closed the connection]
pango- is now known as pango
donny__ has joined #ocaml
yangsx has quit [Read error: 110 (Connection timed out)]
donny has quit [Read error: 110 (Connection timed out)]
mfp has quit [Read error: 104 (Connection reset by peer)]
mfp has joined #ocaml
goalieca has quit ["dreaming about hockey"]
seafood_ has joined #ocaml
rwmjones has quit [Remote closed the connection]
rwmjones has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
Well, I guess I've just produced my first monad tutorial.
* Yoric[DT]
wonders if he has thus joined some club.
magnusth has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
schme has quit ["bfirc sucks."]
bongy has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
authentic has left #ocaml []
authentic has joined #ocaml
bongy has quit ["Leaving"]
<rwmjones>
hmmm
<rwmjones>
any idea how to write function f for this?
<rwmjones>
# Printf.sprintf (f "%s") "hello" ;;
<rwmjones>
This expression has type string but is here used with type
<rwmjones>
('a -> 'b, unit, string) format =
<rwmjones>
('a -> 'b, unit, string, string, string, string) format6
<rwmjones>
the naive definition of f doesn't work
<Snark>
rwmjones, what are you trying to achieve?
<Smerdyakov>
I imagine it would work with the right type annotation on [f].
<rwmjones>
I want to write a replacement function for ocaml-gettext's f_ when ocaml-gettext isn't installed
delamarche has joined #ocaml
delamarche has quit [Client Quit]
<rwmjones>
# let f_ : string -> ('a -> 'b, unit, string) format = fun s -> s
<rwmjones>
;;
<rwmjones>
This expression has type string but is here used with type
<rwmjones>
('a -> 'b, unit, string) format =
<rwmjones>
('a -> 'b, unit, string, string, string, string) format6
* rwmjones
can do it with Obj.magic, but then the format strings aren't checked ...
<Smerdyakov>
No, that of course won't work.
<Smerdyakov>
You should make the argument to [f] a [format*] type, too.
<rwmjones>
ah right, of course
<rwmjones>
cool, this works
<rwmjones>
let f_ : ('a -> 'b, 'c, 'd) format -> ('a -> 'b, 'c, 'd) format = fun s -> s
<rwmjones>
and it checks the format strings
<Smerdyakov>
BTW, if you made [f] actually do something, you probably wouldn't need an annotation.
<rwmjones>
yeah, but the idea is this f_ doesn't do anything -- it can't because there is no underlying gettext implementation
<rwmjones>
when ocaml-gettext is installed then we use the f_ function from that which does translation
<Smerdyakov>
So you don't want to change the format string?
<rwmjones>
in the "gettext is installed" case then the format string gets translated
<Smerdyakov>
gettext is some standard C library that frobs format strings, with no additional inputs?
<rwmjones>
ocaml-gettext can either use the C function or it has its own pure OCaml implementation, which you can choose at runtime
<rwmjones>
the C version knows about (some types of) format strings by the context in which they are used
jsk has quit [Read error: 104 (Connection reset by peer)]
seafood_ has quit []
ttamttam has left #ocaml []
musically_ut has joined #ocaml
Snark has quit ["Ex-Chat"]
thelema has quit [Read error: 110 (Connection timed out)]
ttamttam has joined #ocaml
evn_ has joined #ocaml
jonathanv is now known as jonafan
<hcarty>
rwmjones: Thanks for the quick Calendar update in Fedora
<rwmjones>
np
<rwmjones>
it'll take a while before that package goes out to the repositories because I think we're still in the F9 alpha freeze ... just use the package straight out of koji (link in BZ) in the meantime
<hcarty>
Ok, sounds good
thelema has joined #ocaml
<thelema>
rwmjones: still working on that gettext thing?
<thelema>
what would people want from a generalized IO layer? Extlib provides one that does has simple char/slice read/writes, close on both and flush on output. Anything else?
<flux>
something that works with poll/select
<thelema>
I take that back - those functions are what needs to be provided by the underlying implementation, it has lots of nice helper functions like read_i64 and printf (somehow)
<Smerdyakov>
I hate IO on character streams.
<thelema>
poll/select... hmmm...
<Smerdyakov>
It's embarrassing that this is still the default.
<thelema>
Smerdyakov: you'd like higher-level IO - reading/writing any arbitrary type?
<Smerdyakov>
I'd like to avoid reading and writing, but what you said is a good property for an incremental improvement.
<thelema>
Smerdyakov: how would you interact with... a TCP connection, for example?
<Smerdyakov>
Programs that use TCP are a failure of abstraction.
<thelema>
so programs shouldn't use TCP, they should use... what? HTTP libraries?
<Smerdyakov>
It's an open research problem, and I'm confident that we'll keep making progress on it.
<thelema>
do you disagree with arrays / strings?
<Smerdyakov>
Both are instances of sequence types, which are a fine way to think about parts of programs.
<Smerdyakov>
The imperative aspects I hope to see gone from programming soon.
<thelema>
but linear IO you don't approve of.
<Smerdyakov>
I don't approve of IO.
<Smerdyakov>
You want to phrase programming tasks in ways that avoid it.
<flux>
so, IO is a necessary evil?
<Smerdyakov>
s/necessary/unnecessary
<Smerdyakov>
Belongs in OS kernels and that's it.
<mbishop>
I think it's sad we still have to deal with byte sequences and crap
<Smerdyakov>
None of the languages I've designed make you deal with byte sequences. :-)
<thelema>
Smerdyakov: Maybe I'm old-fashioned, but I like using a paradigm that's compatible with the inner workings of the machine I'm working in.
<Smerdyakov>
thelema, yeah, I'm glad to put people who think like that out of business. ;)
<thelema>
is it possible to abstract too much? My answer: yes.
<Smerdyakov>
Maybe, but so?
<thelema>
on a different topic, does anyone here know anything about the "treematch" branch in INRIA's CVS?
marmottine has joined #ocaml
Linktim has joined #ocaml
coucou747 has joined #ocaml
<thelema>
I'll take that as a no.
magnusth has quit ["Ex-Chat"]
bluestorm has joined #ocaml
thermoplyae has joined #ocaml
thermoplyae has quit [Client Quit]
Linktim_ has joined #ocaml
postalchris has joined #ocaml
middayc has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
Linktim- has joined #ocaml
middayc has left #ocaml []
Linktim_ has quit [Read error: 110 (Connection timed out)]
thelema has quit [Read error: 110 (Connection timed out)]
<jlouis>
Erlang way of using patterns on binary IO sequences is definitely one improvement over loop-based IO
<jlouis>
I am not sure it is the right one, though it has practical merits today.
musicallyut has joined #ocaml
<Smerdyakov>
Anything that deals with bits doesn't belong in 99% of applications.
ygrek has joined #ocaml
<rwmjones>
depends what your applications are ... mine tend to do things like examining raw filesystem partitions for data and pushing/pulling stuff from binary network protocols, so they definitely need to see bits
musically_ut has quit [Remote closed the connection]
<rwmjones>
I actually wish someone would write a syntax extension a la erlang for ocaml
ygrek has quit [Remote closed the connection]
ygrek has joined #ocaml
<bluestorm>
rwmjones: do you have an example of those raw manipulation possibly improvable by syntaxic support?
<jlouis>
Smerdyakov: I agree fully. I claim it is a fallacy of C that has brought this sorry state upon us.
<rwmjones>
although it gets some things right -- eg. the ability to parse C header files looking for structures
<Smerdyakov>
rwmjones, well-designed software of the future won't use filesystems or binary network protocols.
<bluestorm>
:p
<rwmjones>
that's a .. erm .. interesting point of view
<Smerdyakov>
...and I probably think the future is closer than you do. :-)
<rwmjones>
bluestorm, the Linux community also has trouble with an endless series of security patches to wireshark (nee ethereal) and [some software for recovering JPEGs from corrupted USB sticks which name escapes me now]
musically_ut has joined #ocaml
<rwmjones>
these are all caused by people writing binary-parsing code by hand in C
<rwmjones>
so a language where programmers can't hurt themselves is much needed
<bluestorm>
rwmjones: i suppose that eg. lines 45-53 of virt_df_ext2.ml would be the ones you'd appreciate syntaxic support for ?
<rwmjones>
yup
<hcarty>
Smerdyakov: What would be the method for accessing data, either local or remote?
<rwmjones>
also to make it safer (ie. reduce risk of security problems)
<Smerdyakov>
hcarty, everything looks like on big heap.
<Smerdyakov>
s/on/one
<rwmjones>
eg. imagine that the disk image is hostile and is trying to corrupt the program
<ttamttam>
#ocaml-fr
<bluestorm>
rwmjones: are those tied to a type declaration somewhere ?
<rwmjones>
or imagine that we want to support a half dozen different filesystem & partition schemes
<rwmjones>
the idea behind libunbin is that it uses CIL to actually parse out the fields in that header file structure and generates serialization code automatically
<rwmjones>
which (kind of) works
kelaouch1 has quit ["leaving"]
<bluestorm>
i think that providing camlp4 support for declaring a bunch of variables, associated with lengths using a specified read method would not be difficult
ttamttam has left #ocaml []
<rwmjones>
don't forget endianness conversion, bitfields, etc.
<bluestorm>
rwmjones: is a syntaxic support needed for that ?
<rwmjones>
I guess so .. you want to say "bits 2-3 from this 32 bit big endian field"
<rwmjones>
also libunbin allows you to sanity check things like length fields
<rwmjones>
eg if someone passes you an absurdly large length field (intending to corrupt your heap if you're using C+malloc) then you can stop that
<bluestorm>
yes but those checks could be implemented as a standard caml function that the syntax extesion would use
<bluestorm>
it seems there is no need for it to lay at the camlp4 level
<mattam>
rwmjones: you know about cryptol ?
<rwmjones>
sure, if you remember to put them in of course ... part of this is enabling stupid programmers to write code in relative safety
<rwmjones>
nope
<bluestorm>
(more generally, i think the more logic you pass with non-syntaxic tools and the simpler the syntaxic modification is, the better)