<slacker403>
if ocaml generated a little more tiny executeables and a tad bit faster it would be perfect
<slacker403>
right now its just good :)
<flux>
I doubt the
<flux>
the 'tad bit faster' is really a feasible goal
<slacker403>
cant be more optimized ?
<flux>
I believe getting faster would need some bigger changes - it would speed up more than a tad bit, though
<slacker403>
or as i said before turn it into the gcc intermediate code or w/e and have gcc optimize it
<slacker403>
theres also no reason for a 80 KB hello world
<slacker403>
they jus need to make the compiler a bit better
<slacker403>
i wonder how much money in donations they get
EliasAmaral has joined #ocaml
<slacker403>
i dont think they get enough money or something
<flux>
I'm thinking 0 EUR. I believe inria.fr is financed by the government of France.
<slacker403>
o shit ?
<slacker403>
well
<slacker403>
i think if people donated it would be better
<EliasAmaral>
is there a way to get the terminal size (eg. 80x25) with ocaml standard library?
<EliasAmaral>
I expected to see this in Unix library..
<flux>
eliasamaral, I quickly peered over the module, but couldn't find it
<flux>
the terminal does know it, though..
<flux>
so this might actually require interfacing with the C library
<flux>
(with your intermediate code)
<rwmjones>
EliasAmaral, there is a binding for curses, just let me find it ...
<EliasAmaral>
there is a third part library, ocaml-tmk..
<flux>
or you could pick .. those
<rwmjones>
EliasAmaral, yes that's the one ... I think there was someone working on updates to it as well
<flux>
it's funny how those curses libraries haven't ended up in debian
<flux>
but I suppose they've been on the drift for quite a long time - no website, just a svn (or cvs?) repository
<flux>
and I'm not sure even if that's being maintained
<rwmjones>
they're not very mature ... at one point I had a go at fixing them, but to be honest I don't have a lot of use for ocaml apps written with ncurses
<EliasAmaral>
I didn't wanted this because I wanted to say "type sudo aptitude install thisthis, make, ./run"... I just wanted to show a tiny code to some people that also uses ubuntu, but the code works only in 80x25 terminals..
<flux>
eliasamaral, you could run resize -u and parse the result ;-)
<EliasAmaral>
!! great idea:)
<flux>
and you can show off ocaml's great suitability for parsing tasks, too!
<EliasAmaral>
ahahahahaha :) the only problem is, i can't put this in the inner loop, so i can't check if the user has resized the window
<EliasAmaral>
but that's ok
<rwmjones>
EliasAmaral, catch SIGWINCH
<EliasAmaral>
nice :)
<flux>
hmm.. I wonder if it's bad in ocaml to do anything you want in a signal handler?
<flux>
in C there are things you can do and cannot do
<flux>
but is it handled by the ocaml runtime in ocaml? how about with native code?
<flux>
without knowing the answer a solution might be to only set a flag in the signal handler, and poll that flag (wherever you're interested about the screen size)
<EliasAmaral>
Hmmm... but what you can't do in a signal handler in C?
<rwmjones>
it's safe because the enter/leave_blocking_section macros protect you from signals
<EliasAmaral>
I though a signal handler just suspended the current execution and executed something else, some sort of longjmp
<rwmjones>
see byterun/signals.c
<flux>
I think stuff like doing reading fifos is bad
<rwmjones>
and asmrun/signals.c
<flux>
but yes, due to memory management ocaml has to handle signal handling with flags
<rwmjones_>
yes, hopefully one day they'll get into fedora 7
<psnively>
1.1.2pl1...? And hmmm... src.rpm... what about us Mac OS X users?
<rwmjones_>
well basically findlib compiled just fine with 3.10.0 ... what was the problem you had?
<descender>
rwmjones, ah ok. I wrote a .spec file for findlib for inclusion into the then Fedora Extras but never got a follow-up after the initial review
<psnively>
Oh, yeah, it does compile fine.
<rwmjones_>
descender, I'm pushing hard on this one
<descender>
yeah, I'd love to see it in
<psnively>
On the mailing list, though, someone mentioned that there are issues around the new camlp4.
<psnively>
I think we're going to have to see how findlib fares with code making extensive use of camlp4.
vital303 has quit [Client Quit]
* rwmjones_
is interested in anyone that can get PXP to compile on OCaml 3.10
<rwmjones_>
I had a brief go today, but didn't get very far ...
<psnively>
I'll look into it. I ended up rolling back to 3.09.3 personally--there's just too much camlp4 stuff that needs updating.
<Smerdyakov>
I never upgrade OCaml outside of the normal flow of packages into Debian testing. :)
EliasAmaral has quit [Read error: 110 (Connection timed out)]
<slacker403>
pango_: i will join ..............but i think i could pay 4 k usd and get better lcuk for what i want from other people
<Smerdyakov>
slacker403, did I miss some context here?
<slacker403>
i was saying i should donate to the ocaml project
<Smerdyakov>
That won't help.
<slacker403>
i would like to see better optimization for ocaml
<Smerdyakov>
It's run by researchers who keep control over the project.
<Smerdyakov>
And the group leader is more interested in verification than plain compilers now.
<slacker403>
the generated bins and speed is not where it needs to be
<Smerdyakov>
Support Standard ML development instead. MLton already has a thriving development community.
<slacker403>
thats why i said i would pay other people ;)
<slacker403>
ocaml is faster then mlton atm
<rwmjones_>
you keep asserting this, but have been strangely reluctant to show us any code
<Smerdyakov>
How do you quantify that?
<Smerdyakov>
rwmjones, to whom did you say that?
<slacker403>
rwmjones_: most atatics show this
<slacker403>
statistics
<slacker403>
every benchmark i have saw puts ocaml about 4 steps behind c c++ d etc
<slacker403>
except that one you showed me
<Smerdyakov>
What a coincidence that the one I showed you probably has the most care put into it!
<rwmjones_>
"most statistics" "every benchmark" this is meaningless. Either you have a specific problem piece of code which we can help you optimise, or you are trolling
<slacker403>
im not trolling
<slacker403>
i was goinng to use ocaml for a big project thats all
<Smerdyakov>
slacker403, it's reaaaally easy to see how OCaml makes abstraction veeeerry expensive.
<Smerdyakov>
slacker403, try composing a functor many times.
<Smerdyakov>
slacker403, each time adds running time in OCaml, but not with MLton.
<psnively>
Functorial-based development pays a nasty penalty, relatively speaking. So what?
<slacker403>
im jus saying the compiler should be really improved
<Smerdyakov>
psnively, so it's bad to have to think about performance costs of abstractions, so one should prefer MLton.
<slacker403>
i use ocaml imperative most of the time functinal sometimes
<Smerdyakov>
psnively, OCaml has this long list of "performance gotchas" programmers need to keep in mind. MLton's list is qualitatively smaller.
<psnively>
Smerdyakov: MLton is fine if you can afford to do whole-program development.
<Smerdyakov>
psnively, eh? It's only a cost in compiling release versions, as you use SML/NJ otherwise.
<slacker403>
whats the difference syntax wise between ocaml and mlton ?
<Smerdyakov>
slacker403, it can't be summarized in one line. It's standard divergent evolution that began in the 80's.
<Smerdyakov>
Yes, it's very different in many minor ways.
<psnively>
I actually wish Alice ML weren't dependent upon GTK. It'd be very interesting otherwise.
<slacker403>
Alice ML ?
<Smerdyakov>
psnively, did you not realize SML/NJ and MLton compile the same language, or is there some other concern that motivated your saying that one is forced to do whole-program development to take advantage of MLton?
<slacker403>
why would the language depend on GTK ?
<Smerdyakov>
slacker403, English never has spaces before question marks.
<rwmjones_>
slacker403, the prudent thing to do, as in any language, is to take a small part of your big project and test it out in, say, OCaml and mlton. When and if it doesn't meet the performance requirements that are so important to you, post to a list and allow others to help you optimise it. If that fails to get results maybe the language isn't for you or can't perform to your requirements.
<psnively>
Smerdyakov: MLton is a whole-program compiler.
<Smerdyakov>
psnively, and I can write an OCaml compiler that only starts when it finds a proof of P=NP or P<>NP. What's the point?
<psnively>
slacker403: Well, "the language" per se doesn't, but the actual implementation does, so it's quite difficult to build on Mac OS X.
kelaouchi has joined #ocaml
<Smerdyakov>
psnively, because you can use other compilers for a language that has enough of a standard to enable the creation of many compatible compilerzs.
<rwmjones_>
util you've done that, please restrain from making comments about how ocaml's compiler isn't"quite there yet"
<psnively>
Smerdyakov: the point is that MLton, as a matter of policy, includes defunctorization (which is only possible given a whole program), whereas O'Caml, not being a whole program compiler, doesn't include defunctorization. Else they'd likely be even more directly competitive.
<slacker403>
is there really anyways to optimize ocaml code though ?
<slacker403>
pre complination ?
<Smerdyakov>
psnively, I don't understand why you thought that was worth saying.
<psnively>
Yes: use a defunctorizer on it. Unfortunately, the available defunctorizer (third-party) is out of date.
<mattam>
There is a project to make an ocaml frontend for mlton apparently.
<psnively>
Smerdyakov, sorry; I thought you were arguing for SML development based on MLton's quality.
<Smerdyakov>
psnively, I am.
<psnively>
Smerdyakov: then my reason for my statement should be obvious.
<Smerdyakov>
psnively, what does the cost of whole-program compilation, which happens once per release cycle, contribute to a decision to avoid MLton?
<slacker403>
which compiles better ocaml or mlton ?
<slacker403>
benchmark wise mlton is lower then ocaml ?
<Smerdyakov>
slacker403, MLton kicks OCaml's ass on any realistic project.
<slacker403>
o?
<Smerdyakov>
slacker403, and even does slightly better on microbenchmark sets like that at the Shootout.
<mattam>
mlton has more optimization, ocaml has good code generation for itself it seems
<slacker403>
is there any good other compilers out for ocaml that are more optimized then the official ?
<Smerdyakov>
slacker403, no, there is only one.
<mattam>
Nope, not yet.
<slacker403>
ah
<slacker403>
my boss would prolly pay 30 k for one
<psnively>
Smerdyakov, it means that one must work in development in, e.g. SML/NJ, then compile using MLton for delivery, assuming that your program is amenable to whole-program delivery. One advantage of byte-compiled O'Caml is dynamic linking. This benefit is also being developed for native code in Alice ML.
<Smerdyakov>
slacker403, it is VERY unlikely there will ever be another, because there is no language standard, or any definition outside of "what the single compiler does today."
<mattam>
As I said there is a project...
<Smerdyakov>
psnively, OK, so you give dynamic linking as a good reason to prefer OCaml, but it seems you agree that there is no appreciable downside for SML based on MLton's whole-program nature.
<psnively>
SML is a very good conservative choice for developing whole programs.
<psnively>
O'Caml is a very good choice if you're interested in how non-strict, non-pure functional languages evolve over time.
<Smerdyakov>
And hardly anyone is interested in such historiography.
<tsuyoshi>
psnively: we have dynamic linking with native now too
<Smerdyakov>
Rather, they want useful implementations in the present..
<psnively>
Smerdyakov: If you wish to develop whole programs and don't mind using two compilers to do so, sure.
<psnively>
Smerdyakov, on the contrary; many people are keenly interested in dynamic linking in any ML family member.
<Smerdyakov>
psnively, why would I mind using two programs? Do you mind that gcc uses ld? Would GCC be better if 'ld' were folded into it?
<psnively>
tsuyoshi: the natdynlink branch?
<tsuyoshi>
yeah
<psnively>
Not quite ready yet, but getting there.
<Smerdyakov>
I'm going to propose that any project that incurs significant costs from using two different compilers for a language must be so trivial that language choice hardly matters to begin with.
<psnively>
Smerdyakov: not two programs, two compilers for "the same" language. At the least, it raises bug-for-bug compatibility concerns.
<psnively>
On the contrary; the issue really only matters for complex programs making heavy use of the language's "corner cases."
<slacker403>
how well can you optimize your code pre complination ?
<Smerdyakov>
There aren't many corner cases when you have a language standard and the level of development effort that SML gets.
<Smerdyakov>
I've never found ANY language semantics disagreement between SML/NJ and MLton in my implementations that I compile with both.
<psnively>
Smerdyakov: I'll buy that when we have a certified SML compiler.
<psnively>
Yeah, I mean, sure, it's a lot better than going from one C++ compiler to another.
<Smerdyakov>
What a weird viewpoint. It's not like there's a huge tragedy when you find an incompatibility of the magnitude that's likely to have any chance of remaining.
<Smerdyakov>
And, you know, I get the impression that you're speculating, while I'm developing real software that hundreds of people use every day, using SML with easy switching between SML/NJ and MLton.
<psnively>
Smerdyakov: That depends upon how rapidly compiler bugs get fixed.
<mattam>
slacker403: why are you so concerned about optimization ?
<Smerdyakov>
mattam, English never has spaces before a question mark. :)
<psnively>
Let me assure you that I'm not speculating. Granted that the situation in SML is orders of magnitude preferable to that in 99% of other languages.
<Smerdyakov>
psnively, you've used SML on a "real" project?
<psnively>
Yes.
<slacker403>
i dunno
<slacker403>
not really concerned just if i need it
<psnively>
I'm only saying that, as a matter of personal preference, I like the fact that O'Caml gives me a toploop, bytecode compilation with time-travel debugging, and native-code compilation, all in one system.
<psnively>
It'd be nice if the defunctorizer were maintained, but it's not killing me that it isn't.
<Smerdyakov>
psnively, and you used both SML/NJ and MLton and found problems?
<slacker403>
defunmctionizer ?
<psnively>
Smerdyakov: yes.
<Smerdyakov>
psnively, example?
<psnively>
Smerdyakov: the code didn't survive (this was, oh, two and a half, three years ago).
<Smerdyakov>
psnively, ah, that's a significant slice of MLton's lifetime, so you should expect a better situation now, for one thing.
<mattam>
Smerdyakov: got it wrong everytime, thanks.
<Smerdyakov>
psnively, second, I'd still like to hear an example, if you can remember one in general terms.
<psnively>
Smerdyakov: no doubt true, and let me reiterate, I'm VERY HAPPY that MLton exists and is getting the attention in the community it deserves.
<psnively>
Smerdyakov: the general problem related to sharing constraints on modules--again, a rather nasty edge case.
<Smerdyakov>
psnively, and there wasn't a way to change your code to make both compilers happy?
<psnively>
Smerdyakov: Maybe. I wasn't successful in finding one.
<Smerdyakov>
I never use 'sharing', anyway, so we could just consider SML minus sharing. :)
<psnively>
I have actively directed people to SML/NJ + MLton, so I apologize for seeming to overstate the case.
<psnively>
I like SML.
<psnively>
Yeah, I mean, let's face it: once you get into functors, by definition, you're at the edge.
<Smerdyakov>
I've not found that to be the case.
<psnively>
Smerdyakov: No, you wouldn't have. ;-) But consider how little documentation they have, how few people understand "generative" vs. "applicative" functors...
<Smerdyakov>
I'm sure all the main MLton and SML/NJ authors understand it.
<slacker403>
heh i will just use ocaml
<slacker403>
and optimize it the best i can
<psnively>
Oh, no doubt. I'm just saying that functors are a very sophisticated use of modules. Lots of programmers just think of "modules" as "how you do separate compilation."
<Smerdyakov>
And you're proposing this as a reason that they should prefer OCaml?
<psnively>
slacker403: I'll be gobsmacked if you come up with anything where O'Caml native compilation just isn't good enough (and, say, MLton compilation is).
<psnively>
Smerdyakov: no.
<Smerdyakov>
Anyway, both SML and OCaml are crap so far as simple denotational semantics, so I'm not betting on either horse in the long run. :P
screwt8 has quit [Remote closed the connection]
<psnively>
As opposed to what? The SK combinator calculus? ;-)
<Smerdyakov>
All the languages I design have simple translations into the Calculus of (co)Inductive Constructions.
<Smerdyakov>
Many useful subsets of Coq have this property, f'rinstance.
<psnively>
Ahhhhhhhh.
<psnively>
I see. Start with a much more general axiom-free reduction.
<psnively>
Yes, I'm working through the Coq'Art book, actually.
<psnively>
I do like Coq quite a lot.
<Smerdyakov>
#coq :-
screwt8 has joined #ocaml
_blackdog has left #ocaml []
rwmjones_ has left #ocaml []
slacker403 has quit [Connection timed out]
screwt8 has quit [Read error: 104 (Connection reset by peer)]
screwt8 has joined #ocaml
Submarine has joined #ocaml
qwwqe has joined #ocaml
ygrek_ has quit [Remote closed the connection]
leoni has joined #ocaml
ygrek_ has joined #ocaml
<leoni>
hello, can someone help me with this: List.iter (let f x = print_string x) ["a";"b"];; ? what's wrong?
<Smerdyakov>
Reading the language grammar should show you.
<haelix>
leoni: let f x = returns nothing
<Smerdyakov>
haelix, I would say that is a wrong answer. This is a problem already at the level of parsing.
<haelix>
Smerdyakov: well, reminds me of an old discussion with you already
<tsuyoshi>
you probably want List.iter print_string ["a";"b"]
<haelix>
let's say I tried to show the "engineering level" understanding
<Smerdyakov>
I try to avoid using the products of engineering who don't understand the difference between syntax and semantics. ;)
<Smerdyakov>
s/engineering/engineers/
<zmdkrbou>
leoni: you should use print_string as tsuyoshi said, but fyi the syntax for anonymous functions is "(fun x -> print_string x)" for example, and not "(let f x = print_string x)"
<haelix>
:ME HIDES
* haelix
hides
<haelix>
Smerdyakov: a real question for you, though
<haelix>
I've tried to wrap my head around the "coq proof assistant"
<haelix>
and
<haelix>
hu
<Smerdyakov>
haelix, #coq
<mbishop>
Better than trying to wrap your mouth around it
<leoni>
thanks everyone. I missed the anonymous declaration syntax
<psnively>
You don't wrap your head around coq. Coq wraps its head around you.
<G>
rwmjones: pong
_JusSx_ has joined #ocaml
ygrek_ has quit []
Mr_Awesome has joined #ocaml
vadimtk has joined #ocaml
_JusSx__ has joined #ocaml
cjeris has joined #ocaml
_JusSx__ has quit ["leaving"]
leoni has quit ["Leaving"]
haelix has quit ["leaving"]
haelix has joined #ocaml
_JusSx_ has quit [Read error: 110 (Connection timed out)]
<leo037>
you know what ?
<psnively>
I give up. :-)
<leo037>
I've written, in the past few days, an ocaml program
<leo037>
and now, I better code in other language :)
<leo037>
recursion and accumulators are a good coding practice :D
<psnively>
Ah. Yes, I think one of the underappreciated benefits of working in languages with a better formal foundation is that the mindset transfers.
<psnively>
Indeed.
<leo037>
and coding like that is even near bug-free by design
<Smerdyakov>
leo037, if you're still using explicit recursion, you're only half-way there. ;-)
<Smerdyakov>
(Higher-order functions are the remaining piece.)
<leo037>
ho yes
<leo037>
the next step :)
<leo037>
It's a bit complicated : I know it but for the moment I didn't manage using it :)
<leo037>
the fun part is when using ocaml native code compared to matlab :)
<leo037>
ocaml : 3/100 sec, matlab : 13h :)
<leo037>
"Oooh.... What is the name of your language, you said ?"
shawn_ has joined #ocaml
shawn_ has quit [Client Quit]
shawn_ has joined #ocaml
pants2 has joined #ocaml
shawn_ has quit [Connection timed out]
shawn_ has joined #ocaml
Len2 has quit [Remote closed the connection]
slacker403 has joined #ocaml
pants1 has quit [Read error: 110 (Connection timed out)]
<slacker403>
i know people in here yesterday said using fcc would be stupid for a front end but it does a hell of a job optimizing ......... why not just have ocaml use gcc for optimizations ?
<Submarine>
for once the stack frame is not formatted like C's
<Submarine>
C is *not* portable assembly
<psnively>
Because C is a lousy intermediate language for OCamlm.
<psnively>
OCaml, even.
vadimtk has quit [Read error: 110 (Connection timed out)]
love-pingoo has quit ["Connection reset by pear"]
<psnively>
slacker403: I still don't understand why you're of the belief that OCaml's native code isn't adequate for your purposes.
joshcryer has joined #ocaml
<slacker403>
ocaml i think will be fine
<slacker403>
but still improving shit will be needed
<psnively>
Why?
<slacker403>
ok nevermind
<slacker403>
all im saying is ocaml with perforamcne of C would really give it a great boost
<Smerdyakov>
slacker403, and I think the channel has collectively told you to keep that to yourself unless you have specific insights to share. ;)
<psnively>
OCaml is already plenty close to C, and getting it to 100% of C (whatever that even means) is impossible, if for no other reason than that garbage collection overhead can't be zero.
<slacker403>
it could be much closer trust me
<psnively>
The point, simply put, is that "fast enough at runtime" is app-dependent anyway.
<slacker403>
they dont focus on compiler optimizations
<psnively>
slacker403: Um, with all due respect, trust is earned, and many here understand the OCaml language and its compiler vastly better than you do.
<Smerdyakov>
psnively, maybe you should stop encouraging. ;)
<psnively>
Smerdyakov: a worthy point. :-D
<psnively>
slacker403: What the OCaml team have done is do an excellent job of developing a "what-you-code-is-what-you-get" object/functional/imperative language.
<slacker403>
i was just suggesting
<slacker403>
hot damn
<psnively>
Heck, you even get unpacked arrays of floats, and big arrays in either C or FORTRAN layout for speed and easy integration with nasty C/FORTRAN code.
<slacker403>
money can do alot
<psnively>
All we're saying is that very smart people have thought/are thinking about these issues, and that there isn't a trivial path to improving OCaml's runtime.
<psnively>
And, if we're going to talk economics, there isn't much motivation to, relative to other goals.
<Smerdyakov>
psnively, maybe you should stop encouraging. ;)
<Submarine>
slacker403, C is not portable assembly, that's the point.
qwwqe has quit ["Leaving"]
<Submarine>
slacker403, Did you try J# with a JIT-enabled .net runtime?
<Submarine>
er F#
leo037 has quit ["Leaving"]
cjeris has quit [Read error: 104 (Connection reset by peer)]
shawn_ has quit [Read error: 113 (No route to host)]
eumenides has joined #ocaml
bluestorm_ has joined #ocaml
benny_ has joined #ocaml
bluestorm_ has quit ["Konversation terminated!"]
noteventime has quit [Remote closed the connection]
<mbishop>
C makes a fairly nice target, but there are better things to target, if you ask me :P
benny has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
ProphetZero has joined #ocaml
<ProphetZero>
so how are things going?
ProphetZero has quit ["ChatZilla 0.9.78.1 [Firefox 1.5.0.1/2006011112]"]