<tsuyoshi>
it's pretty complicated.. but I guess unicode is complicated
seafood has quit []
seafood has joined #ocaml
<flux>
tsuyoshi, you could actually want to do that. say, if you use the toplevel as an interactive configuration mechanism for something else
<flux>
say, a synthesizer..
<jdh30>
or a replacement for a technical computing environment like Mathematica.
<flux>
or wy not a raytracer ;)
<jdh30>
Speed quickly becomes critical
<jdh30>
:-p
<tsuyoshi>
that is really not a good idea.. type inference and interactivity don't mix
<jdh30>
Type inference and interactivity mix really well. This is the foundation of F# as well.
<tsuyoshi>
maybe f# does something differently but I don't think it works well with ocaml
<flux>
tsuyoshi, also, have you seen the F# demos with 3d? looks pretty cool, and I could totally see one doing that with O'Caml too.
<jdh30>
F# uses Visual Studio to give IDE support to the interactive environment. That is essential and completely missing in OCaml.
<jdh30>
You need to write your code in Emacs while running an infinite build loop so that you can get type throwback. Then cut and paste your code into the OCaml top-level.
<flux>
well, the cool parts of the demos I've seen didn't seen to need anything from the visual studio, other than toplevel
<flux>
and emacs can do that with a single keypress to an ocaml session running inside it. the type feedback will require compilation, though.
<flux>
but there are people working on it; better toolkit support for ocaml is a Jane Street summer project
<jdh30>
There is some IDE support for OCaml though, like ocaide.
<jdh30>
We put some demos on Metacafe and YouTube as well. Not sure if that one is.
<jdh30>
Get a decent video player...
<jdh30>
I'm playing it in 64-bit Linux here (mplayer)
<vixey>
jdh30: actually I think I'd rather not watch your f# video
<jdh30>
Then why do you want it in another format?
<vixey>
jdh30: I don't anymore
<jdh30>
ok
<tsuyoshi>
hahahahah
<jdh30>
Anyway, checkout ocaide
<jdh30>
Has anyone tried camelia?
hkBst has joined #ocaml
<tsuyoshi>
no, what is it?
<jdh30>
Another IDE for OCaml.
<jdh30>
There are lots but most are fledgling
<tsuyoshi>
have you tried camelia?
<jdh30>
Me? No.
<jdh30>
I've only tried ocaide
<jdh30>
I got so disgruntled with emacs that I've switched to kwrite now, and it is much worse feature-wise but at least it is stable and fast.
<tsuyoshi>
heh.. I just use vim
<jdh30>
Is vim any good?
<tsuyoshi>
it doesn't have syntax highlighting or autoindent for ocaml, but I went to a lot of trouble to turn those things off for c
<bluestorm>
tsuyoshi: there actually are vim modes for ocaml
<bluestorm>
iirc markus mottl did one
<jdh30>
oh
<jdh30>
Yeah, I thought vim was the other "major" editor for OCaml programmers
<tsuyoshi>
yeah I figured.. I was just saying, that kind of thing annoys me
<tsuyoshi>
but I'm sure I'm in the minority, I know a lot of people who can't really read code without highlighting
<jdh30>
Yes. I've never heard of anyone trying to turn it off before...
<jdh30>
Ideally, I'd like a Mathematica-like notebook front end for OCaml with all the bells and whistles.
<tsuyoshi>
ohh.. I spent like a week turning off all the extra features in vim
<jdh30>
Can't build one easily because OCaml's top-level isn't OSS.
<tsuyoshi>
I only switched from nvi because nvi doesn't work with utf8
<jdh30>
Never heard of nvi
<Yoric[DT]>
jdh30: you could try and write one based on TeXmacs
<tsuyoshi>
it's the modern bsd version of vi
<qwr>
vi with the original sucking taste ;)
<tsuyoshi>
basically.. they just rewrote vi to get out of some copyright problem with the original vi, so it had no features
<tsuyoshi>
but then they added a perl interpreter to nvi.. and it went downhill from there
<bluestorm>
jdh30: apart from the tool problems, do we have (open source) scientific libraries available in ocaml to support that kind of things right now ?
<jdh30>
Yoric[DT]: we considered writing more advanced tools build around the OCaml distribution but the licensing makes it difficult.
<Yoric[DT]>
jdh30: what kind of tools ?
<jdh30>
bluestorm: what kind of things?
<tsuyoshi>
still no unicode support though.. a significant portion of my text editing is japanese these days so nvi is pretty useless for me now
<bluestorm>
hmm
<bluestorm>
you were just speaking about the front-end
<jdh30>
Yoric[DT]: An interactive technical computing environment like Mathematica's notebook interface.
<Yoric[DT]>
ok
<bluestorm>
i thought you were thinking scientific computations too, sorry
<qwr>
tsuyoshi: vim certainly has some syntax highlighting for ocaml
<vixey>
when you say "we" you mean, just yourself?
<jdh30>
bluestorm: yes i was. What kind of things are already available?
<jdh30>
vixey: my company
<bluestorm>
vixey: i assume that means FFconsultancy
<jdh30>
yes
<vixey>
how many people is it ?
<jdh30>
two
<tsuyoshi>
qwr: luckily for me it's not enabled by default with the version I'm using =^D
<jdh30>
lol
det has quit [Read error: 104 (Connection reset by peer)]
AxleLonghorn has joined #ocaml
AxleLonghorn has left #ocaml []
<jdh30>
Looks like 3.10.2 does not have the native code top level after all... :-(
<flux>
jdh30, cvs has it, but it's not compiled by default
<jdh30>
Is anything happening on the community contribution front?
<jdh30>
yes
<jdh30>
I've got it from CVS
<jdh30>
Has anyone here tried Jane St.'s core library?
<tsuyoshi>
I took a look at it.. I think it looks better than the standard library
<tsuyoshi>
but it is still incomplete
<vbmithr>
Hello
<vbmithr>
Anybody knows where the netstring package can be retrieved ?
<tsuyoshi>
the idea of replacing all the exceptions with option types is interesting
<vbmithr>
I need this to compile PXP but I can't find it anywhere..
<fremo>
ocamlnet.sf.net ?
<tsuyoshi>
pretty much the only major ocaml debugging task I've had is figuring out where an exception was raised
<tsuyoshi>
everything else is caught by the type checker
<tsuyoshi>
so.. moving everything to the type checker sounds good to me
<tsuyoshi>
it's funny, I've done some pretty crazy things with Obj.magic but it's never resulted in the problems I've had with c
<bluestorm>
and i'm not sure using option types is the same as "moving everything to the type checker"
<jdh30>
tsuyoshi: interesting. I've never had a problem with exceptions so I was always quite happy to use them instead of boxing to avoid the performance hit and the unboxing.
<bluestorm>
(except that it makes the exception handling mandatory)
<bluestorm>
option types are even less descriptive as exception in most cases, but i agree they have value for find/lookup for example
<jdh30>
bluestorm: well, it means the type checker forces you to handle the exceptional case. In theory there is a danger that people will forget and exceptions will propagate but I've never had that problem.
<jdh30>
I guess I only use them locally.
<tsuyoshi>
ah.. in the programs I've written, performance was either largely irrelevant or 90% of the time was taken by gtk code
<jdh30>
tsuyoshi: 90% of the time was taken by Gtk in your OCaml code or in other languages as well?
<tsuyoshi>
bluestrom: exactly.. the compiler doesn't care if you catch an exception or not, but it will warn if you don't match an option
<vixey>
I don't think option types have to be boxed
<vixey>
doesn't SMLNJ just tag the top bits of a pointer?
<jdh30>
vixey: i believe ocamlopt always boxes them because they are just ordinary variant types (which are a tag with a length and then a sequence of pointers to data for ordinary variants)
<tsuyoshi>
can't really do that in ocaml.. maybe in 64-bit, in 32-bit the bits are pretty much all taken
<jdh30>
vixey: even F# only avoids boxing in certain circumstances (e.g. using a nullable pointer to an object)
<tsuyoshi>
I think it is likely the branching kills performance more than the boxing anyway
<jdh30>
tsuyoshi: no, branching is much faster than allocation
<tsuyoshi>
oh allocation.. you know I was just thinking of access
<jdh30>
tsuyoshi: ocaml could use a zero pointer to represent None, as F# does, but it lacks the JIT capability to make that useful (via type specialization).
<tsuyoshi>
and thinking the box and its contents ought to be in l1 cache anyway
<tsuyoshi>
but yeah the allocation will kill
<jdh30>
yes
<jdh30>
boxing also tends to incur two branches where as CPS can only incur one.
<jdh30>
the library code branches to fill the boxed value and then the user code checks the value and does a redundant branch to handle it
<tsuyoshi>
even without jit though, the compiler should be able to just put the box on the stack
marmottine has joined #ocaml
<jdh30>
In theory, it would be preferable to pass continuations and have it branch only once to the correct handler.
<tsuyoshi>
I mean, the caller could allocate stack space before the call.. and then that should be fast
<jdh30>
tsuyoshi: yes, that is theoretically possible. Hopefully the F# guys will have a go at implementing such things. I don't think the OCaml team will but perhaps a new FPL will come along to replace it...
<tsuyoshi>
but even so.. in jane st. core, they have _exn versions of all the functions, so if you have a performance problem with some code because of this it's not a huge deal
<jdh30>
Yes.
<jdh30>
I wonder how much of their converting to option types was motivated by making it easier to port efficiently to F#.
<tsuyoshi>
jdh30: I have had a lot of ideas for improving the compiler's code generation but I haven't had any code that I needed to go faster
<jdh30>
Presumably Jane St. are going to follow suite and migrate to F# soon.
<jdh30>
tsuyoshi: Yes, it is all academic when you don't have a concurrent GC anyway...
<tsuyoshi>
if we had some code to benchmark with, we could do a lot more.. I could implement some things but I have nothing to test to see if it's helping
<tsuyoshi>
I think inria has the same issue, they were asking people to test the pic amd64 iirc
<jdh30>
I ported SciMark2 to OCaml recently, for an OCaml Journal article. I'll make that publically available ASAP.
<jdh30>
I may also open source Smoke...
<tsuyoshi>
since for the most part, ocaml doesn't do much in the way of optimisation.. there are a ton of easy optimizations - boxing especially - that you could do
<jdh30>
You should start with the most productive though. IMHO, that means writing a concurrent GC, porting the backend to a JIT (like LLVM) and doing type specialization.
<tsuyoshi>
and it's pretty easy to understand the code.. whenever I look at gcc source I want to bang my head against the wall
<jdh30>
That also paves the way for lots of cool features, like vastly better FFI.
<jdh30>
Oh yes, the OCaml distribution is easy to understand. The problem is that you cannot contribute to it (unless you're French which, I assume from your name, you're not ;-).
<tsuyoshi>
ah.. I think they accept patches
<tsuyoshi>
if not, fork it
<jdh30>
Xavier told me they don't,.
filp has quit ["Bye"]
bzzbzz has joined #ocaml
<tsuyoshi>
I guess some people on the mailing list were complaining about this but I think a fork is inevitable
<tsuyoshi>
it's sort of like minix versus linux
<jdh30>
I proposed forking it to the community but the licence makes that seriously tedious (you can only distribute patches) and lots of prominent figures spat the collective dummy out over it
<jdh30>
I agree. However, the OCaml software market is non-existant so we're off to greener pastures.
<tsuyoshi>
yeah.. the patches thing is annoying but you can automate that easily enough
<jdh30>
Maybe when money is no longer an issue for us I'll be able to afford to come back and do some hacking on OCaml or whatever replaced it.
<jdh30>
You can automate it, yes. It is just a PITA (and what for?).
<jdh30>
To be honest, the whole makeup of the OCaml distro is very 1990's. It is so out of date that I think I would just start from scratch.
<jdh30>
By far the hardest part is writing a concurrent GC.
<tsuyoshi>
ha yes.. money is not an issue to me right now
<jdh30>
You could target Mono but it is absolutely appallingly badly written, unreliable and slow...
<jdh30>
what do you do for a living?
<tsuyoshi>
nothing.. I'm living in southeast asia, basically just studying japanese full time
<tsuyoshi>
eventually I will have to go back to the first world and get a job again
<jdh30>
wife and kids?
<tsuyoshi>
no
<jdh30>
they're expensive. :-)
<tsuyoshi>
hmm.. not here so much
<jdh30>
depends how many you have. :-)
<jdh30>
How's the food out there?
<tsuyoshi>
but I imagine women from my home country wouldn't want to live here
<jdh30>
where are you from?
<tsuyoshi>
the food is good... actually, vientiane of all places has the best food of anywhere in the world I've been
<tsuyoshi>
I'm from the us originally
<jdh30>
vientiane. I'll remember that. Where abouts in the US?
<tsuyoshi>
most recently seattle, I also lived in chicago, los angeles, nashville, and portland
<jdh30>
Ah. My Dad was asking if I would by flying out to Seattle to work with MS. I'm not but their description of it sounded nice.
<tsuyoshi>
the weather I like there.. otherwise I don't like seattle so much
<tsuyoshi>
I kind of wish I had lived in new york.. that's my favorite city there
<jdh30>
Of the places you listed, I've only been to LA and that was when I was a wee nipper.
<jdh30>
Really? I didn't like NY at all. Not my bag. In fact, I'm not really much of a city dweller at all. Grew up around farms in the countryside. The city of Cambridge is more than enough city for me.
<tsuyoshi>
ah.. if you go to work at microsoft in redmond, a lot of people there live a few miles east where it is kind of rural
<jdh30>
I seem to be in the habbit of making off-topic conversion on IRC. I was doing it on the Haskell group yesterday...
<jdh30>
Oh good. I think we're going to stay firmly put in Cambridge
<tsuyoshi>
my parents actually live in this 100 year old house (this is extremely old for seattle) on an acre about a mile from microsoft
<jdh30>
If not, we'll be going to Queenstown NZ.
<jdh30>
Is that where you grew up?
<tsuyoshi>
no.. my parents actually moved there after I did
Snark has joined #ocaml
<jdh30>
So you went to Asia? ;-)
<tsuyoshi>
yeah you could say that
<jdh30>
My in-laws were just looking at a house near here last week. Apparently it was perfect.
<tsuyoshi>
I went to tokyo, but it was kind of expensive there.. I would have had to get a job, but my japanese was crap and if I was working I wouldn't be studying
<jdh30>
Do any of the OCaml IDEs have Debian packages?!
<jdh30>
Do you just study languages or something else too?
<tsuyoshi>
just japanese.. as soon as I think I've got it down, I'm headed back to tokyo
<tsuyoshi>
although I guess I'm always learning about other things
<tsuyoshi>
I was figuring out how to do a priority queue in c without malloc yesterday
jonas_e has joined #ocaml
<jdh30>
A student of life. :-)
<tsuyoshi>
wasn't too hard.. next is an avl tree, I think it will be harder
<gildor_>
jdh30: cameleon has one, but it needs some works to make it works great (patches are welcome)
<jdh30>
I thought they were hard for ages but they're actually really easy.
<tsuyoshi>
the neat thing about a priority queue is that you can do it entirely without pointers
<tsuyoshi>
you put it all in an array, you just do a couple calculcations on the index to get the parent or child
<tsuyoshi>
I thought I learned all about data structures years ago but I never really implemented any
<jdh30>
I still have lots of data structures to discover. There seem to be a never ending supply.
<jdh30>
Incidentally, I tried finger trees recently and they appear to suck. What are they supposed to be good for?
<jdh30>
Haskell's DataSequence uses them for generic sequences IIRC but they don't seem to be any better than AVL trees.
struk_atwork2 is now known as struk_Atowrk
struk_Atowrk is now known as struk_atwork
<jdh30>
I asked the Haskell community and their feeling seemed to be that the best thing about finger trees is that Haskell's type system can handle them but OCaml's cannot...
<tsuyoshi>
hahhaha
<tsuyoshi>
haskell is the new common lisp
<jdh30>
Haskell is nothing like as crap as CL though.
<tsuyoshi>
lots of smart people love it but nobody does anything practical with it
<jdh30>
CL is just unbelievably awful, compounded by the enormous number of idiots using it who do not understand why they cannot feasibly Greenspun a pattern match or code anything non-trivial correctly without a decent static type system.
<jdh30>
I'd be hard pressed to name any smart people who love it.
<orbitz>
CL is gunna lose it's name soon. since nobody will adopt an updated stanard everyone is just making their own Uncommon Lisp
<orbitz>
I think the benefit of Haskell these days seems to be it's a good place for crazy ideas to start, and then filter into more mainstream langauges
<jdh30>
Yes. Scheme is at least of some educational value.
<vixey>
jdh30: You're so much smarter than KMP, Sussman et al
<orbitz>
i personnally think haskell is really swell and I like working in it (granted, I don't have a lot of experience init)
<jdh30>
orbitz: Maybe. It is certainly very active academically but the community are so full of BS.
<tsuyoshi>
yeah.. there are a lot of good ideas in haskell
<jdh30>
vixey: I know.
<orbitz>
hrm, how is it fullof BS?
<jdh30>
vixey: Just look at Fortress.
<vixey>
jdh30: that was sarcasm you are obviously stupid
<orbitz>
jdh30: what about fortress?
<jdh30>
vixey: That's Dr Stupid to you.
<jdh30>
orbitz: it sucks and they've only just begun. :-)
<orbitz>
jdh30: haha I'm unsure that really answers my question
<orbitz>
I have found the BS level of haskell to be on par with the BS level of mosth langauges
<jdh30>
orbitz: So I asked various members of the Haskell community, as an industrialist interested in the possibility of using it commercially, if that could be viable?
<vixey>
no you didn't you just rambled on about how much you love F# for an hour
<orbitz>
i guess that depends on a number of factors
<jdh30>
orbitz: Turns out there are lots of things that Haskell really sucks at but instead of just saying that they kept sending me on wild goose chases.
<jdh30>
vixey: that was yesterday. I'm talking about last year.
<jdh30>
Anyway, I met SPJ and spoke to him about it. He agreed that the problems I noted were serious problems ("those are the right things to be worrying about" he said) and that Haskell certainly doesn't have any of the capabilities that I am looking for.
<orbitz>
jdh30: i can't really comment on that since i wasn't present AFAIK, however i would point out that yoru sample size doesn't seem large enough to judge an entire ocmmunity
<jdh30>
The problem is that the Haskell community is composed entirely of academics who have absolutely no idea what industry needs.
<orbitz>
jdh30: well that is not surprising...
<jdh30>
orbitz: look at my discussions on the Haskell mailing lists and Reddit.
<orbitz>
jdh30: i'm not *that* interested :)
<vixey>
jdh30: You are actually so confused
<jdh30>
orbitz: Sure. The problem is that they think they know what industry needs (e.g. monads, not DLLs).
<orbitz>
i do not think I would use haskell for a large commercial product at this point.
<jdh30>
vixey: I really respect your opinion on that.
<jdh30>
orbitz: It doesn't have to be large. I just wanted to know if there would be any chance of selling Haskell libraries any time soon.
<orbitz>
jdh30: i would say, in my experience, you have to know the experiece of those you seek advice from. academics won't be able to tell you to omuch about industry of course. but *shrug*, whatevs
<jdh30>
orbitz: Turns out the language itself has lots of problems that make it difficult to write large code bases (no records, no functors, no dynamic features, DLLs etc.)
<orbitz>
haskell does not ahve functors?
<jdh30>
orbitz: Right. Several of these people pretended to be industrial users but they all turned out to be fakes, basically.
<jdh30>
orbitz: yep, no functors.
<jdh30>
orbitz: no polymorphic variants...
<bluestorm>
hmm
<jdh30>
they'll tell you that Haskell's type system is more powerful but just ask them to translate the expression `a.
<vixey>
by functors you mean ML modules
seafood_ has joined #ocaml
<bluestorm>
iirc Haskell does have syntaxic sugar for records
<jdh30>
The translation is something like 400 lines of code
<orbitz>
ohh
<jdh30>
vixey: part of the ML module system, yes.
<vixey>
jdh30: yes
<orbitz>
jdh30: that is not why many peopel will say haskelsl type system is more powerufl..
<jdh30>
vixey: F# also lacks functors but they are replaced by a conventional nominally-typed object system. I am still mastering it but I have faith that it scales because there are huge C# projects built around it.
<orbitz>
i would say it is probably due to typeclasses
<jdh30>
orbitz: Sure, but they imply subsumption.
<orbitz>
is jdp = jon harrop?
<orbitz>
jdh
<bluestorm>
orbitz: actually the haskell type system (with GHC extensions and all the stuff) _is_ more powerful
<vixey>
than MLs?
<jdh30>
orbitz: When, in fact, Haskell has a lot of trouble with basic contructs from OCaml.
<bluestorm>
but none of their extension has polymorphic variants
<jdh30>
bluestorm: for some practically-irrelevant definition of "powerful", yes.
<bluestorm>
vixey: than OCaml at least
<jdh30>
bluestorm: That is a Turing argument anyway. All that matters is the relative amount of code required to do the same thing.
<bluestorm>
jdh30: i like the kind system, but you would certainly describe it as irrelevant (and i've only seen it used in typeclasses, so maybe not so useful)
<jdh30>
Anyway, some things can be written slightly more concisely thanks to inherent laziness.
<jdh30>
bluestorm: I agree but F# already does it better. OCaml should just copy that.
<orbitz>
eep
<orbitz>
i'm not sure how i feel abou lazynes
<orbitz>
part of me likes it
<bluestorm>
jdh30: do you have any pointers on the kind system in F# ?
<orbitz>
and part ofme sees it as a huge block to making predictable code
<bluestorm>
orbitz: "The next ML should be pure, the next Haskell should be strict."
<orbitz>
bluestorm: haha
<jdh30>
orbitz: Right, so I lurked on the Haskell mailing list for two years. One nice example of laziness came up with the Burrows-Wheeler block sorting data compression algorithm
<jdh30>
But the Haskell is 10,000x slower than anything else.
<vixey>
jdh30: Are you aware that most of what you are saying is completely false?
<vixey>
jdh30: I just want to know if you actually beleive what you are saying or not
<orbitz>
jdh30: 10000x sounds like hyperbole to me, unless you have some numbers?
<jdh30>
orbitz: That quote was attributed to SPJ but I asked him in person and he said it was a crap idea.
<jdh30>
Yes, I'm Jon Harrop whoever was asking.
<orbitz>
i was asking
<orbitz>
hard to miss it with the mr opinionatd :)
<orbitz>
err sorry, dr opinionated
<jdh30>
orbitz: There was a long thread about it on the Haskell cafe list. Those aren't my numbers, I'm just quoting them
<vixey>
the comp.lang.lisp troll?
<jdh30>
vixey: yes.
<vixey>
and now he's migrated to IRC
<jdh30>
vixey: you probably mean "spread". ;-)
<gildor_>
fork is better
<jdh30>
lol
<gildor_>
jdh30 has forked concurrently anothr time ;-)
<jdh30>
I just thought of a not-stupid CL user: Christophe Rhodes. We did physics together at Cambridge.
<vixey>
who are you to judge if people are smart or not ...
<tsuyoshi>
same for sql.. it's really hard to make complicated queries fast
<jdh30>
Did you check them out? Most of them don't use Haskell...
<orbitz>
no i did not
<orbitz>
did you email them or something?
<jdh30>
I particularly liked the Erlang consultants who were listed there. I contacted them and they explained that the Haskell in Industry list is basically just spam for random companies looking to hire people familiar with Haskell to code in C/Java/...
<orbitz>
is the argument here that the haskell community si shit? or that haskell as a whole is shit?
<jdh30>
Yes.
<jdh30>
Read their blogs etc.
<jdh30>
Peter at Nazooka looks quite promising but I believe they still only intend to prototype in Haskell and then switch to F#.
<tsuyoshi>
in case anyone gets the wrong idea: I am not talking about mysql.. the kind of queries I'm talking about don't work with mysql at all, you need oracle or postgresql
<jdh30>
How come MySQL doesn't support them?
<orbitz>
MySQL likes to mollest young SQL standards
<jdh30>
?!
<tsuyoshi>
mysql is very primitive.. I think they have some limited form or subqueries now, but there's so much missing still
<mib_qiojn4hv>
Entry-level question: in the ocaml shell, I #load "site-lib/pcre/pcre.cma";; and get no complaints, then I open Pcre;; and get "Unbound module Pcre"--what's going wrong?
<tsuyoshi>
wasn't it supposed to be #use for libraries?
<jdh30>
Ansemond have one product and Haskell never had anything to do with it (they don't even use Haskell). Antiope have no products.
<jdh30>
no
<jdh30>
you need to use #directory "site-lib/pcre"
<jdh30>
do that OCaml can see the cmi files (I think)
<jdh30>
then #load "pcre.cma"
<jdh30>
and then open Pcre
<jdh30>
Works for me
<tsuyoshi>
oh.. see, he uses the toplevel and I don't
<jdh30>
I'm sure you would if it supported native code. ;-)
seafood has quit []
<jdh30>
Anyway, I'm off to ship some products. BFN.
jdh30 has quit ["using sirc version 2.211+KSIRC/1.3.12"]
seafood has joined #ocaml
vixey has joined #ocaml
<mib_qiojn4hv>
Hrm. The #directory "site-lib/pcre" gave no error, but then #load "pcre.cma" couldn't find file pcre.cma
<bluestorm>
mib_qiojn4hv: do you have findlib/ocamlfind ?
<bluestorm>
if you do, then #use "topfind";; #require "pcre";;
<mib_qiojn4hv>
How Oh, trailing slash did it!
<mib_qiojn4hv>
I shall remember the ocamlfind trick, though, thanks.
seafood has quit []
<struk_atwork>
require? interesting directive
<mib_qiojn4hv>
struk_atwork: Almost sounds familiar, doesn't it?
<struk_atwork>
mib_qiojn4hv, it definitely sound familiar (#include, or java require)..but ocaml directives are only valid within the interpreter, correcft?
<bluestorm>
yes they are
<bluestorm>
#require is a findlib-specific directive that allows one to use ocamlfind facilities trough the toplevel
<flux>
bluestorm, btw, an alternative to your idea about let foo = bar in module Baz: module Baz = Baz with let foo = bar? or is that redundant module naming the issue you were attempting to address..
<flux>
actually it's would imo not be very useful in that case, but perhaps when you have a deeper module hierarchy
<bluestorm>
hm
<flux>
in which case it would need to be able to fill in the intermediate module layers too: module Foo = struct include Foo module Bar = struct include Bar let foo = bar end end ..
<bluestorm>
module Baz = Baz with let foo = bar looks fine too
<flux>
hm, I suppose that isn't already a valid syntax?-)
<flux>
I wonder though if anyone would have code that does so much module extending that that language extension would be worth the trouble
<bluestorm>
i thought of it when using some module extensions, but it was for demonstration purpose only ("yes, this solution is extendable, ...")
pango has quit [Remote closed the connection]
pango has joined #ocaml
Axioplase has joined #ocaml
aryx has joined #ocaml
seafood has quit []
Linktim has joined #ocaml
<flux>
happiness. I finally managed to (almost) implement a type-safe mechanism for destructuring sql responses:
<flux>
parse (m c_client @| m c_client_name @| m c_client_host) (fun client name host -> (client, name, host)) should make all three fields end up with their proper types
<flux>
I don't statically know which fields are in the response, though, but it could be a pain too big, when constructing queries in a dynamic fashion..
<bluestorm>
flux: where does the type inference happen ? is c_client a type-binding function ?
<flux>
c_client is a column field which I've built earlier
<flux>
let t_client = (R.new_type R.Conv.any_string : (_, t_client) R.col_type) let c_client = R.new_column t_client
<flux>
I think atleast this should be a good excuse to look into camlp4 :-)
<flux>
t_client is an abstract type
<flux>
phantom type, that is
<flux>
I'm hoping it will not be too big a pain to build the tables in ocaml, but say, slightly annotating the sql create clauses and converting them to ocaml sounds appealing..
<flux>
btw, I read the Functional Unparsing white paper (O. Danvy 1998) for ideas
<rwmjones>
flux, have you looked at pg'ocaml?
<flux>
rwmjones, yeah, but it cannot really compose queries
<flux>
the relational project by someone who has visited the channel also is more like what I'm doing
<rwmjones>
not really sure I understand flux, can you give an example?
<flux>
rwmjones, let's say you have a function that does select * from client and another that does select * from host
<flux>
you can have a function that takes those relations and produces a new one which is a join between those
<flux>
in the end it ends up creating a query select * from client left join host using (client) or something
<rwmjones>
hmmm .. I'd just write the composed query. It would be type safe.
<flux>
well, it's not fun when you have tons of queries
<flux>
and many similar ones
<flux>
the eigensomething guy's project can do that
<mfp>
flux: yup, it's essentially an encoding of the relational algebra with existential types + a heavy camlp4 extension for convenience
<mfp>
the query language is more limited than pg'ocaml, but there are 2 advantages: composability & ability to develop w/o the DB + schema checking at startup
* mfp
is the eigenclass guy btw.
<flux>
figured ;)
pango has quit [Remote closed the connection]
<rwmjones>
none of this is new of course ... there was a thing called pdl from ArsDigita / Red Hat which did this years ago (2001-2002)
jonafan has joined #ocaml
<flux>
IBM has developed a relational query language, basically dead these days.. but it seemed nice for doing relational algebra, much nicer than SQL
<flux>
I wonder if that would be good language to pick for a camlp4 frontend
LordMetroid has joined #ocaml
<flux>
unfortunately I don't remember its name, so I may never find any documentation for it ;)
<mfp>
rwmjones: didn't know about pdl; did it feature type-safety + composability? I'd only heard of HaskellDB before writing that stuff
<rwmjones>
type-safety yes, composability, not sure (possibly not)
<rwmjones>
it was all a bit java-ish, so I wasn't paying much attention to it at the time
pango has joined #ocaml
marmottine has quit ["Quitte"]
love-pingoo has joined #ocaml
filp has joined #ocaml
zopelander has joined #ocaml
zopelander has left #ocaml []
marmotine has joined #ocaml
bluestorm has quit [Remote closed the connection]
bluestorm has joined #ocaml
OChameau has quit [Read error: 110 (Connection timed out)]
munga has joined #ocaml
rwmjones has quit ["Closed connection"]
smimou has quit ["bli"]
munga has quit ["Ex-Chat"]
smimou has joined #ocaml
jlouis has joined #ocaml
rwmjones has joined #ocaml
mib_iaxa1ubt has joined #ocaml
<mib_iaxa1ubt>
I'm getting kind of frustrated with the pcre library. The documentation consists of a few five word long comments in the source.
<mib_iaxa1ubt>
I've been working for two days on making a regex to split a tcpdump line into a source and destination address; that took me about 10 minutes in Ruby.
<mib_iaxa1ubt>
Is there any thorough documentation anywhere, maybe with examples beyond the cryptic three that come with the ocaml pcre source?
<flux>
I'm guess the interface closely maps to the library interface
<flux>
so the original documentation can be helpful
<mib_iaxa1ubt>
Likely, but Perl 5 syntax is just slightly different than ocaml syntax, and the manpages are War and Peace.
<flux>
so you mean the regular expression syntax or the library interface?
teepark has joined #ocaml
<mib_iaxa1ubt>
But if there's no less opaque guide online, I guess that'll have to do
<flux>
I was thinking pcre documentation, not perl documentation, though
<mib_iaxa1ubt>
flux: I have a pretty good handle on regexes, as used in sed, ruby, etc.
<flux>
often times documentation for wrapper libraries can be a bit thin
<mib_iaxa1ubt>
But damned if I can tell how to use 'em in ocaml to, say, grabe a few matching groups
<mib_iaxa1ubt>
flags, iflags, rex, pat...
<mib_iaxa1ubt>
the pcre_exec function seems to be the closest I've gotten so far to actually matching a regex against a string
<mib_iaxa1ubt>
but "let the_answer = pcre_exec ~rex:test_compiled_regex 'test string'" has to be about a mile away from intuitive, given the documentation and my prior knowledge.
<bluestorm>
(it's poorer than pcre but may be sufficient in some cases)
<flux>
mib_iaxa1ubt, you did look at the file pcre.mli?
<mib_iaxa1ubt>
flux: Yup. That's the "five word comments in the source" I mentioned
<rwmjones>
mib_iaxa1ubt, you probably want to look at perlre man page too, also I use pcre a great deal in libraries such as weblogs (http://merjis.com/developers/weblogs) so grabbing the source for that might give you some idea
<flux>
mib_iaxa1ubt, hmm.. you're not referring to pcre.ml, are you?
<mib_iaxa1ubt>
It's a chicken and egg problem, the first practical project I need to do with ocaml requires regex, but until I complete a real, practical project I can't tell quite so much from reading the pcre.mli
<rwmjones>
mib_iaxa1ubt, scroll down to 'Labelled and optional arguments to functions' section
<mib_iaxa1ubt>
Neato. That may be the missing part of my puzzle. Some days I wish google supported full regex so I could search for things like ~ and #
<struk_atwork>
mib_ I wish google supported a way to search within a time span easily ( you can via getting to the advanced search, but I don't know of any key words to do it in a search bar)
filp has quit ["Bye"]
<teepark>
newbie issues related to http://dpaste.com/54385/. I suspect that I'm approaching this in a really naive way, because I'm getting tons of warnings and a 'Exception: Invalid_argument "Random.int"' (http://dpaste.com/54386/). I just don't understand what's going wrong.
<flux>
teepark, Random.int 0 is not valid
<flux>
Random.int gives a random value that is >= 0 and < n
<flux>
if n = 0, no value can be returned
<flux>
btw, (to people saying that all exceptions should be replaced with sum types) this is an example of case where I would not prefer Random.int to return int option..
<teepark>
I don't think the newlst from line 4 can have 0 length, based on the predicate funcs it gets from lines 12 and 18
<flux>
teepark, well, you could just compile the program with -g, and then export OCAMLRUNPARAM=b and run it
<flux>
it will spit out the backtrace of the exception
<flux>
that will tell you which Random.int is failing
jonafan has quit [Read error: 104 (Connection reset by peer)]
<flux>
you have only one that receives a non-constant value, so I think it's a pretty safe bet that you are infact passing zero to it..
jonafan has joined #ocaml
<teepark>
yeah, and the stack trace just confirmed that
<flux>
that is, the predicate matches no entries, or the list is empty
<teepark>
lines 42, 29, 12, 5
<flux>
hmm
<flux>
I think you have a misunderstanding on pattern matching
<pango>
teepark: you can't pattern match against previous let bindings
<flux>
match i with foo -> .. will always match, and foo will be bind to i
<flux>
so you need to replace for example line 13 with: x when x = correct -> false
<flux>
didn't the compiler warn you?
jonas_e has left #ocaml []
<pango>
also, the way you're using let ... in, I think your whole program is local definitions (local to the pick_random function)
<flux>
hmm, no?
<flux>
each function ends in 'in'
<teepark>
yeah it is. I think I just need to look at a lot of existing ocaml code to figure out a balance
<flux>
but it's still a bit non-conventional
<flux>
pango, if they were local to pick_random, it wouldn't compile, as pick_random isn't recursive
<teepark>
pick_random is just local to the rest of it all - everything until the last line is just local vars to be used in 'doloop 0 0 0'
<pango>
the print_endline's lack a begin .. end block around them
<teepark>
how is that different from single semi-colons?
<teepark>
I fixed the pattern matching sections and it's compiling, but it isn't printing right - I probably need a begin .. end block around the print_endlines :-P
<pango>
right now the 'else' case ends at the end of line 35
* orbitz
generally prefers to wrap mutliliners in ()
<teepark>
I'm not sure about my begin..end - I get a syntax error
<teepark>
now what would you do differently (probably sustantial) to make this more idiomatic ocaml?
<flux>
I would remove the trailing 'in' from all functions and replace the last in doloop 0 0 0 with let _ = doloop 0 0 0
<flux>
I might replace fun i -> match i with.. with function..
<palomer>
hrmph
<palomer>
what functions would I use to read a file and store it in a string?
<flux>
I would rename finalanswer with final_answer, doloop with do_loop (or something even better ;))
<orbitz>
palomer: input_line probably
<orbitz>
palomer: module M = Pervasives;;
<palomer>
input_line removes the newline character, right?
<palomer>
which is system dependent
<palomer>
(so to put it back would be hard)
<orbitz>
why would you want to put it back?
<pango>
teepark: pattern matching doesn't really help in most of your cases, I'd go for (fun i -> i <> correct && i <> selection) and (fun i -> i <> selection && i <> shown)
<flux>
I would remove extra parenthesis around Random.int 3 and the if conditions. do some reindentation. replace match finalanswer with.. with finalanswer = correct. keep/change_successes could maybe use another function to remove duplicity. find a way to not use List.nth.
<orbitz>
text sterams translate '\n' <-> system_dependent
<flux>
palomer, you could use the non-line interface of course
<pango>
teepark: and for result display Printf.printf is very commonly used
<orbitz>
why do match foow ith x when x = bar/ why not just do match foo with bar ->
<flux>
orbitz, oh, really?-)
<flux>
orbitz, think..
<orbitz>
what am i thinking about?
<flux>
what is expression let a = 42 in let b = 32 in match 0 with a -> false | b -> false | _ -> true?
lordmetroid_ has joined #ocaml
<orbitz>
never? when is it true if you do x when x = a?
<flux>
"x when x = a" is very different from "a" in a pattern
<flux>
note that you can remove 'let a = 42 in' and it still compiles
bzzbzz has quit [Read error: 113 (No route to host)]
<orbitz>
how is it different here though?
l_a_m has quit [Remote closed the connection]
<flux>
let a = 42 in match 0 with a -> "false" | _ -> "true" evaluates to "false"
<flux>
let a = 42 in match 0 with x when x = a -> "false" | _ -> "true" evaluates to "true"
<flux>
match 0 with a -> "false" | _ -> "true" evaluates to "false"
<orbitz>
right, but he has correct, slection, an shown defined...
<orbitz>
err
<orbitz>
wait
<orbitz>
i'mr etarded
<orbitz>
sorry
Linktim has quit [Remote closed the connection]
<pango>
teepark: I'm not sure of what you're trying to do, but, is it expected that corrent and selection will have different values between montyhall_attempt true and montyhall_attempt false evaluations?
<orbitz>
my only excuse is i've eben working in erlang for the past day so my pattern matchign is wildly differently!
<palomer>
how could ocaml possibly segfault when accessing a record field
<pango>
corrupted memory pool
* palomer
bangs head against wall
<palomer>
oh boy, making a test case for this beast is going to take a week!
<palomer>
I'm accessing self from another object
<palomer>
is this typically a problem?
<pango>
whatever you'll find won't be accepted as a bug until you can reproduce it on a sane environment ;)
<palomer>
of course
bluestorm has quit ["Konversation terminated!"]
jupiterjam has joined #ocaml
<jdh30>
palomer: what unsafe features are you using?
<pango>
struk_atwork: it's supposed to support a daterange: operator (daterange:min-max, in julian days)
<jupiterjam>
hello, is it possible to define ternary operators?
Demitar has quit ["Burn the land and boil the sea. You can't take the sky from me."]
<jdh30>
jupiterjam: only "let (+) a b c = a+b+c" so that "(3+4) 5"
<jupiterjam>
hrm.. I was hoping I could define a rounded equality operator for floats
<jupiterjam>
float_a =(0.0005)= float_b
<jupiterjam>
thanks
jupiterjam has quit ["Leaving"]
<pango>
I don't think an operator identifier can start with a parens character...
<palomer>
jdh30, I'm not doing anything unsafe at the place where it happens
<palomer>
I use marshal for saving/loading files, but I'm not doing any of that anywhere
Yoric[DT] has quit ["Ex-Chat"]
<Smerdyakov>
palomer, you seem to have a basic misunderstanding of how "type unsafety" works.
<Smerdyakov>
palomer, an incorrect use of Marshal can break any part of your program, at any time.
<jdh30>
i don't mean at the place where it happens. I mean what are you doing that is unsafe in the entire program.
<jdh30>
jupiterjam: there is no way to do that. The nearest you'll get is to define a pair of operators and make the first one return something the second one can consume and then write in a similar style a =. 0.01 =.. b or something.
<jdh30>
palomer: You have probably corrupted the run-time using marshal of FFI or something similar.
<pango>
jdh30: he's gone
<jdh30>
oh
<pango>
but yes, I was about to suggest something like that too
marmotine has quit ["Quitte"]
<jdh30>
Anyway, try "dpkg --purge ocaml" or something
guillem has quit [Remote closed the connection]
aryx has left #ocaml []
RobertFischer has quit []
hkBst has quit ["Konversation terminated!"]
<palomer>
I have no basic misunderstanding of how "type unsafety" works, though I appreciate your concern.
<palomer>
anyways, I don't call marshal any time before the program crashes
<palomer>
no FFI anywhere
<palomer>
I could trivially remove the marshalling code and get the same segfault
<Axioplase>
then try
<Axioplase>
Marshalling may add/remove some extra constraints when typing is done
<palomer>
ok, I'll remove the marshalling code
<palomer>
brb
<Axioplase>
It's not a problem of "not executed this part yet". It's a problem of "because some constraint introduced by marshalling was propagated, the type system believes expr E has type T, which may be wrong"
<palomer>
the marshaling code has nothing to do with anything, I'm marshalling one type and it's not polymorphic
<palomer>
and it's on the other side of the code planet
lordmetroid_ has quit [Connection timed out]
<palomer>
ok, removed the marshalling code
<palomer>
and same thing happens
<palomer>
which isn't a big surprise, since the marshalling code was never run in the first place (and introduces no type constraints)
<Axioplase>
quit dinner
Axioplase has quit ["dinner"]
LordMetroid has joined #ocaml
AxleLonghorn has joined #ocaml
AxleLonghorn has left #ocaml []
<jdh30>
So you haven't circumvented the type system in any way?