<Yoric[DT]>
Plus Chris King seems open to discussion :)
jonafan has quit [Read error: 110 (Connection timed out)]
<rwmjones>
anyone used it?
<Yoric[DT]>
I've tried it briefly about one year ago and it was nice.
<Yoric[DT]>
Chris implies that it has improved a lot since then.
<Yoric[DT]>
I'm planning to check it before December and, if it turns out good enough, to teach it to my students starting in January.
<rwmjones>
does it solve the problem of generating complicated database-accessing UIs easily? particularly ones where the client keeps asking for loads of annoying changes to be made?
<Yoric[DT]>
I wouldn't know.
<Yoric[DT]>
What it does help is connecting a particular menu item/button/... to some variable or behavior.
<tsuyoshi>
I kind of like lablgtk
<Yoric[DT]>
Lablgtk is alright.
<bluestorm_>
i kind of miss lablqt :-'
<tsuyoshi>
but the only thing I have to compare it to is gtk in c
<Yoric[DT]>
IMO, Chris King's stuff was better than LablGtk.
<tsuyoshi>
everything in ocaml is nicer than in c..
<Yoric[DT]>
bluestorm_: was there such a thing ?
<bluestorm_>
there isn't
<flux>
hmm, is there a decent library for generating bitmap pictures with lines, ellipses, etc?
<tsuyoshi>
well, except I was trying to mmap something today and I couldn't figure out how to make the result into a regular string
<bluestorm_>
flux: cairo is decent
<flux>
bluestorm_, how about documentation-wise?
<bluestorm_>
hm
<bluestorm_>
the API is very close to the C one
<bluestorm_>
wich is decently documented
<rwmjones>
flux, yeah the ocaml-cairo bindings
<bluestorm_>
i haven't used it a lot but it seems appropriate
<rwmjones>
alternately, generate postscript and push it through ghostscript
<flux>
cairo looks nice
* Yoric[DT]
should now write down his exam.
* Yoric[DT]
isn't motivated.
<flux>
hmph, ubuntu ocaml cairo is somehow broken; on linking stage there is a missing symbol bigarray_byte_size
<bluestorm_>
hm
<flux>
perhaps only then META-data is busted
<flux>
adjusting package order leads to undefined symbol cairo_ps_surface_set_dpi_REPLACED_BY_cairo_surface_set_fallback_resolution
<flux>
well, works with another ubuntu installation (different version)
<flux>
actually a simple domain-specific tool could work fine here :-) - any suggestions for a program that generates charts etc? gnuplot is not quite sufficient here..
<bluestorm_>
as rwmjones said, postscript graphics may be enough
<bluestorm_>
(or metapost maybe ?)
<flux>
I'm generating something for the web, I don't think ps is quite proper here - pixel point accuracy by default could be nice
<flux>
plus I bet transparency (in the resulting bitmap) can be very difficult to do with ps ;-)
<flux>
and then again postscript doesn't give very nice error messages when you fail
<bluestorm_>
hm
<bluestorm_>
has someone looked at the OcamlJava project ?
<bluestorm_>
it seems quite new, and i'm afraid it lacks workforce
<hcarty>
bluestorm_: I've looked at it, but building it is not well documented
<bluestorm_>
(this is a problem with a lot of OCaml projects actually : looks like dead meat)
Tetsuo has joined #ocaml
buluca has joined #ocaml
ramkrsna has quit [Read error: 104 (Connection reset by peer)]
Mr_Awesome has joined #ocaml
Abo-Marwan68 has quit [Excess Flood]
david_koontz__ has quit []
ita has joined #ocaml
jonathanv is now known as jonafan
pango_ has quit [Remote closed the connection]
pango_ has joined #ocaml
david_koontz has joined #ocaml
szsz has joined #ocaml
ser_ has joined #ocaml
szsz has quit [Read error: 104 (Connection reset by peer)]
ser_ has quit [Read error: 104 (Connection reset by peer)]
szsz has joined #ocaml
carmen is now known as c
jedai has joined #ocaml
bluestorm_ has quit [Remote closed the connection]
bluestorm_ has joined #ocaml
szsz has quit [Read error: 113 (No route to host)]
zbrown has joined #ocaml
<zbrown>
any ocaml gurus around?
<rwmjones>
erm
<ita>
<ita>
zbrown: no
|Jedai| has quit [Read error: 110 (Connection timed out)]
<bluestorm_>
zbrown: we use Haskell here
<zbrown>
awesome :)
<zbrown>
actually just a simple question (i think?): Whats the ideological difference between the statements "5 == 4;;" and "5 = 4;;"
<bluestorm_>
== is physical equality
<zbrown>
I'm playing in the interpreter, and noticed they both produce
<zbrown>
"woops
<bluestorm_>
that concerns only mutable structures
<ita>
bluestorm_: rhaa s'qu'elle est bonne :-)
<bluestorm_>
zbrown: on int there is no difference
<zbrown>
bluestorm_: so == is for mutable types?
<bluestorm_>
and we generally use =
<bluestorm_>
== has a meaning only with mutable types
<zbrown>
ah ok
<bluestorm_>
and is not very useful
<bluestorm_>
unless in very special cases
<rwmjones>
zbrown, you need to know how int etc are implemented to understand the difference
<zbrown>
ok, thats what I seemed to gather from the first couple chapters in Practical OCaml, I just wanted to clear it up
<zbrown>
rwmjones: ah ok
<rwmjones>
basically == is pointer equality in C
<rwmjones>
if you're familiar with that
<zbrown>
ah ok, then yes I understand that
<rwmjones>
but = looks recursively inside the structure to work out equality
<zbrown>
ah ok
<zbrown>
that makes perfect sense
<rwmjones>
but in OCaml, ints are represented as simple numbers, so there is no "inside", so = and == are the same for ints
<zbrown>
ya
<rwmjones>
but something like int64, or any structure, or pairs, tuples, etc. are all allocated on the heap and you use pointers to access them, so = and == are different in those cases
<zbrown>
ah, so = for those values is value equality, while == is pointer equality?
<rwmjones>
yup
<zbrown>
ok makes sense
<zbrown>
I suspect I won't need == much ;)
<rwmjones>
there's a function Obj.is_block which you can use to tell whether something you have is a block (accessed through a pointer) or int-like
<rwmjones>
no, I never used == I don't think
<rwmjones>
there's also Pervasives.compare which is very very similar to = but has some differences in strange corner-cases involving floating pointer NaNs
<rwmjones>
floating point (not pointer!)
<zbrown>
ah ok
<zbrown>
intersting
<zbrown>
guess I will continue reading Practical OCaml then :)
<zbrown>
thanks rwmjones
<rwmjones>
oh noes, I've just realised you're reading the cursed ocaml book :-)
<zbrown>
granted its not my first foray into functional programming... I learned erlang before and I'm more or less just trying to find the semantic and syntactical differences
<rwmjones>
zbrown, definitely suggest the Jason Hickey book/tutorial (the caltech.edu link above)
<bluestorm_>
hm
<bluestorm_>
zbrown: is erlang typed ?
<zbrown>
bluestorm_: actually no
<bluestorm_>
that is a major difference
<zbrown>
though I have modest eperience in Haskell
<zbrown>
so I have some view in both areas
<bluestorm_>
:p
<zbrown>
and I've worked on a few things in scala
<bluestorm_>
then i'd be interested to know
<rwmjones>
zbrown, what about SML?
<bluestorm_>
how is it difficult for a Haskeller to learn Ocaml
<rwmjones>
I used haskell at uni
<bluestorm_>
and what he thinks of the compared langage difficulties
<rwmjones>
but that was before the standardized version & it was missing things like monads
<bluestorm_>
i personally think Haskell is "more complex", but strangely a lot of peoples seems to disagree
<zbrown>
rwmjones: no real experience there
<rwmjones>
someone sent me an SML book to review, so I read it, but it just seemed like a more limited OCaml
<zbrown>
bluestorm_: haskell is a beautiful language but an impractical language
<bluestorm_>
hm
<rwmjones>
although apparently the current compilers rock
<bluestorm_>
there are some SML fans here
<bluestorm_>
and Smerd. made an interesting comparison
<zbrown>
bluestorm_: it is often impractical to work in haskell for things as you're too busy trying to maintain the beauty when sometimes it is often just to hack a solution out without minding the niceities too much
<rwmjones>
bluestorm_, I found Haskell to be basically slow & memory intensive. Is it better now?
<bluestorm_>
hm
<rwmjones>
that was GHC, circa 1994 though
<bluestorm_>
i am very new to haskell
<bluestorm_>
so i doens't know the situation back then
<bluestorm_>
but there still seems to be some performances issues
<zbrown>
rwmjones: ghc produces binaries that are comparably as fast as C now
<bluestorm_>
(in particular, compiling GHC take hours)
<bluestorm_>
zbrown: ... sometimes
<zbrown>
rwmjones: the biggest issue with haskell unless you declare everything strict is the unpredictability of performance and memory usage
<zbrown>
which was a deal breaker for me
<zbrown>
bluestorm_: "typically
<zbrown>
"
<bluestorm_>
hm
<c>
Yi, the emacs-in-haskell-instead-of-elisp used 200 MB of ram on launch here, and was pretty slow to start
<rwmjones>
someone wrote emacs in haskell?? that's just wrong
<bluestorm_>
rwmjones: someone wrote emacs in OCaml too
<Yoric[DT]>
ghc's binaries looked quite good to me.
<bluestorm_>
(efuns, Ed, iirc)
<Yoric[DT]>
I only did some simple stuff on it, but, well, it worked.
<zbrown>
I want to be able to predict how my code is going to act and worry about optimizing later since the majority of the code I work on is computational models...
<rwmjones>
does GHC have a native code generator now?
<zbrown>
rwmjones: nope
pango_ has quit [Remote closed the connection]
<zbrown>
rwmjones: there was an article recently on reddit about clean vs haskell and why clean was faster
<rwmjones>
it used to compile via gcc, which I found very clumsy
<zbrown>
clean has an excellent native code generator
<zbrown>
rwmjones: it goes ghc -> c-- -> C -> native code
<bluestorm_>
what is strange to me is than hm
<bluestorm_>
GHC does a lot of clever optimizations
pango_ has joined #ocaml
<zbrown>
yup
<bluestorm_>
while OCaml is a very crude compiler
<zbrown>
though Clean has a leg up still ;)
<bluestorm_>
but produces typically faster executables
<bluestorm_>
this must be related to the lazyness
<rwmjones>
ocamlopt is quite a literal compiler
<bluestorm_>
wich maybe is difficult to compile efficently
<rwmjones>
I found that to be true when I was doing some work with neural networks a couple of years ago
<rwmjones>
moving all the invariant code out of a loop (by hand) make it faster than C
<rwmjones>
but we had to do it by hand ...
<bluestorm_>
but it's still strange to see some really beautiful deforestation and the like, and still have something slower
smimou has joined #ocaml
<bluestorm_>
rwmjones: aren't then any projects concerning ocaml optimization ?
<bluestorm_>
hm
<rwmjones>
everyone gets hung up on C as the "competitor"
<bluestorm_>
actually the real question is : would more optimisation increase typical programs speed ?
<rwmjones>
but in fact the competing languages (in open source anyway) are turds like python
<zbrown>
python is far more elegant than ruby could ever be
<rwmjones>
well, that as well, but python is more popular
<zbrown>
indeed but at least python is useful and plenty of app use it
<zbrown>
it actually has a runtime that isn't fundamentally flawed
<zbrown>
ruby's runtime is beridden with leaks and crap code
<rwmjones>
honestly, the big problem we have here is people applying patches to python, and accidentally re-indenting code while doing it, which changes the semantics of if-statements and the like!
<zbrown>
Guido van Rossum at least knows what the hell he's doing
<c>
ruby has lots of runtimes. including Squeak-style and JVM
<zbrown>
c: true, but its still an abomination
<rwmjones>
python's runtime seems to be slow & takes up loads of RAM afaict
<rwmjones>
& leaks too
<c>
does Mono have a F# project?
<c>
or will they just tweak ocamlc/opt?
<rwmjones>
apparently f# runs on mono
<zbrown>
bluestorm_: either way I've written several different models each in OCaml and Haskell (maybe not to their best optimizations) and found that OCaml frequently has a shorter and quicker solution
<zbrown>
rwmjones: it should
<rwmjones>
Jon seems to be promoting it heavily at the moment
<zbrown>
F# is actually what I signed on at MS to work on next summer
<rwmjones>
is that in cambridge uk, or ms research labs?
<zbrown>
I think its MSR Redmond
bzzbzz has quit ["Lost terminal"]
<zbrown>
but by the time I get there it will have a unit in Developer/Server tools
<zbrown>
as they're now pushing it and moving it into production
<rwmjones>
interesting times ...
<zbrown>
this is all tentative of course, but if all goes well, I'll have some blogs and stories to share this summer
david_koontz has joined #ocaml
<rwmjones>
they're already using OCaml to verify their drivers, or so I heard
<zbrown>
rwmjones: yup they do use it, I have a friend thats a tester for OS division and he works on some of the verification code
<zbrown>
he and another friend that works on Stirling (business security product) were the ones helping me out getting an internship there
<bluestorm_>
hm
<bluestorm_>
i regret we do not have a vocal Ocaml community
<rwmjones>
there's a company over in Wales who verify the Airbus A380 software (written in C!) using OCaml programs
<bluestorm_>
i'll end bookmarking every ocaml blog post i see
<bluestorm_>
and then threatening everyone with some weapon, to create a planet :-'
<zbrown>
lol
<zbrown>
bluestorm_: well as functional programming becomes more prevalent I'm sure it will grow
<bluestorm_>
hm
<zbrown>
bluestorm_: especially with F# being pushed, that should help as well
<bluestorm_>
Haskell is doing great work on community building
<rwmjones>
more likely you'll see fp concepts becoming more mainstream -- eg. Java and C# both now do a very limited form of type inference
<bluestorm_>
and their language is even more brain-damaging than ours
* Yoric[DT]
is working on verifying Firefox extensions using OCaml programs.
<bluestorm_>
so i don't think waiting for the "favorable times" will help
<bluestorm_>
on the other hand
<rwmjones>
Yoric[DT], seriously? URL??
<bluestorm_>
i can't write english blog posts, and doesn't have anything interesting to say
<zbrown>
bluestorm_: to be honest, I avoided ocaml til now after reading several blogs from last year about ICFP contestants who used ocaml and bitched about some issues they had (i forget now what they were) but either way about 2 months ago i snapped out of it and realized that was stupid to do so here i am
<bluestorm_>
so it's difficult for me to criticize others :-'
<zbrown>
bluestorm_: and now I regret not having started using it earlier as it would have saved me time from digging into haskell which I find beautiful but like I said, fairly useless
<bluestorm_>
it's funny to see that the google team won the contest
<hcarty>
bluestorm_: I think there is an OCaml planet site
<bluestorm_>
zbrown: i don't think learning haskell is a waste of time
<rwmjones>
it's more about the libraries really
<zbrown>
bluestorm_: well lets put it this way, it was a waste of development time at work as I used work time to learn it
bzzbzz has joined #ocaml
<zbrown>
bluestorm_: it wasn't a waste of intellectual time but it was a waste of time at work
<rwmjones>
so Yoric[DT] it's trying to assign static types to JS variables?
<zbrown>
bluestorm_: I appreciate the knowledge I picked up from it, but it just isn't... easy to hack out solutions in
<bluestorm_>
zbrown: this is why i love being a student :p
<zbrown>
bluestorm_: I'm a student :)
<zbrown>
bluestorm_: but I work two jobs along with taking 18 hours so go figure lol
<zbrown>
bluestorm_: so ya between teaching Scheme to 7th graders and writing computational models for a researcher I have little time outside to do much elese lol
<bluestorm_>
zbrown: does it work ?
<bluestorm_>
(i mean the 7th graders)
<zbrown>
bluestorm_: quite well
<hcarty>
zbrown: What setup do you use to teach Scheme to them? My brother isa bit older than that, but looking to learn to program
<Yoric[DT]>
rwmjones: sssh, don't say that :)
<zbrown>
hcarty: we base our material off of "The Little Schemer" book
<zbrown>
hcarty: I work for IMACS (Institute for Math and Comp Sci)
<rwmjones>
Yoric[DT], no, that's a good thing! Wish you could do it for python too ...
<Yoric[DT]>
rwmjones: but yeah, the final objective is essentially to add a type-and-effects system to a subset of JavaScript 2.
<zbrown>
basiaclly we teach gifted students advanced math and computer science
<Yoric[DT]>
rwmjones: only one language at a time.
<Yoric[DT]>
JS2 will be hard enough...
<zbrown>
hcarty: our CS program includes mostly functional programming, we do very little outside of functional programming
<bluestorm_>
zbrown: what are the advanced maths like ?
<zbrown>
bluestorm_: lambda calculus, though at a younger age (1st grade through 8 grade) they usually stick with binary math and formal logic
<zbrown>
as they get older we get into lambda calculus and theorem proving