malc has quit [Read error: 104 (Connection reset by peer)]
malc has joined #ocaml
gene9 has quit ["Client Exiting"]
gene9 has joined #ocaml
malc has quit [carter.openprojects.net irc.openprojects.net]
malc has joined #ocaml
malc has quit ["no reason"]
gene9 has quit ["b"]
samx has quit [Read error: 110 (Connection timed out)]
TimFreeman has joined #ocaml
TimFreeman has left #ocaml []
TimFreeman has joined #ocaml
TimFreeman has left #ocaml []
TimFreeman has joined #ocaml
<TimFreeman>
Hi. Anyone awake?
<TimFreeman>
If I have an ocaml program that prints "hello world", the executable for i386 is <100K. A simple lablgtk application that displays an editable window gives me an executable of >800K. Does anyone know why the huge increase ...
<TimFreeman>
in size, or how to debug the huge increase in size? Note that the gtk library itself is a .so file, so it doesn't contribute to the size.
<TimFreeman>
Hmm. Nobody is really awake. Goodnight, all.
TimFreeman has left #ocaml []
jemfinch has joined #ocaml
jemfinch has quit []
tav has quit [Read error: 110 (Connection timed out)]
two-face has joined #ocaml
two-face has left #ocaml []
koyuki has quit [Read error: 110 (Connection timed out)]
jao has quit [Read error: 113 (No route to host)]
Dimka has joined #ocaml
two-face has joined #ocaml
two-face has left #ocaml []
Taaus has quit [Remote closed the connection]
Dimka has quit [Read error: 110 (Connection timed out)]
Dimka has joined #ocaml
two-face has joined #ocaml
TimFreeman has joined #ocaml
<TimFreeman>
I see there are dll files for the installed ocaml libraries. For example, I was given a /usr/lib/ocaml/lablgtk/dlllablgtk.so when I installed lablgtk. I presume this would let me use lablgtk as a shared library. Does ...
<TimFreeman>
anyone know the arguments to ocamlopt for that?
<two-face>
hmm
<TimFreeman>
Aha! Someone here is awake! Usually everyone is away from their computer.
<TimFreeman>
two-face: Hi.
<two-face>
hi
<two-face>
the -cclib ?
<TimFreeman>
Tried ocamlopt.opt -I +lablgtk -cclib -Llablgtk lablgtk.cmxa gtkInit.cmx whyterm.ml -o whyterm; the new executable isn't any smaller. Trying other permutations.
<two-face>
i don't understand the error message
<TimFreeman>
There was no error. Judging by the size of the executable, it grabbed the static library instead of grabbing the .so.
<two-face>
probably
<smkl>
anyway, ocaml cannot produce pic, so it is linked statically. only the stubs can be shared
<TimFreeman>
Progress. ocamlopt.opt -noautolink -I +lablgtk -cclib /usr/lib/ocaml/lablgtk/dlllablgtk.so lablgtk.cmxa gtkInit.cmx whyterm.ml -o whyterm gives me a slightly smaller working library that does depend on the dll.
<TimFreeman>
What are the stubs?
<smkl>
the c files
<TimFreeman>
Aha.
<two-face>
hi smkl
<smkl>
hello
<TimFreeman>
Right, the .so file is too small to be the whole thing.
<two-face>
smkl: do you follow the caml mailing list ?
<TimFreeman>
Hmm. Bummer that ocaml can't generate PIC. It seems that the way thing are structured, when something is statically linked in, you get most of the library.
<smkl>
two-face: yes
<smkl>
TimFreeman: i think malc has been working on that but it only works for i386
<two-face>
smkl: have you heard of dynamic loading of ocaml native code ?
<TimFreeman>
Well, I'm running on an i386. Is there something I should attempt to use?
<scipient>
does anyone know if there's any work being done on OCaml stream abstractions? if i understand correctly, the problem with in_channel and out_channel is you can't implement them yourself
<two-face>
smkl: thx, still not integrated in the mainstream ?
<smkl>
i don't think so
<two-face>
ah
<TimFreeman>
The changelog is pretty long.
<TimFreeman>
Thanks for the pointer. The previous link I pointed to said that the generated PIC code was twice as big and slow. Any hints on whether this more recent pointer degrades performance?
<two-face>
no
<two-face>
but the patch seems to do it well, no?
<TimFreeman>
Do you know if the ocaml people are contemplating taking the patch?
<two-face>
i don't know
<two-face>
maybe we could ask them
<TimFreeman>
I suppose I should get on the mailing list.
<two-face>
sure
<two-face>
smkl: one maore question, has anyone cared for library reduction in ocaml?
<smkl>
library reduction?
<two-face>
yes
<two-face>
currently, using a library mean including the whole code
<two-face>
even the one you don't use
<smkl>
oh, i don't think so
<two-face>
ah, well, i'm sure it will be implemented some day
<two-face>
it's just low priority , i thinnk
<scipient>
am i correct that there's no way to implement your own in_channel or out_channel from pure OCaml code?
<two-face>
i don't know
<smkl>
scipient: i guess so
<scipient>
das ist ein problem! ;p
<two-face>
warum ?
<scipient>
i need a way to pass very large pieces of data around, that may come from a file, or a socket, or what have you, without reading the whole thing into memory
<scipient>
so passing around an in_channel would be ideal
<scipient>
but, it might have to come from a string or something instead of a file/socket
<two-face>
maybe in C
<scipient>
i don't know if anyone is familiar with the way Java handles I/O streams, but that is basically what i'm looking for
<smkl>
in_channel and out_channel are just for easy interfacing from C... try using streams or your own abstraction
<two-face>
BBL
two-face has left #ocaml []
<scipient>
streams?
<scipient>
that's what i'm asking, is there such a thing for OCaml?
<smkl>
module Stream in standard library. they are perhaps bit different from streams in java or c++, but they should be good for inputting data
<TimFreeman>
two-face: I don't think it really includes the whole library. It just seems to include most of it in practice.
<TimFreeman>
two-face: For instance, if you make an object, includes oo.o; if you include oo.o, you get digest.o for md5 digests because oo.o includes a function you probably didn't call that wants a random number. That sort of thing.
<scipient>
smkl: the Stream module is totally the wrong thing
<scipient>
i can make my own abstraction, but i think it'd be nice if it could become a standard
<smkl>
then what do you need?
<scipient>
you can have abstract classes / interfaces in OCaml, i hope?
tav has joined #ocaml
<scipient>
i'm very new to this
<scipient>
i want an abstract class that defines some methods for reading bytes, and another that defines some methods for writing bytes
<scipient>
so you can subclass it any way you want to implement those methods
<smkl>
sure ... people just don't usually use oo features in ocaml
<TimFreeman>
scipient: Stream.from makes a stream from a function. Is that sufficient?
<scipient>
no :)
<scipient>
i want both input and output abstractions
<scipient>
and i don't want any of this parser and look-ahead stuff
<scipient>
basically just: read X bytes, and close
<scipient>
or write X bytes, flush, and close
<TimFreeman>
You're right, what you want doesn't seem to be there.
<smkl>
well, that is trivial with objects
<scipient>
so i guess i'll make my own interfaces and try to add them to the hump
Dimka has quit [Read error: 110 (Connection timed out)]
<smkl>
TimFreeman wanted to know about your patch
<malc>
yes? lets check the logs
<TimFreeman>
Oh. Right. I find that ocamlopt tends to produce huge executables, and I was hoping to use shared libraries to make them smaller. Specifically, I'd like to avoid distributing many copies of lablgtk when I distribute my ...
<TimFreeman>
binaries.
<malc>
precisely the reason why i made scaml
<malc>
sigh
<TimFreeman>
Position-independent-code and real shared libraries might solve the problem. Another option seems to be alluded to at http://caml.inria.fr/archives/200112/msg00010.html; it seems that the dynamic linker is often willing to ...
<TimFreeman>
statically link in something at run time. Have you seen that work?
<TimFreeman>
...work with ocaml, that is?
<TimFreeman>
How does the speed of code generated for shared libraries with scaml compare with statically linked code?
<malc>
there is no difference, i havent touched codegen(all that much)
<malc>
and i dont make PIC code so there should be no difference at all, unless ld.so does very wacky things
<TimFreeman>
So it generates .so's that will get statically linked in at run time, right? That's sufficient for my purposes.
<malc>
..that will get dynamically linked in at run time..
<TimFreeman>
Right. I mean, the link editor has to touch all the bits to relocate them, right?
<malc>
yep
<TimFreeman>
Any idea whether the ocaml people want to take your patch for some future release?
<malc>
judging by my mail exchange with Xavier this is highly unlikely
<TimFreeman>
Hmm. Was it clear what his objection was?
<TimFreeman>
malc: The link to "OCaml 3.04" on http://algol.prosalg.no/~malc/scaml/ is broken, by the way. It was a relative URL and you didn't want it to be.
<malc>
TimFreeman: thanks i will correct it
Dark has left #ocaml []
<TimFreeman>
malc: I'm poking at the ocaml mailing list to try to get a better explanation of the status quo about scaml.
<malc>
TimFreeman: there was no scaml discussion on the list, 3 or so reactions on my announcements and thats it
<malc>
i had private exchange with Xavier though
<TimFreeman>
Alright, I omit your quote of Xavier's email, and I won't presuppose that it has been discussed on the list before.