smkl changed the topic of #ocaml to: check logs from http://bespin.org/~nef/logs/ocaml/
graydon has quit []
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
<TimFreeman> two-face: Found something at http://caml.inria.fr/archives/200011/msg00180.html. They say they can generate PIC with ocaml, but for an old version of ocaml and it's slow.
<two-face> thx
<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
<scipient> just want to avoid duplicating effort
<smkl> http://sourceforge.net/projects/ocamlnet seems to have that kind of interfaces
malc has joined #ocaml
<smkl> hello malc
<malc> lo smkl
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?
<malc> lets see if i can dig the exact quote
<malc> btw. if you will use scaml apply following
<malc> --- cmmgen.ml Fri Jan 11 03:05:36 2002
<malc> +++ /mnt/mdk/home/malc/scaml/diff/field/ocaml-3.04/asmcomp/cmmgen.ml
<malc> Fri Jan 11 03:54:34 2002
<malc> @@ -822,7 +822,7 @@
<malc> (Pgetglobal id, []) ->
<malc> let name = Ident.name id in
<malc> if
<malc> - name = Compilenv.current_unit_name() ||
<malc> + (*name = Compilenv.current_unit_name() ||*)
<malc> not (Ident.persistent id)
<malc> then
<malc> Cconst_symbol name
<malc> here goes
<malc> > I think dynamic linking is needed(what a surprise, eh?). For one thing it
<malc> > will eliminate disparity between byte/nativecode compilers (Dynlink), plus
<malc> > speedy native Camlp4 without constant recompilation to accomodate pa_ifdef
<malc> > or whatnot is good. On the other hand i understand the futility of any
<malc> > attempts to convince anyone in this, sigh.
<malc> And I understand the futility of any attempts to convince you that
<malc> dynamic linking is fundamentally evil :-)
<TimFreeman> I take it the >'s are you and the non->'s are Xavier. Looks like he didn't attempt to explain himself.
<malc> indeed
<TimFreeman> Hmm. Maybe we can do an end-run around him by having a separate scaml debian package.
<TimFreeman> What's pa_ifdef?
<malc> hardly. scaml is binary incompatible with vanilla ocaml
<malc> camlp4 addon for CPP like define ifdef ifndef
<scipient> what's scaml?
<scipient> thanks. interesting
<TimFreeman> So the idea with dynamic linking and camlp4 is to link in the interpreter to do the ifdef's?
<malc> TimFreeman: scaml's only chance of survival was inclusion into CDK, but CDK looks pretty much dead itself
<malc> sortof
owll has joined #ocaml
Cryptor has joined #ocaml
Cryptor has quit ["Leaving"]
<TimFreeman> Are there other plausible patches that aren't making into ocaml for unclear reasons?
<TimFreeman> (other than scaml, that is.)
Dark has joined #ocaml
Dimka has joined #ocaml
Dimka has left #ocaml []
<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.
<malc> Ok
<malc> omit from where btw?
<TimFreeman> omit from the email I'm composing.
<TimFreeman> Not that it was ever present...
<malc> right
<owll> wow.
<owll> scaml looks as great thing...
<owll> malc: 10X!
<malc> owll: uh, heh, no problem ;)
<malc> tata
malc has quit ["no reason"]