<salierix>
"Performance notice: values of type int32 occupy more memory space than values of type int, and arithmetic operations on int32 are generally slower than those on int. Use int32 only when the application requires exact 32-bit arithmetic."
<sgnb>
an int32 is a 32-bit integer
<sgnb>
(as in int in C on a 32 bit machine)
<asmanur>
salierix: because Int32 are stored like blocs
<asmanur>
but you have only 32 bits for the integer itself
<sgnb>
in memory, it is larger, but you don't have to care
<salierix>
Oh.
<sgnb>
(as asmanur said)
yminsky has quit []
<salierix>
Why is "begin" sometimes used in if statements?
<sgnb>
begin/end are like parentheses
<sgnb>
"begin t end" is equivalent to "(t)"
<sgnb>
you have to use it sometime because of priorities
<Yoric[DT]>
Actually, "int" is platform-dependent.
<sgnb>
for example : if a then b; c else d is parsed as "(if a then b); c else d" which is nonsense
<Yoric[DT]>
It's 31 bits on 32 bit platforms, 63 bits on 64 bit platforms.
<sgnb>
so you have to use if a then (b; c) else d
<Yoric[DT]>
This "begin...end" stuff actually disappears in the revised syntax.
<salierix>
sgnb, I don't see what the first part is trying to do even if it was legal.
<salierix>
Oh, I understand.
<salierix>
; sequences things. I forgot.
<salierix>
Does ocaml have support for efficient bit arrays?
ulfdoz has quit [Read error: 60 (Operation timed out)]
yminsky has quit []
<flux>
I suppose that depends on the definition of "support"; you can do it now with multiple processes, by using message passing (or in the extreme, shared memory)
<flux>
judging from the comments of xavier leroy an actual two threads of ocaml code running concurrently in the same address space looks unlikely
ulfdoz has joined #ocaml
<salierix>
What about that software transactional memory stuff? Think we'll ever get hardware support for that?
<flux>
we well; look up 'htm' and 'hytm'
<flux>
there is this an ocaml "threading" library that attempts to seamlessly traditional ocaml green threads and ocaml processes; infact I think it even supports such things across the network. for shared data stm is provided.
<salierix>
How do I fork the running process in ocaml?
<flux>
Unix.fork ()
<flux>
you will need to provide your own communication though; the Marshal-module might be helpful
<flux>
(one cool feature: you can pass closures too; limited so that the receiving and sending ends must be the same binary)
<salierix>
What I want to do is embarrassingly parallel so I only need to return a result.
<flux>
you could implement a function pmap
<flux>
it has been implemented in this channel a few times..
<flux>
one approach: for map inputs into file descriptors to processes that are performing the mapping, and the map those descriptors to what they feed you
<flux>
s/for //
<flux>
let fds = List.map (fun i -> let (i, o) = Unix.pipe () in if Unix.fork() = 0 then let v = i () in .. marshall to o.. else i) inputs in List.map (fun fd -> ..unmarshall fd, close it, join process..) fds
<flux>
that will not work well when you have much more inputs than processors, though ;)
<salierix>
I still have to learn more ocaml first though I think.
<flux>
someone on the channel had a pmap that took that into account, perhaps he can join in..
<salierix>
Is "Developing Applications With OCaml" still good?
<flux>
I haven't read it, but it is constantly being praised
<salierix>
It's a little old now though right?
<flux>
right
<flux>
but for the most part I doubt that matters; after having read that, one should be able to march through the manual too (which is always a good idea)
<salierix>
OCaml for Scientists sure is expensive.
ita has joined #ocaml
ygrek has joined #ocaml
love-pingoo has joined #ocaml
<Yoric[DT]>
salierix: there's support for SMP.
<Yoric[DT]>
It's called CoThreads.
<Yoric[DT]>
It's a library.
<flux>
has anyone actually given a spin to the library? I haven't yet..
<Yoric[DT]>
Not yet.
<Yoric[DT]>
I'm planning to.
<flux>
it isn't quite the same as using threads in, say, C, where you can split a large bitmap into two regions and have two threads manipulate their own regions?
<flux>
atleast without separately making said bitmap into shared memory..
vpalle has joined #ocaml
<flux>
but I guess having stm work with that library will be helpful
<salierix>
Why is "1.0 == 1.0" false but "1 == 1" is true?
<flux>
1.0 are boxed: they are stored in memory as a pointer and the value at the end of the pointer
<flux>
== compares those pointers
<salierix>
Ah.
<flux>
1.0 allocates a new memory location for the value; such addresses will differ
<flux>
you usually want to use =
<flux>
using == is in my experience very rare, and needs some thought before using it..
<flux>
it is perhaps a bit unfortunate that they picked two so similar operators..
<flux>
also, = is to <> what == is to !=
<flux>
that actually has bitten me atleast once :-o
<flux>
(used != when I intended to use <>)
<salierix>
Good to know.
buluca is now known as mac
pango_ has quit [Remote closed the connection]
seafoodX has quit []
mac is now known as buluca
pango_ has joined #ocaml
crathman has joined #ocaml
crathman has quit [Remote closed the connection]
<vorago>
flux, i still ocaml is better hire than PHP
<vorago>
flux, AFAIR they use == and === and I never know which is which.
<ita>
=== is comparison without implicit casting ? :-)
<vorago>
i -> i think; hire -> here. Think, then type...
<bluestorm_>
ocaml use =
jlouis has joined #ocaml
<bluestorm_>
and keeps == for nasty things
<bluestorm_>
it's useful to have a keyword that let you say "ok, you're going to blow yourself up because of that very line"
<vorago>
Yes; but this is error prone for many developers which come from C/C++. So we are discussing approach.
<bluestorm_>
Haskell have UnsafePerformIO for exactly the same purpose, i guess
<vorago>
Hm.
<vorago>
It could be something like /ignore/.
<ita>
i have always found funny that array bound checking does not exist in c, as if the optimization was worth the resulting bugs
<vorago>
I guess it's doable with camlp4.
robozni has joined #ocaml
tetsuo_ has joined #ocaml
<vorago>
ita, gcc supports -fbounds-check
<vorago>
Hm... wait a minute.
<ita>
vorago: yeah, wait a minute :-)
<vorago>
Only for fortran and java. ;s
Tetsuo has quit [Read error: 104 (Connection reset by peer)]
<vorago>
So it really stinks. ;p
<bluestorm_>
i'm not sure C really make sense to the "bound checking" idea anyway
<vorago>
It does during debugging stages. But they can be more/less done with GDB.
<vorago>
debugging and testing.
<ita>
vorago: just like python, work with the debugger and do the compiler's work
<Yoric[DT]>
IMO, array bounds checking is a typical case of "worse is better".
<Yoric[DT]>
that is, the absence of array bounds checking is "worse is better".
<ita>
Yoric[DT]: i suspect the compiler guys were too lazy to implement it
<Yoric[DT]>
A very good reason to use OCaml (or Java, or C#...), but there is a whole category of people who consider that they're better without it.
<ita>
compiling c is really hard
<Yoric[DT]>
ita: well, that's part of "worse is better" :)
<Yoric[DT]>
Are you kidding ?
<ita>
no
<ita>
compiling c is difficult
<Yoric[DT]>
Unoptimized compilation of C looks trivial.
<ita>
Yoric[DT]: haha, make a preprocessor for c first
<Yoric[DT]>
I might be wrong, but it maps nearly directly to assembly language.
<ita>
nope
<Yoric[DT]>
What's difficult about the preprocessor ?
<Yoric[DT]>
It's barely more than a lexer.
<vorago>
Well it has some quirks.
<ita>
the ## the # the macro rules and the other niceties
<ita>
some quirks
<ita>
yeah, that's everybody says
<Yoric[DT]>
Well, maybe, but does it make C harder to compile than, say, OCaml ?
<ita>
do it, and you will change your mind
<vorago>
##, #, ..., __FILE__, __LINE__, __FUNCTION__, other. But doable.
* Yoric[DT]
admits he's no expert about compiling C.
<ita>
yes, c is much harder to compile than ocaml
* Yoric[DT]
usually compiles *to* C.
<bluestorm_>
you could compile to OCaml too
<ita>
first, lexing c is difficult (requires semantik info for the comments)
<bluestorm_>
the prolog guy achieved convincing results
<Yoric[DT]>
ita: what do you mean semantic info for the comments ?
<Yoric[DT]>
bluestorm_: well, yes, I could, but then I would have to teach OCaml to my students first :)
<Yoric[DT]>
Which is kind of difficult in 10 hours.
<bluestorm_>
what are you teaching ?
<ita>
Yoric[DT]: "/* \" */" /* hehe */
<Yoric[DT]>
ita: it's just a widely complex regexp, isn't it ?
<ita>
Yoric[DT]: no
<flux>
ita, compiling c must be easy if that's the difficult part :)
<Yoric[DT]>
ita: oh, because of the quotes.
<Yoric[DT]>
Is that it ?
<Yoric[DT]>
bluestorm_: depending on the days, Java, OCaml, mathematics for computer science, DBMSes and compilers.
<flux>
now, compiling c++, on the other hand..
<Yoric[DT]>
bluestorm_: compilers in one university, everything else in the other.
jlouis_ has quit [Read error: 110 (Connection timed out)]
<ita>
Yoric[DT]: then, remember that c requires several passes over the code (trigraphs, comments, macros, then the lexing and parsing)
<ita>
Yoric[DT]: erf ?
<flux>
ita, btw, "(* \" *)" (* hehe *) is the ocaml case; I would expect that from all the languages with block comments..
robozni has quit ["leaving"]
<flux>
if you wanted to target a new platform, you could just use an already-existing preprocessor
<Yoric[DT]>
ita: I must admit I forgot what trigraphs are all about.
<flux>
and I doubt implementing c preprocessor can be _that_ hard.. I don't know in which stage trigraphs should be handled, but I would expect they would be first
<Yoric[DT]>
Well, ok, so C is a crap spec.
* Yoric[DT]
returns to OCaml anyway :)
<ita>
Yoric[DT]: ??= represents a #
<ita>
Yoric[DT]: and for digraphs, %: represents a # too
<Yoric[DT]>
I surrender, I surrender !
<salierix>
Why do so few ocaml programmers seem to use objects?
<flux>
I wouldn't strictly call those multiple passes anyway, because they can be performed at the same time
<Yoric[DT]>
salierix: because 99% of the time, there's a better mechanism for doing the same thing with less code and faster results.
<flux>
ita, how much forward lookup does trigraphs or comments require?
<flux>
or even macros
* Yoric[DT]
returns to parse JavaScript, which *is* easier.
<ita>
salierix: because functions can be embedded into other functions (closures and scopes), so where a hierarchy of classes is needed, a few nested functions do it much more elegantly
<ita>
flux: the comments cannot be parsed until the trigraphs are transformed
<flux>
ita, but really, can't that be built into the lexer itself?
<flux>
although I suppose the definition of pass I used isn't quite universal.. I wonder what is, though
<ita>
flux: the lexer is not a lexer already, as it needs semantik info for lexing .. :-)
<ita>
it is like xml, it looks all nice and simple until you have to actually parse it
<vorago>
Hah, good comparison.
<flux>
about xml: atleast how openoffice uses it.. it's fscking impenetrable!
<Yoric[DT]>
XML never looked nice :)
<vorago>
No wonder. if C is actually that complicated think how complicated is C++ compiler with their templates etc.
<vorago>
No wonder that there actually exist _no_ full c++ standard implementation.
<vorago>
Of comeau after implementing export keyword has full standard support... it would be one compiler only.
<ita>
vorago: let's say that there are c++ programs that we cannot know if they compile or not
<flux>
well, atleast there are multiple implementations. things are simple when there's only one implementation, and the specification is basically "what the implementation does" ;)
<flux>
judging from the traffic in c++ newsgroups, those undefined corner cases, bring a lot of questions
<ita>
(since c++ templates are turing-complete)
<vorago>
Yeah. This is what I hate about them most.
<vorago>
I've seen Functional-language done using C++ templates.
<vorago>
List parsing etc.
<vorago>
It looked horrible. I'd kill for using sth like this in projects.
<flux>
:-)
<flux>
templates in c++ are like another language in c++
<flux>
I hear in D things might be better. and they're becoming slightly better in c++, too
<Yoric[DT]>
Well, just like Camlp4.
<Yoric[DT]>
Except, of course, that Camlp4 is OCaml :)
<ita>
flux: they *are* another language (turing complete)
* Yoric[DT]
has played (too much) with templates.
<flux>
ita, well, technically they aren't, because it's part of C++ standard, no?-)
* Yoric[DT]
has played with Java generics.
<vorago>
But they generally should be functor - like. Not camlp4 like.
* Yoric[DT]
has played with Camlp4.
<flux>
yoric[dt], yes, but the mechanism how it works is quite different
* Yoric[DT]
know which one he chooses.
<flux>
yoric[dt], it would be fun if the type information was available in camlp4
<Yoric[DT]>
flux: I'm sure there's a way to get that somehow.
<ita>
flux: it is a sub-language within the language .. ? :-)
<Yoric[DT]>
But you'd need several passes.
<Yoric[DT]>
camlp4 -> ocaml -i -> camlp4
<flux>
templates - and overloading - in right hands can result in some beautiful and concise code
<flux>
in wrong hands.. well ;)
<vorago>
Preprocessor shouldn't have unlimited power. ;p
<flux>
vorago, like camlp4?-)
<ita>
vorago: double negation ?
<flux>
or lisp..
pango_ has quit [Remote closed the connection]
<vorago>
Hm, right. I meant C++ templates have too much power. Recursive calling and creating templates for compile-time calculation I guess should not take place.
<flux>
the capability to generate code based on types of expressions is quite a powerful feature
<vorago>
Is it possible (as I don't know camlp4) to do recursive camlp4 calls?
<bluestorm_>
"camlp4 calls" ?
<Yoric[DT]>
vorago: probably. Depends on what you mean by "camlp4 calls".
<Yoric[DT]>
Camlp4 *is* OCaml.
<Yoric[DT]>
So, yeah, you have recursivity.
<Yoric[DT]>
You use OCaml to pre-process OCaml.
<Yoric[DT]>
(just like Lisp)
<Yoric[DT]>
Somewhat as what Ruby or Python allow, except for Ruby or Python, it's during execution, while for OCaml it's during compilation.
<bluestorm_>
hm
<bluestorm_>
but camlp4 is purely syntaxic
<vorago>
Hm. C++ templates are used for things which they won't intended for.
<bluestorm_>
while reflexion and meta-programming are based on semantic properties
<vorago>
camlp4 I guess is more generic.
pango_ has joined #ocaml
<Yoric[DT]>
bluestorm_: fair enough.
<Yoric[DT]>
Still an apt comparison, I believe.
<flux>
I don't buy the reason "x wasn't intended for y" for explaining why doing y is bad. it is not that uncommon that things will find a wider range of use than what the author originally visioned.
<bluestorm_>
flux:
<bluestorm_>
in the templates case
<flux>
of course, sometimes I buy that: I wouldn't want to see a real application written in brainfuck :-)
<bluestorm_>
i think that means the original complexity was not in control
<bluestorm_>
"wider range" is a benefit from solid foundations
<bluestorm_>
"WTF ranges" mean the original design maybe wasn't that careful
<flux>
I've heard that the explanation why LaTeX is turing-complete is because many things needed to be described, and it would have been more (much more?) difficult to devise a language that would provide all that - instead of going in and just make sure everything you want is possible, by going to turing completeness
<flux>
actually, read that just a few days back, perhaps a link from reddit..
<flux>
for programming languages.. well I suppose there were even at the time c++ was designed examples or working solutions for that particular domain
<flux>
but atleast the implementations so far haven't (before mlton?) haven't been quite 'c-like'; that is, if you want to really construct special-case code for all types etc
* Yoric[DT]
assumes the design of C++ started with the words "Cthulhu f'taghn".
<vorago>
flux, sure but it's even more implementation defined then. Like,
<ita>
Yoric[DT]: jejeje
<flux>
sml apparently came around at 1990
<vorago>
flux, some calculations need recursive use of templates. Depth of recursion depends only on compiler,
<vorago>
flux, and still is awful.
<flux>
vorago, yeah, it's nice to have compilations always terminate
<flux>
vorago, but those cases rarely come up. they might, if you use some template combinator library for doing something fun, though..
<vorago>
flux, well; there are plenty of sites on how to do 'template metaprogramming'. People learn to use it.
<flux>
I'm quite sure compilers need to support a certain level of template instantiations also.. although I recall some boost code suggests the user to up the number a bit ;)
<flux>
could sml type system have been retrofitted into c (in the form of c++ml or something), while keeping backwards compatibility and maintaining the things a c-programmer expects? perhaps.. perhaps I would need to buy some book from stroustrup to see what he was thinking ;)
<vorago>
;d
<Yoric[DT]>
You know what they say about mad arab poets :)
<flux>
although then again, haskell type classes are in practice more powerful than modules, although modules would be nice there too - and c++ templates already cover that (well, mostly)
tetsuo_ has quit ["Leaving"]
<flux>
c++ still has quite a lot of verbosity. I wonder what closures and type-inference would do to that..
* Yoric[DT]
is still trying to understand the difference between type classes and modules + functors.
<flux>
yoric[dt], have you read the paper on that? [I haven't]
<Yoric[DT]>
The proble, iirc, is that G'Caml maintains a run-time type.
<Yoric[DT]>
IIRC, type classes don't.
<flux>
don't they?
<Yoric[DT]>
You have to manually specify the type, though.
<flux>
there is atleast dictionary passing going on
<Yoric[DT]>
But that doesn't look like a major problem for me.
<Yoric[DT]>
I might be wrong, though, I'm no Haskell pro.
<flux>
let's say you have a function do_show : Show a => a -> String do_show a = show a (this might not be valid, I haven't looked at haskell for quite a while)
<flux>
if that function is to be compiled only once, some runtime information must be passed to that function for that to work..
<bluestorm_>
iirc Haskell sometimes use runtime dictionnary, and sometimes doesn't
<flux>
and it is my understanding that it doesn't generate one do_show for each type
<flux>
like c++ would..
<flux>
deriving looks cool - it just feels a bit redundant to have to point out the types explicitly.. what whatcha gonna do.
<Yoric[DT]>
Operator overloading would be nice.
<vorago>
In OCaml/
<flux>
some of the examples on that deriving intro look like magic :)
<bluestorm_>
because there is some camlp4 magic under the hood i guess
<bluestorm_>
(although i haven't looked into the code yet)
<bluestorm_>
yallop is doing interesting things
<bluestorm_>
his other project on Google Code (click on his name to see the url) is a little camlp4 extension wich looks really nice
<flux>
now only if someone wrote a campl4 type inference module.. ;-)
<Yoric[DT]>
:)
<bluestorm_>
flux: camlp4 type inference ?
<Yoric[DT]>
The problem is that you'd need a way to extend that type inference.
<flux>
and ocaml would go to the undecidable land too! (I guess)
<bluestorm_>
hm
<flux>
bluestorm_, you know, like determining types of expressions at camlp4 stage
<bluestorm_>
err
<bluestorm_>
looks like a strange idea
<flux>
which can be tricky as the code could change the types
<bluestorm_>
and very complex too
<bluestorm_>
are you not looking for a generic generic programming solution like MetaOCaml ?
<flux>
but that would make those pesky explicit type annotations go away.. Show.show<int list> [1; 2; 3]
<flux>
I must admit I haven't taken a look at MetaOCaml
<bluestorm_>
i've seen promising things concerning MetaOCaml integration with Coq somehow
<bluestorm_>
(at the type level)
<flux>
coq.. now that's something I would be interested in learning, but haven't found the time
jenny2 has joined #ocaml
<flux>
ah yes, concoqtion, I saw it earlier
<flux>
or is that just one example of that integaration
Abo-Marwan has joined #ocaml
jenny2 has quit [Client Quit]
<vorago>
How is camlp4 related to ocamlyacc and ocamllex?
<flux>
it isn't
<vorago>
Ok.
<vorago>
Just like I thought.
screwt8 has joined #ocaml
<vorago>
It would be queer; I've written two, three parsers and still have no idea about camlp4.
<bluestorm_>
flux: concoqtion is the thing i was thinking at
<hcarty>
Is there a way to #use multiple files in the toplevel after loading a camlp4 extension?
<hcarty>
A first #use works ok, but a second gives "I/O error: Bad file descriptor"
<hcarty>
Which makes testing things in the toplevel a pain
<salierix>
Should I use the revised syntax or not?
<bluestorm_>
salierix: what for ?
<bluestorm_>
ita: i'm interested in monads for the idea of behavioral genericity
<bluestorm_>
not precisely error reporting or I/O
<ita>
bluestorm_: yes, i understand
<flux>
does metaocaml bring anything else except performance?
<flux>
hm, indexed types were mentioned.. so I suppose yes
<flux>
perhaps I need to read the whitepaper through first, not ask questions during reading it ;)
<salierix>
bluestorm_, in general.
asmanur has quit [Connection timed out]
<hcarty>
salierix: It's somewhat of a personal choice. The original syntax is used more often, but there are tools to automatically convert the syntaxes back and forth
<bluestorm_>
i considered the choice this summer
asmanur has joined #ocaml
<bluestorm_>
and i concluded that the best thing to do syntax-wise would be to use my own personal syntax
<bluestorm_>
(a mix from the standard and revised one)
<bluestorm_>
then i got lazy and stuck with the standard one
<bluestorm_>
moreover, this raises question about inter-developpers communication and so on
<bluestorm_>
salierix: you should try to use it for a while, and see
<bluestorm_>
i used it for camlp4 extension, and while i think a part of it is really nice, some bits are heavy to use
<bluestorm_>
(i'd say the [ ] on pattern matching and the different things to do with ; )
<salierix>
What's the dirrence between camlp4 and camlp5?
<bluestorm_>
for the 3.10, camlp4 got a partial rewrite
<bluestorm_>
it's incompatible with former versions
<bluestorm_>
the original author of camlp4 is not happy with these changes
<bluestorm_>
so he "forked" : took the old camlp4 and created camlp5
<bluestorm_>
the confusing thing is, camlp5 is closer to 3.09 camlp4 than 3.10 camlp4 is
<flux>
hm, the metaocaml white paper doesn't touch the capability to extend ocaml type system.. I wonder what concoqtion does, then. extends metaocaml also?
<vorago>
I'd like to create a robot with AVR Atmel which would be able to balance itself.
<vorago>
So that's why I've written this simulation.
<pango_>
379.75s. Beat that ;)
<vorago>
With timeres 0.0005?
<vorago>
I doubt I could. ;p
Thunderfoot has quit []
<pango_>
didn't change anything to the source
<vorago>
So 0.0005.
<vorago>
It's not well timed.
<vorago>
But it should be more/less the same on all fast computers.
<vorago>
In line 187 you've got simulation parameters.
<pango_>
Unix.select only guarantee is that it will take _at least_ the requested time
<vorago>
Sure. And I had quite big problem.
<vorago>
select was broken each time an event occured.
<pango_>
but it's free to use more, depending on OS scheduler,...
<vorago>
So this is why there's a recursive function for sleeping.
<vorago>
I guess it would be better to use lablgl + gtk. But it was supposed to be simple.
buluca has joined #ocaml
<vorago>
I guess it's harder with switched h_mass and l_mass
bluestorm_ has quit [Remote closed the connection]
<pango_>
it should be more accurate to measure the deltat between display refreshes and use that to update parameters
<pango_>
rather than trying to enforce a static timeres (you won't get accurate 0.0005 pauses unless the kernel is compiled with HZ >= 2000, which is still an unusual setup those days)
<vorago>
Sure I wasn't thinking about real-time display.
<vorago>
Rather about more/less accurate simulation.
<pango_>
(just checked that stock Debian kernel uses CONFIG_HZ_250)
seafood_ has quit []
<vorago>
I wonder. It would be rather hard to calculate in real-time model situation at time t
<vorago>
For any t given
buluca has quit [Read error: 113 (No route to host)]