<exarkun>
S3: Are you sure your compiler is installed correctly? :)
<TimFreeman>
S3: Where is closedir? exarkun: He's reporting different errors on different runs, I think.
<S3>
well, pretty sure, ye
<TimFreeman>
Found closedir in otherlibs/unix. Same gcc command that failed for S3 works for me.
<TimFreeman>
Try just that gcc invocation, in just that directory again. Does it fail again?
<TimFreeman>
Which Linux kernel? I remember bad buffering for a CD once in an old Linux kernel.
<TimFreeman>
Ran out of memory even when there was plenty.
<TimFreeman>
Might be your situation, if the kernel's old enough.
<TimFreeman>
cat /proc/version.
<S3>
2.2.20
<S3>
what gcc invocation?
<TimFreeman>
Hmm. I'm running 2.4.17 and I recall being forced to upgrade due to bugs, but I don't recall which bugs and I don't know if they were prcesnt in 2.2.20.
<TimFreeman>
Can you run "top" in another window while you're attempting your compile? It might
<TimFreeman>
be interesting watching to see if the available memory drops to zero during the run.
<S3>
i'll redo make world
<TimFreeman>
Maybe you should take a trip to a hardware store and buy more memory? It's pretty cheap lately. Maybe a good idea regardless of the resolution of this particular problem.
<S3>
as a ventilator is blowing on the box, maybe a hardware problem
<S3>
that box has edoram...
<S3>
it's a pice of history man ;)
<TimFreeman>
History bites. I hear wal-mart sells $300 PC's.
<TimFreeman>
Well, I'll stop griping about your hardware. Watching it with "top" might be worthwhile.
<S3>
not in switzerland....
<TimFreeman>
("it" being the compilation).
<S3>
hold on
<TimFreeman>
Hey, if it can compile a few files, then fail, then next time around it compiles a few files and then fails,
<TimFreeman>
then you could just say "make world" over and over again until it passes. Might work.
<S3>
yeah
<S3>
but's not just ocaml...
<S3>
apache 1.3 just did a similar thing
<TimFreeman>
I guess your kernel isn't functioning as well as you'd like with your present small amount of physical memory. Let's check again that the virtual memory is configured right. Say "free". The amount of swap free should be ...
<TimFreeman>
over 100000.
<TimFreeman>
If the swap is configured right, and you can't get new memory, I'd try a new kernel.
<S3>
it's 160'000 actually
<TimFreeman>
How much physical memory free?
<S3>
about 1mb
<TimFreeman>
Running X windows?
<TimFreeman>
Might want to try your compile running as little other stuff as possible.
<TimFreeman>
X windows is relatively heavy, and you can get along without it for the duration of your comple.
<S3>
no x window here
<TimFreeman>
Don't see a good solution here. The C compiler is failing intermittently. Has to be a kernel bug, IMO, since the C compiler is failing in different places on different runs without some intelligent error like "out of ...
<TimFreeman>
memory". New memory or new kernel are still the only options I see.
<gjgj>
make world under freebsd?
<TimFreeman>
gjgj: Ya, different OS is a reasonable way to accomplish a different kernel.
<gjgj>
TimFreeman, was just gonna say that make world clears out /usr/obj each time
<gjgj>
So you'd be starting from scratch with each iteration.. what version are you running?
<TimFreeman>
gjgj: The second time I run make world it's almost instantaneous. Did it just now. What did you mean by "/usr/obj"?
<TimFreeman>
My build account doesn't have access to any /usr/obj and make world has no problems.
<gjgj>
/usr/obj is where it puts its object files
<TimFreeman>
There is no /usr/obj on my machine, make world works fine, I've used the resulting interpreter. Can you point
<gjgj>
Oh.. maybe it falls back to something else then (like storing the objs in /usr/src0
<TimFreeman>
at the lines from the makefile?
<TimFreeman>
lobus:~/ocaml-anon-cvs/ocaml> ls /usr/src0
<gjgj>
we might be talking about 2 different things :)
<TimFreeman>
ls: /usr/src0: No such file or directory
<gjgj>
yea.. that 0 was supposed to be a )
<gjgj>
;-)
<gjgj>
I'm talking about a make world from /usr/src
<gjgj>
but maybe ocaml has a build target called 'world' that you're talking about (i'm very new to ocaml, just starting to learn a bit of it :))
<TimFreeman>
gjgj: Can't figure out what you're talking about yet. I've configured my ocaml built from cvs to be in ~/ocaml-anon-cvs/ocaml, and the build doesn't touch any files outside of there, and "make world" is really incremental ...
<TimFreeman>
unless I fetch new stuff from cvs. I'm talking about ocaml's make world, perhaps you're talking about "make world" in some freebsd ports package?
<gjgj>
ah okay
<gjgj>
I didnt know ocaml had a world target :).. when I hear 'make world' I think of freebsd's source-based upgrade procedure
<TimFreeman>
So S3's still stuck. The ideas on the table are more memory, new Linux kernel, or migrate to freebsd. I know nothing about the latter. Any other ideas?
<TimFreeman>
There are memory test programs that can be run. However, I would expect bad memory to crash the OS frequently, instead of just crashing the C compiler.
<gjgj>
what error are you getting from the compiler?
<gjgj>
Internal Error
<gjgj>
?
<TimFreeman>
Not sure if S3 is still listening. gcc gives different errors at different times while trying to compile C code that comes with the ocaml sources.
<gjgj>
do you have an example of one of the errors? :)
<gjgj>
usually when it's memory related or something uncontrollable by gcc you get an internal compiler error
<TimFreeman>
S3's problem, not mine. Probably caused by a combination of Linux kernel bugs aggravated by only having 16mb of physical memory.
<TimFreeman>
He never quite said he was running linux. He did mention that the machine name is "debian", so if it's not running linux, he's pretty perverted.
<TimFreeman>
Ya. whacky.
<TimFreeman>
I guess we'd have to call it a gcc compiler bug too, if it gives bizarre answers instead of a clean failure when run in an uncomfortable environment.
<TimFreeman>
S3: Hey, maybe your disk is full! Gcc saves intermediate files during compilation.
<TimFreeman>
S3: You aren't idle, but you aren't talking to us. That's okay. Good luck to ya.
two-face has joined #ocaml
Kostya has left #ocaml []
Yurik has joined #ocaml
<Yurik>
re
<Yurik>
evening
<TimFreeman>
Hi.
<two-face>
Yo
<two-face>
you are the namespace man , aren't you?
<Yurik>
yes, it's i an
<Yurik>
s/an/am
<two-face>
nothing from the ocaml team?
<Yurik>
nothing :(
<Yurik>
seems that they aren't interested at all :(
<TimFreeman>
I didn't get a response to my proposed Streams revision either. They classified it as a "feature request" even though I sent them code that they could have just taken.
<Yurik>
however, i'm trying to implement it by myself, since i need this
<two-face>
Yurik: you could file a wishlist bug in the bug tracker
<Yurik>
two-face: i know about it. i think i'll fill request soon
<two-face>
good
<two-face>
TimFreeman: the best way to get a new feature included is to provide a patch
<Yurik>
however, as per caml-list archives, they idea of namespaces was proposed more then 1 time, and no success
<two-face>
show them the code :)
<TimFreeman>
I provided them an entire new streams.ml.
<Yurik>
two-face: it is not very easy for me to make a patch, since i'm not an ocaml core hacker :)
<two-face>
Yurik: work hard :)
<Yurik>
two-face :)
<two-face>
we don't know their priorities
gl has quit [No route to host]
<TimFreeman>
Ya. I'm hoping that after they come out with 3.06 they'll pay some attention to my proposal.
<TimFreeman>
Yurik: Thanks. Looked at their website now. Have you tried it?
<Yurik>
yep, but only a bit
<Yurik>
seems that it works
<Yurik>
but
<Yurik>
i've faced w/ problems while generating code for ocaml
<TimFreeman>
I don't get the deal with namespaces. Won't ocamlc -pack let you accomplish much the same thing?
<two-face>
I'm doing this manually :)
<Yurik>
it had an error in generated C source. however, it was fixed in minute by changing the order of two lines in template
<Yurik>
TimFreeman: nope
<Yurik>
TimFreeman: namespaces can intersect
<TimFreeman>
Yurik: Do you mean union?
<Yurik>
TimFreeman: well, as for me, I name it "glueing" :) in fact, identically named namespaces unions in one
<TimFreeman>
I see. With ocamlc -pack and without namespaces, you can't merge two identically named namespaces.
<Yurik>
yeah
<Yurik>
namespaces are the way to allow this
<Yurik>
it will be very suitable for large projects
<TimFreeman>
Is there an ocamlc -unpack? With ocamlc -pack and ocamlc -unpack you could glue together two modules provided that they consist only of submodules.
<TimFreeman>
...and you're willing to implement the glueing with shell scripts.
<Yurik>
umm. i mean namespaces union as module with the same name but "include Ns1Impl ;; include Ns2Impl"
<Yurik>
shell scripts sucks for this. very heavy
<TimFreeman>
Yurik: Agreed.
malc has joined #ocaml
<two-face>
hi malc
<malc>
lo two-face
* Yurik
is eating ears
<Yurik>
malc hi
<TimFreeman>
Yurik: your own ears? How do you do that?
<malc>
lo Yurik
<malc>
hes an acrobat
<Yurik>
TimFreeman: not own
<two-face>
Do you know that people eat pig ears?
<TimFreeman>
Sounds like a difficult wrestling match. Doesn't the pig's extra weight give you a disadvantage?
<TimFreeman>
Sorry, I'll stop the bizarre Q&A right now.
<malc>
yeah, lets return the channel to its normal near entropy state
* Yurik
finished eating pig ears
<Yurik>
:)
<two-face>
pig ears makes you fat
<Yurik>
really?
<malc>
beans make you fart
<malc>
big deal
<two-face>
beans are vegetables
<Yurik>
food makes fat
<Yurik>
especially when you eat a lot of food
<two-face>
no, it depends
<two-face>
vegetables dont make you fat, fried vegetables make you fat
* Yurik
likes meat a lot :)
<two-face>
meat is the worst :)
<TimFreeman>
Um, if this is what we're going to talk about we might as well get back to pig-wrestling. How can you type at IRC while your gnawing on it's ear?
Yurik- has joined #ocaml
Yurik has quit [Read error: 104 (Connection reset by peer)]
<Yurik->
re
Yurik- is now known as Yurik
* Yurik
is playing w/ Ensemble
<TimFreeman>
And what is Ensemble?
<Yurik>
look at humps - group communication toolkit implemented in Ocaml
<malc>
heh thats funny
<malc>
Take the current (3rd) quarter results of SPECfp2000 on http://www.spec.org:
<malc>
HP server rx2600 (1000 Mhz Itanium 2, 3.0 Mb on-chip L3 cache:
<malc>
apsi
<malc>
235 (base) 205 (peak)
<malc>
HP server zx6000 (1000 Mhz Itanium 2, 3.0 Mb on-chip L3 cache:
<malc>
apsi
<malc>
678 (base) --- (peak)
<malc>
The first one uses the HP/UX Fortran compiler, the second one the Intel
<malc>
Fortran compiler.
<two-face>
which means ?
<malc>
one of them was 3x fast?
<two-face>
ah, sorry
<two-face>
anyway, i've always thought that IA64 is a bad idae
<malc>
its a bad idea for OCaml thats for sure
<two-face>
because of optimisation ?
<malc>
because its hard to write an optimizing compiler for this arch, yes
<two-face>
that sux
Yurik has quit [Read error: 104 (Connection reset by peer)]
<two-face>
they ported ocaml on ia64 iirc
<malc>
yep
<malc>
fairly long time ago
<two-face>
i think they have access to ia64 machine though