two-face changed the topic of #ocaml to: OCaml 3.05 released: http://caml.inria.fr/ocaml/distrib.html (expect 3.06 soon: week 34) | http://www.ocaml.org/ | http://caml.inria.fr/oreilly-book/ | http://icfp2002.cs.brown.edu/
gl has quit [Read error: 113 (No route to host)]
pnou has quit [Read error: 104 (Connection reset by peer)]
chameau has quit [Read error: 104 (Connection reset by peer)]
pnou_ has joined #ocaml
Kostya has joined #ocaml
Kostya has quit [Remote closed the connection]
clog has quit [^C]
clog has joined #ocaml
pnou_ has joined #ocaml
samx has joined #ocaml
kjs3 has joined #ocaml
gl has joined #ocaml
kruskal has joined #ocaml
kruskal has left #ocaml []
karryall has joined #ocaml
Yurik has joined #ocaml
<Yurik> re
kruskal has joined #ocaml
Yurik has quit [Read error: 110 (Connection timed out)]
gl is now known as gl-limsi
gl has joined #ocaml
gl has quit [Remote closed the connection]
gl has joined #ocaml
gl-limsi has quit [Killed (NickServ (Ghost: gl!~gl@eno.limsi.fr))]
gl is now known as gl-limsi
kruskal has quit ["Fermeture du client"]
kruskal has joined #ocaml
gl-limsi has quit ["O'Caml: the programming tool of choice for discriminating hackers"]
malc has joined #ocaml
foo has joined #ocaml
malc has quit ["no reason"]
mr_bubbs has joined #ocaml
karryall has quit ["bye .."]
Dalroth has joined #ocaml
foo is now known as gl
gl has quit ["La foule est une somme d'erreurs qu'il faut corriger."]
gl has joined #ocaml
Kostya has joined #ocaml
kruskal has left #ocaml []
TimFreeman has joined #ocaml
Dalroth has quit [Connection reset by peer]
S3 has joined #ocaml
<S3> has somebody an idea why i get the following error doing a make world opt opt.opt
<S3> In file included from /usr/include/string.h:360,
<S3> from custom.c:16:
<S3> /usr/include/bits/string2.h: In function `__strtok_r_1c':
<S3> /usr/include/bits/string2.h:1088: `NULL' undeclared (first use in this function)
<S3> /usr/include/bits/string2.h:1088: (Each undeclared identifier is reported only once
<S3> /usr/include/bits/string2.h:1088: for each function it appears in.)
<S3> make[1]: *** [custom.o] Error 1
<S3> make[1]: Leaving directory `/home/greg/src/ocaml-3.05/byterun'
<S3> make: *** [coldstart] Error 2
<TimFreeman> Well, string.h is the first file included by custom.c, so a good start would be to make a standalone
<TimFreeman> piece of code that just includes string.h and reproduces the error. There's probably something wrong
<TimFreeman> with your compiler options or environment somewhere. You didn't say what
<TimFreeman> the compiler options were (I mean the C compiler here). If you make the standalone test program
<TimFreeman> that reproduces the problem, you can isolate the problem from the ocaml make files and other
<TimFreeman> ocaml source.
<S3> hmmm, it's more like a compiler error then, right?
<TimFreeman> Ya, it's an error reported by your C compiler. That's gcc, right?
<S3> yea
<TimFreeman> Give me a few more lines of your "make" output that preceed the error. The gcc options are probably important.
<S3> arghl, my ram is over then... it's an old pc
<S3> hold on
<TimFreeman> doesn't make sense to run out of ram at the first #include.
<S3> 16mb
<TimFreeman> How much VM?
<S3> i did another make world opt opt.opt
<S3> swap is 150 if you mean that
gl has quit [Read error: 113 (No route to host)]
<TimFreeman> 150 MB of swap should be fine. (You do mean 150MB, not 150KB or something?)
<S3> here is the error fom this run
<S3> 150 megabyte, yes
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o addrofstr.o addrofstr.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o alarm.o alarm.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o bind.o bind.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o chdir.o chdir.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o chmod.o chmod.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o chown.o chown.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o chroot.o chroot.c
<TimFreeman> I don't have that much and I can recompile ocaml fine, shouldn't be the problem.
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o close.o close.c
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o closedir.o closedir.c
<S3> In file included from closedir.c:20:
<S3> /usr/include/dirent.h:171: parse error before `__ASMNAME'
<S3> make[1]: *** [closedir.o] Error 1
<S3> make[1]: Leaving directory `/home/greg/src/ocaml-3.05/otherlibs/unix'
<S3> make: *** [otherlibraries] Error 2
<S3> greg@debian:~/src/ocaml-3.05$
gl has joined #ocaml
<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> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o closedir.o closedir.c
<TimFreeman> But cd to otherlibs/unix f8irst.l
<S3> Linux version 2.2.20-idepci (herbert@gondolin) (gcc version 2.7.2.3) #1 Sat Apr 20 12:45:19 EST 2002
<TimFreeman> gcc --version
<TimFreeman> I get 2.95.4 for the gcc version.
<exarkun> The VM problems were in 2.4.0 through 2.4.13ish, so it's probably not that
<S3> 2.95.4
gjgj has joined #ocaml
<TimFreeman> s/b good enough.
<S3> gcc -I../../byterun -O -fno-defer-pop -Wall -Wno-unused -D_FILE_OFFSET_BITS=64 -fPIC -c -o closedir.o closedir.c
<S3> no errors
<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.
<gjgj> ah okay
<TimFreeman> Ocaml chat room logs are at http://bespin.org/~nef/logs/ocaml/02.08.19. Don't want to do a massive paste.
<gjgj> wow.. whacky
<gjgj> a parse errors.. and it's not recurring?
<gjgj> s/errors/error
<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.
<two-face> maybe, yes
two-face changed the topic of #ocaml to: OCaml 3.05 released: http://caml.inria.fr/ocaml/distrib.html (expect 3.06 soon: week 34) | http://www.ocaml.org/ | http://caml.inria.fr/oreilly-book/ | http://icfp2002.cs.brown.edu/ | SWIG now supports OCaml
<Yurik> hm. may be. hope dies last :)
<TimFreeman> SWIG is?
<Yurik> TimFreeman: swig.org
<Yurik> afair
<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
<malc> nope.. Xavier used SF's compile farm
<two-face> ah ? is it a problem ?
<malc> not having access to machine?
<two-face> how the compile farm work?
<malc> no idea.. go to sf.net and read the docs..
<malc> me im heading to bed. ciao
malc has quit ["no reason"]
<two-face> be
<two-face> by
two-face has left #ocaml []
TimFreeman has left #ocaml []
Yurik has joined #ocaml
<Yurik> re
Yurik has left #ocaml []
S3 has left #ocaml []