cdidd has quit [Remote host closed the connection]
ulfdoz_ has joined #ocaml
thomasga has quit [Quit: Leaving.]
ulfdoz has quit [Ping timeout: 272 seconds]
ulfdoz_ is now known as ulfdoz
iago has quit [Read error: Operation timed out]
iago has joined #ocaml
iago has quit [Quit: Leaving]
<adrien>
ssbr_: Oug maybe
emmanuel__ has quit [Remote host closed the connection]
Se7en1 has joined #ocaml
Se7en2 has quit [Ping timeout: 248 seconds]
bjorkintosh has quit [Ping timeout: 244 seconds]
oriba has quit [Quit: oriba]
Tobu has quit [Ping timeout: 248 seconds]
mjonsson has joined #ocaml
<thelema_>
hcarty: renamed ulib to uniclib in batteries git
lamawithonel has quit [Ping timeout: 272 seconds]
<adrien>
sounds like "unique"
JoeyA has joined #ocaml
Tobu has joined #ocaml
cdidd has joined #ocaml
emmanuel__ has joined #ocaml
lamawithonel has joined #ocaml
JoeyA has quit [Quit: Leaving]
X1z0r has quit []
Hussaind has joined #ocaml
Hussaind has left #ocaml []
smerz has quit [Remote host closed the connection]
tautologico has quit [Quit: tautologico]
wtetzner has quit [Remote host closed the connection]
mjonsson has quit [Remote host closed the connection]
emmanuel__ has quit [Remote host closed the connection]
Se7en1 has left #ocaml []
gnuvince has quit [Ping timeout: 250 seconds]
gnuvince has joined #ocaml
ankit9 has joined #ocaml
eni has joined #ocaml
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
ankit9 has quit [Ping timeout: 245 seconds]
cdidd has quit [Read error: Operation timed out]
eni has quit [Ping timeout: 250 seconds]
ankit9 has joined #ocaml
Snark has joined #ocaml
Submarine_ has joined #ocaml
Submarine_ has quit [Changing host]
Submarine_ has joined #ocaml
Submarine_ has quit [Client Quit]
pseudonym has joined #ocaml
pseudonym is now known as pseudonick
<pseudonick>
hi there, I am wondering how object identifiers are used in OCaml
<pseudonick>
does ocaml reuse object identifiers? That is, if I create an unbounded number of objects that are used only for a limited period each, what happens?
<_habnabit>
'object identifiers' ?
<pseudonick>
whatever x contains when I write x = new myclass
<pseudonick>
let x = new myclass
<_habnabit>
are you having some issue? I don't know what you're trying to ask here
<pseudonick>
I would like to know about ocaml's implementation of objects
<pseudonick>
and in particular if a (maybe recursive) program that allocates an unbounded number of objects will crash
<pseudonick>
or what happens
<pseudonick>
under the assumptions that not all the objects are used
<pseudonick>
but e.g. only the freshest is used in each moment
<_habnabit>
why don't you try it and see
<pseudonick>
because it may take a long time to reach the maximum
<pseudonick>
I don't know how an object identifier is implemented
<pseudonick>
so I don't even know the max
<pseudonick>
I would need to read the source code so I am asking experts instead
<pseudonick>
actually, I implemented the program
<_habnabit>
I would be very much surprised if there was a limit that was smaller than being bounded by available memory
<_habnabit>
have you had issues in other languages, or something? it's kind of a strange question to ask
<pseudonick>
I do research in programming languages
<pseudonick>
so this is a question about ocaml, not about its usage
<pseudonick>
however it's relevant
<pseudonick>
e.g. implement an infinite loop in ocaml that allocates things
<pseudonick>
like an operating system or whatever you may think of
<pseudonick>
will this program live forever (assuming integers wrap at max_int which is what I remember)
<_habnabit>
probably
<pseudonick>
anyone willing to try a more precise answer? :)
<_habnabit>
maybe if you ask a more useful question
eni has quit [Ping timeout: 245 seconds]
<pseudonick>
habnabit define "useful question"!
<pseudonick>
<pseudonick>
bye all
pseudonick has quit [Quit: irc2go]
ankit9 has quit [Ping timeout: 245 seconds]
ankit9 has joined #ocaml
<Drakken>
It sounds like pseudonick was just asking about the garbage collector.
<Drakken>
I had a similar once with record trees. The program kept huge structures in memory even though they couldn't be accessed anymore and it needed room for new data.
Se7en1 has joined #ocaml
<Drakken>
a similar _problem_
<adrien>
they could still be accessed :-)
<Drakken>
no they couldn't :-)
<flux>
but things like the halting problem prevent the GC from seeing that. however, there was a path from your visible variables and functions to the tree?
cyphase has quit [Ping timeout: 256 seconds]
cdidd has joined #ocaml
probst has joined #ocaml
ulfdoz has quit [Ping timeout: 252 seconds]
probst has quit [Client Quit]
cyphase has joined #ocaml
ulfdoz has joined #ocaml
Tobu has quit [Ping timeout: 248 seconds]
Tobu has joined #ocaml
GPHemsley has quit [Read error: Operation timed out]
ulfdoz has quit [Ping timeout: 260 seconds]
ulfdoz has joined #ocaml
Cyanure has joined #ocaml
<Drakken>
no, they were shadowed all the way to the end of the environment they were defined in.
<Drakken>
that's not the halting problem, it's a simplistic gc
<adrien>
nah
<adrien>
it's because your variables were still in scope, even if shadowed
ulfdoz has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
<Drakken>
that's simplistic. the shadowed trees could be collected if the code were analyzed better.
<adrien>
it hurts badly the first time but all you need to do is to make shorter functions
<adrien>
anything that makes the GC more complex or make it do more work also makes it slower
<Drakken>
what about that object recursion? there's only one allocation per call.
<adrien>
now, Qt's horror: getting connect() right
<flux>
hey, c++ nowadays has way to initialize lists inline and lambdas, so you could just do something like iter({foo, bar}, [](Bar* a) { a->hello(); }) given appropriate library ;)
<Qrntz>
adrien, I seem to have problems with finding any info on it except the bitbucket repo yet
<adrien>
it always takes me several tries to get anything with it
<pippijn>
flux: I'm not using C++11
<Qrntz>
it seems like actually being meant for use with qt 4, though, my bad
<pippijn>
the Qt SDK on windows doesn't come with a supporting compiler
<adrien>
yypkg!
<adrien>
now I only need to fix binutils
eni has quit [Ping timeout: 250 seconds]
<flux>
pippijn, but there is hope for c++
<adrien>
C++11 is a bit like GADTs for OCaml
<pippijn>
flux: a little
<adrien>
except that with GADTs, tehre's only one thing we're having troubles completely getting and using; in C++11, there are dozens =)
<adrien>
&&& ftw!
<adrien>
(or was one of the new operators only "&&"?)
<mrvn>
They should have defined that like in ocaml. Everything starting with a basic operator is also an operator.
<pippijn>
adrien: && is a new type operator
<pippijn>
mrvn: nope
<pippijn>
mrvn: it wouldn't be backward compatible with C
<adrien>
it's not compatible anyway =)
<pippijn>
it would be much worse
<pippijn>
it wouldn't even be syntactically compatible
<mrvn>
pippijn: they should have done that from the start
<Qrntz>
wait, «&&» is a type operator?
<pippijn>
in C*
<pippijn>
?
<Qrntz>
seems to me even worse than using right/left bit shift for IO
<pippijn>
Qrntz: yes, just like * and &
<pippijn>
and [] (postfix type operator)
<Qrntz>
hrmph
<pippijn>
int &&ref = 3;
<mrvn>
Qrntz: why do people always complain about << >> for io? It makes perfect sense if you think about shifting chunks in or out of a stream.
<pippijn>
mrvn: I agree
<adrien>
mrvn: because it's not readable and already in use for other things
<adrien>
in other *unrelated* things
<mrvn>
adrien: it is no more or less readable than a + b
<mrvn>
adrien: what unrelated things?
<adrien>
what's the equivalent of printf's %0.2f with iostream?
<pippijn>
oh, + reminds me of something that confused me yesterday
<pippijn>
I do java for a living.. and..
<adrien>
and +: addition, for floats, or integers, or ...
<mrvn>
adrien: out << <some format modifier> << f
<adrien>
<< and >>: I/O or bit-shifts; it might "look" fine with the pipe analogy but it's not the same thing at all
<adrien>
mrvn: and "%0.2f, %0.2f\n"? and which format modifier?
<mrvn>
adrien: 0x17 >> 4, takes 4 bits out of the bit stream and leaces the rest. Same as with IO. Just a different size of chunks.
<adrien>
(the bulldozer CPUs were pretty bad; piledriver is apparently _way_ better)
<adrien>
(and the basic chipset will allow for 32GB of memory while you have to pay a lot to get that on an intel chipset)
<mrvn>
I wondered when they would have multiple cores that share functional units (like an fpu).
<adrien>
AMD's merging process of computation units is on-going; ultimately, the address space should be shared
<adrien>
oh, and with AMD stuff: IOMMU for everyone (which makes quite a lot of sense considering the need to access the graphic units)
<pippijn>
oh, good
jamii has quit [Ping timeout: 252 seconds]
<flux>
some big company should buy AMD and push it to make it a real competitor to intel :)
<adrien>
well, the upcoming CPUs are apparently much better than what was released last year, like +15% performance, -15% power, and graphics are also improved
<adrien>
otoh, what intel is releasing now hasn't improved much
<adrien>
so the gap should narrow quite a lot
<adrien>
and amd's new architecture is, well, new so it shouldn't be a surprise that it starts less good
<adrien>
but it has room to improve
<adrien>
and, well, I was believing it but the general-purpose APUs in laptops from last year from AMD are plenty fast, even for compilation
<adrien>
and they don't suck battery
<adrien>
(noone really knows why AMD suddenly stopped taking that much power for laptops)
Anonyme44893 has joined #ocaml
ivan\ has quit [Ping timeout: 248 seconds]
ivan\ has joined #ocaml
<mrvn>
.oO(Hey, why do we have a 10 Ohm resistor between the chips + and - pins? That just wastes power. lets remove that.)
<adrien>
heh, maybe ;-)
<adrien>
but iirc, with llano, it was really "Oh, they suddenly got +50% battery life?"
iago has joined #ocaml
jamii has joined #ocaml
Tobu has quit [Quit: No Ping reply in 180 seconds.]
Tobu has joined #ocaml
Tobu has quit [Changing host]
Tobu has joined #ocaml
Zerbugug has joined #ocaml
<Zerbugug>
hi
<Zerbugug>
what is the best way to implement a module where everything will depend on given int parameters ?
<mrvn>
Zerbugug: Will you have many different sets of them or just one or two per program?
<Zerbugug>
probably one per program
<mrvn>
Then you could use a functor taking a module with all the parameters.
<Zerbugug>
(if you know some algebra : i want to implement finite fields of cardinal p^n, where p = 2 or 3)
<mrvn>
Zerbugug: urgs, 3?
msimoni has joined #ocaml
<mrvn>
Zerbugug: I have some code for p=2 and n=8 and n=16.
<mrvn>
C code that is. still need to write the ocaml stubs.
<Zerbugug>
i'd like to make it all in ocaml
<Zerbugug>
and generic
<mrvn>
that will be ineficient
<Zerbugug>
i don't need to, i'd just like to :)
<Zerbugug>
what will be inefficient ? the generic part ?
<mrvn>
yes
<Zerbugug>
do you think I should just write two separate modules ?
<mrvn>
How will you represent numbers? int?
<Zerbugug>
yes
<Zerbugug>
if I implement p=2 separately I'll use the binary representation
<mrvn>
How large will n be?
<Zerbugug>
I don't know yet, but 8 is probably enough
<mrvn>
The nice thing with binary is that + becomes xor and with small n you can do a lookup table for *
gnuvince has quit [Ping timeout: 250 seconds]
<Zerbugug>
that's what I meant to do
<mrvn>
I guess for 3^8 you can still do a lookup table for + and *
<Zerbugug>
I don't even think I'll go up to n=8 for p=3
<Zerbugug>
maybe 5
<mrvn>
My problem was that for 2^16 a lookup table is way to big. So I made lookup tables for log and exp and left * as exp (log x + log y)
<Zerbugug>
i planned to represent every number as a power of a primitive root X
<Zerbugug>
this way X^i * X^j = X^(i+j mod p^n)
<mrvn>
Zerbugug: but then + is complicated
<Zerbugug>
and X^i + X^j = X^i * (1 + X ^ (j-i))
<Zerbugug>
this way the look up table is linear
<Zerbugug>
2 ^ 16 ints is still rather huge, though
<Zerbugug>
er, actually no
<mrvn>
I would just represent the numbers as int where the coefficients of the constructing polinom are the digits in a base p number system.
<mrvn>
2^16 is 65536 so 128k for a log/exp table.
<mrvn>
8Gib for +/*
<hcarty>
thelema: Thanks!
curryboy has joined #ocaml
<Zerbugug>
mrvn : i think I'll just implement p = 2 and n <= 8 for now
<mrvn>
Makes sense to me. Otherwise you will have to pass something as first argument to all your functions to get the n and any lookup tables
<mrvn>
Or you need to store n in some reference.
<Zerbugug>
that sounds very ugly
<mrvn>
yes
<Zerbugug>
ok, i'll get to work, thank you
<mrvn>
Zerbugug: How do you do + with p=3?
<curryboy>
so, I'm interested in learning ocaml. What type of things is ocaml good for? sorry if the question is a bit too generic, I'm just trying to understand what type of stuff to use it for and whattype of stuff avoid implementing in ocaml
<Zerbugug>
mrvn : the way I described above
<mrvn>
Zerbugug: That still has a (1 + X ^ (j-i)) term.
<Zerbugug>
I use a lookup table for 1 + x
<mrvn>
curryboy: try following the manual
<mrvn>
Zerbugug: but how do you create that?
<Zerbugug>
that's the question
<Zerbugug>
it's possible by hand, with some random choices, I haven't thought a lot about it but it can certainly be implemented as an algorithm
<mrvn>
Zerbugug: if you represent the numbers as the coefficients then you can just split it into the coefficients and add each module p and then combine the result to a number again.
<curryboy>
mrvn: I've done some reading of the manual already, including the tutorial, but..was looking for something more synthesized
<mrvn>
curryboy: Anything functional will do. Try to avoid things that inherintly need mutables.
<mrvn>
e.g. don#t write a gui toolkit.
<curryboy>
ok!:)
<Zerbugug>
if I can't find how to genrte the 1+x table I'll use your way
<mrvn>
curryboy: one think that I always liked is writing silly games, Tic-Tac-Toe, with a computer oponent.
<curryboy>
cool idea!
gnuvince has joined #ocaml
<curryboy>
any good books or reference material other than the tutorial/manual?
<hcarty>
mrvn: I haven't read through the hex field one much for that reason. But the square tile implementation looks like it would be an excellent candidate for exansion into a tutorial
<mrvn>
hcarty: he has every other row indented half a tile to form the hex grid. So going top-left changes depending on which row you are.
<mrvn>
hcarty: The square and hex tiles would make a great exercise for functors too.
<mrvn>
or using first class modules to write a polymorphic maze solver.
<hcarty>
mrvn: Those would be nice additions. From a tutorial standpoint, that gives a lot of room to grow from beginner to advanced topics.
<mrvn>
What I miss sometimes is a tutorial that gives a bunch of simple problems and then shows the different ways of solving them using variants, records, tuples, modules, objects, functors, ...
<mrvn>
An experts tutorial
<hcarty>
Maybe ocamlpro can be convinced to add mock Graphics module support using canvas to tryocaml...
<mrvn>
curryboy: Another simple and fun thing to write is turtle graphics.
<hcarty>
mrvn: Agreed. An experts tutorial like that would be particularly helpful when features like GADTs are added to the language.
<mrvn>
curryboy: The turtle can raise and lower its tail, move forward and turn left/right. There is paint on its tail so if lowered it leaves a trail.
<hcarty>
I haven't used the Graphics module past the first six months or so of using OCaml, but I'm really glad it's there. It's nice to have a built-in visualization mechanism, even if it isn't sophisticated.
<mrvn>
curryboy: and then you can do fun stuff like draw polygons, circles, snow flakes or trees.
<mrvn>
hcarty: esspecially since it isn't sophisticated. It needs to be trivial to use.
<hcarty>
mrvn: True. Even down to things like easily grabbing the value of a specific pixel.
<hcarty>
That kind of thing was huge when it learned BASIC. It was equally useful when learning OCaml.
<hcarty>
s/it/I/
<mrvn>
hcarty: One thing bugs me though. Graphics doesn't have a concept of different mouse buttons. Sometimes I needed more than one.
<hcarty>
mrvn: That may be a worthwhil addition/patch. I don't know how easy it would be to add.
<hcarty>
worthwhile. Ack, I can't type.
<mrvn>
hcarty: changes the type of Graphics.status. status.button would go from bool to int, int list or bool array.
<mrvn>
hcarty: I wonder who wrote the Graphics.X11. All it can do is open and close sub windows. But you can't do a single thing with them.
<mrvn>
curryboy: write me a pong game please
<hcarty>
Mazes, pong, and sprite animation all tend to be fun projects
<hcarty>
mrvn: That's unfortunate... multiple windows may be overkill for something like the Graphics module. But it's still unfortunate.
<mrvn>
hcarty: yeah. I would have expected it to have all the functions from Graphics but extended to include a window_id as first argument.
<curryboy>
mrvn: sorry, was not paying attention to irc
<curryboy>
thanks for all the tips/suggestions :)
Cyanure has quit [Ping timeout: 244 seconds]
iago has quit [Ping timeout: 244 seconds]
emmanuel__ has joined #ocaml
BiDOrD has quit [Read error: Operation timed out]
BiDOrD has joined #ocaml
emmanuel__ has quit [Read error: Connection reset by peer]
jamii has quit [Read error: Connection reset by peer]
munga has joined #ocaml
msimoni has quit [Quit: Leaving.]
iago has joined #ocaml
jamii has joined #ocaml
<curryboy>
mrvn: just out of curiosity, why a pong game?
<mrvn>
nostalgia
<mrvn>
If you haven't lived history, repeat it. :)
<hcarty>
A jumping in with both feet option could be creating a 3D navigator for one of the maze generators.
<hcarty>
Stick the user at the start of the maze, give them a first-person view, and allow them to navigate through tile-by-tile.
<hcarty>
A much simpler but still interesting approach would be allowing the user to navigate using a 2D, overhead perspective.
<mrvn>
hcarty: 4 (doom), 5 (quake) or 6 (descent) degrees of freedom?
Tobu has quit [Ping timeout: 248 seconds]
<hcarty>
mrvn: 2 (early dungeon crawlers)
<mrvn>
hcarty: oehm, you can go forward or turn left?
<hcarty>
Or, no... four :-)
<hcarty>
Although forward + turn left should be sufficient
Tobu has joined #ocaml
<mrvn>
yeah, but if you have those the reverse is trivial.
<mrvn>
actualy 2 degrees would be just forward/backward on a line.
<hcarty>
forward/backward/turn left/turn right
<mrvn>
hmm, how many degrees does asteroids have? 3? left/right and accelerate?
oriba has joined #ocaml
<mrvn>
I should write an asteroids game. should be fun.
<hcarty>
mrvn: You could functorize the drawing code so it works with Graphics/Cairo/Gtk canvas without Cairo/js_of_ocaml + canvas
<hcarty>
Bonus points for writing it up in tutorial form :-)
<mrvn>
hcarty: Graphics is to slow. I would use sdl there.
<adrien>
graphics is faster than cairo actually
<adrien>
cairo is not fast
<hcarty>
adrien: No, sadly. It's often painfully slow.
<adrien>
cairo is even slower :-)
<hcarty>
adrien: Cairo is slower than Cairo? :-)
<adrien>
something pretty interesting is evas from the EFLs (enlightenment.org / e17) ; there are two people working on bindings and they should be almost done now (part of a master project)
<mrvn>
hcarty: sure, it reaches a fixpoint when it stops.
<adrien>
(there's stuff I don't agree with in the bindings however :-) )
<hcarty>
adrien: OCaml bindings? Cool.
<adrien>
the interface will be the same as Graphics' so having the code functorized could be interesting :-)
<hcarty>
adrien: What are they doing that you don't agree with?
<adrien>
hcarty: cairo slower than graphics ;p
<hcarty>
adrien: Ah - I was agreeing with you... but that wasn't entirely clear.
<adrien>
my biggest gripe (although it should be fine now) was that they were tighly coupling an object interface and the bindings code
<adrien>
makes it hard to code, and makes some things impossible
<adrien>
I quite heavily depend on lablgtk's non-object layer in some of my projects because the typing of objects sometimes just isn't not practical
<adrien>
I've been having real performance issues with cairo
<adrien>
creating a context takes 10 to 20ms on my laptop
<adrien>
and I haven't managed to reuse them between frames of my animation
<adrien>
or maybe but it was even slower
<adrien>
and the destruction of contexts also takes some time (maybe 5ms here)
Tobu has quit [Ping timeout: 248 seconds]
Tobu has joined #ocaml
Tobu has quit [Changing host]
Tobu has joined #ocaml
<adrien>
20ms minimum for each frame, it's going to be hard to get something very fast
<adrien>
but cairo is stupidest for drawing
<mrvn>
adrien: I'm aiming for 40ms but currently I'm at 200ms.
<adrien>
on screen
<adrien>
it's a vectir API for a raster display...
<adrien>
mrvn: with SDL?
<mrvn>
adrien: yes.
<adrien>
not bad if you start at 200fps; you should be able to get better than 40ms :-)
<hcarty>
adrien: Cairo works beautifully if (a) speed is not a concern; (b) you want to reuse the same code for vector and raster output (ex. screen, PNG, SVG)
<mrvn>
adrien: I'm at 5fps.
<hcarty>
adrien: You should be able to reuse a context as much as you want...
<adrien>
hcarty: but I had to clear everything between frames
<adrien>
and I'm not sure that was faster than destroying
<hcarty>
adrien: Ah. I havne't tested that.
<hcarty>
I don't know how efficient the clear operation is in Cairo for image or xlib surfaces.
<adrien>
but I haven't really enjoyed cairo's API for drawing "simple" stuff; I've found Graphics much nicer (for drawing lines for instance)
TDJACR has quit [Ping timeout: 250 seconds]
<hcarty>
A Graphics-compatible wrapper around Cairo would be nice
<hcarty>
It would be a bit of a challenge to get a 100% replication of Graphics, but something close should be possible.
TDJACR has joined #ocaml
<mrvn>
If it isn't 100% then it won't work for a functor.
<mrvn>
(modulo being a subset)
<hcarty>
mrvn: The interface shouldn't be too difficult to replicate, but getting the side effects correct could be challenging in some cases.
<hcarty>
mrvn: Things like reading the value at a pixel.
<mrvn>
I find reading/setting a pixel quite important and overly complicated in most toolkits.
<adrien>
archimedes has quite a lot of code for the drawing stuff
<adrien>
tbh, the task seems a bit dauting
<hcarty>
adrien: archimedes seems to be going in the other direction - wrapping Graphics so that it supports Cairo's primitives.
<adrien>
yup, it's how it does it but the surface and context management stuff makes the length of the code explode iirc
<mrvn>
might make more sense since Graphics is pretty much the lowest interface you can get
<adrien>
well, they're really just different kind of interfaces
emmanuelux has joined #ocaml
emmanuelux has quit [Read error: Connection reset by peer]
iago has quit [Ping timeout: 240 seconds]
emmanuelux has joined #ocaml
Nahra has joined #ocaml
Nahra has quit [Changing host]
Nahra has joined #ocaml
avsm1 has joined #ocaml
avsm1 has quit [Client Quit]
Se7en1 has quit [Read error: Connection reset by peer]
avsm has quit [Ping timeout: 245 seconds]
ftrvxmtrx has joined #ocaml
msimoni has joined #ocaml
err404 has joined #ocaml
eni has quit [Ping timeout: 245 seconds]
Tobu has quit [Quit: No Ping reply in 180 seconds.]
Tobu has joined #ocaml
snearch has quit [Quit: Verlassend]
<mrvn>
What's another word for "raise"? As in the Turtle.raise : unit -> unit (* turtle raises its tail *)
<adrien>
stop_writing?
<mrvn>
lift
<adrien>
building a gcc, that reminds me of something from yesterday
<adrien>
with autotools, you're not supposed to do "./configure", i.e. you're not supposed to configure and build directly in the sources
<adrien>
so you should "../gcc-foo/configure --enable-whatever && make"; solves the "make clean" issue
<mrvn>
adrien: "supposed to"? Nah. building in tree is normal. out-of-tree builds don't always work but they indeed are neat.
<rly>
adrien: where does it say that? I am pretty sure the manual doesn't say that.
<rly>
adrien: the manual says one _can_ do that.
<adrien>
out-of-tree is actually the normal way but in-tree works almost all the time
cdidd has quit [Ping timeout: 265 seconds]
bjorkintosh has joined #ocaml
<adrien>
but obviously none will work 100% of the time; we're talking about computers and build systems here =)
<rly>
I settle for theoretically 100% if we ignore physics.
<mrvn>
adrien: unpack, ./configure, make is the standard way. out of tree builds are the new thing
<adrien>
new? gcc has never supported in-tree builds, or at least not for a decade
<rly>
adrien: interesting that you mention that... considering that it does work.
<rly>
adrien: and sure, they might not 'support' it.
<rly>
adrien: then again, they also don't even promise it is a C compiler.
<rly>
adrien: perhaps some company might want to put a stamp on it and say it is a C compiler to you.