Herrchen_ has quit [Read error: 110 (Connection timed out)]
<ffdd>
I have a C extension that needs to read the string out of an exception that's of string
joo_ has quit [brown.freenode.net irc.freenode.net]
<ffdd>
I can get an int with Extract_exception(), what about for a string?
joo_ has joined #ocaml
<mfurr>
Isn't that int a pointer to a block containing the exception value?
pattern_ has quit ["..."]
dan2_ has joined #ocaml
<ulfdoz_>
re
mfurr is now known as mfurr_sleep
dan2 has joined #ocaml
dan2_ has quit [Connection timed out]
beta3 has joined #ocaml
dan2 has quit [Read error: 110 (Connection timed out)]
dan2_ has joined #ocaml
_shawn has joined #ocaml
beta3 has quit [Connection timed out]
dan2_ is now known as JBoss
JBoss is now known as dan2
dan2 has quit [Read error: 60 (Operation timed out)]
shawn_ has quit [Client Quit]
Submarine has joined #ocaml
petchema_ has joined #ocaml
pango has quit [Read error: 60 (Operation timed out)]
Tipsy has joined #ocaml
Tipsy has left #ocaml []
dan2_ has joined #ocaml
Mike_L has joined #ocaml
* Mike_L
looks around
mlh has quit [Client Quit]
Snark has joined #ocaml
<Mike_L>
hello, I am interested in learning caml
<Mike_L>
I recently learned Erlang and like it a lot
<Mike_L>
then I started learning Tcl but found that I dislike it
Nutssh has joined #ocaml
Nutssh has quit [Read error: 104 (Connection reset by peer)]
dan2_ has quit [Connection timed out]
dan2_ has joined #ocaml
<Snark>
Mike_L: ocaml is a nice language
<Mike_L>
how is it for making GUI programs?
<Mike_L>
I want to make a GUI chat client that will run on Windows, unix, and Mac
smimou has joined #ocaml
xav has joined #ocaml
<xav>
hi
<Mike_L>
hello
petchema_ is now known as pango
dan2_ has quit [Connection timed out]
dan2_ has joined #ocaml
<Mike_L>
I see ocaml supports Tk
smimram has joined #ocaml
<mflux_>
I like the lablgtk2-library, but I wonder what is its status in Windows world
<Mike_L>
is it easy to package a precompiled application and all of its required libraries?
<Mike_L>
how about opengl?
<mflux_>
I haven't used opengl with ocaml, but the bindings are there
<mflux_>
I guess your packaging problem is solved either by linux distributions or by software such as InstallShield
<Mike_L>
so I won't need to distribute the ocaml compiler and whole distribution with my program?
<xav>
lol
<Mike_L>
can I make an EXE or an ELF executable?
<Mike_L>
it is a funny question, but I was surprised to find that smlnj does not produce EXE or ELFs
<Snark>
ocaml can produce either bytecode or native executables
<Mike_L>
excellent!
<Mike_L>
maybe I will try ocaml/tk for this application
<Mike_L>
Tk has great localization support, supporting Japanese and Chinese text input and display
<xav>
I don't know why, but just seeing the exe extension gives me nightmares.
<Snark>
xav: there's worse to it: with mono you even see it on civilized systems...
<Mike_L>
xav: you could write an EXE handler for the Linux kernel and then compile your whole linux system into EXE binaries and it would work just like your current ELF system
<Mike_L>
you would need something to replace ld, though
<Mike_L>
personally, I dislike ld very much, and the whole concept of shared libraries
<xav>
Mike_L: hmm didn't know that :)
<xav>
Snark: right
<xav>
Mike_L: why?
<Mike_L>
xav: there is a Java handler in the linux kernel so you can run Java bytecode programs natively
<Snark>
exe handlers exist, to use wine to launch an exe, if I remember well
<Mike_L>
ld is incomplete
<Mike_L>
ld provides libraries to applications, but there is no accounting
<mflux_>
I believe the only thing in kernel nowadays is the capability to add magic bytes that the kernel will recognize and run with the provided binary
<Mike_L>
so when you upgrade a library, there is no way to know which applications will be affected and which will break
smimou has quit [Read error: 110 (Connection timed out)]
<Mike_L>
and library developers are not disciplined to follow their numbering methods (ie, same major version numbers should all be compatible)
Submarine has quit [No route to host]
<Mike_L>
we don't yet have the technology to make sure that an upgraded version of a library will be compatible with an application that was designed to use the older version of the library
<pango>
isn't that undecidable
<Mike_L>
there are really two uses for shared libraries: saving disk space and memory, and providing a central location to upgrade functionality that exists in many programs
<Mike_L>
the first use is obsolete.
* Snark
isn't sure to agree
<xav>
same
<pango>
saving memory too
<Mike_L>
modern machines have enough RAM and disk space to store a copy of each library for each application installation
<xav>
not everyone use modern machines
<Snark>
Mike_L: try to load xlib for each x app running...
<Mike_L>
and the second use (centralized upgrades) are so problematic
<pango>
(oups, noticed you said it already)
<Snark>
gtk for each gtk app
<Mike_L>
how big is GTK in RAM?
<Mike_L>
it is very big simply because it is a shared library
<Mike_L>
a statically linked library could save a lot of unused code
<Mike_L>
anyway the current tools are designed for people that use shared libraries, and the current libraries are designed to be shared, not statically compiled in
<Snark>
uh... as far as I know the autotools allow building statics
<Mike_L>
so I guess my problem with ld is a problem with the whole shared library system
<xav>
when you upgrade a library, you just need to recompile the apps that depend on it, right? it'll work most of the times?
<Mike_L>
xav: if it were automated then I would have no problem with the idea, other than the problem of incompatibilities
<Snark>
sometimes recompiling isn't even necessary
<Mike_L>
sometimes
<xav>
Mike_L: I think it's on source distrib
<Mike_L>
I imagine the world's computing infrastructure will move away from shared libraries in the next 10-20 years
<Mike_L>
shared libs are a nightmare under Windows
* xav
doesn't really care
<xav>
but maybe I should
<Mike_L>
lol even though the world's businesses and organizations all depend on Windows
<xav>
silly for them
<Mike_L>
no. it is a failure of the IT industry to provide better products
<Mike_L>
and a failure of academia to educate the CS students properly so they can make good decisions and better products
<pango>
yes, back to ol' MS-DOS days without shared libs ! ;)
<Mike_L>
my uni is a perfect example
<xav>
indeed
<Mike_L>
pango: I highly doubt that shared libs will be supported under proof carrying code
<Mike_L>
at least not in their current flavor
<Mike_L>
anyway this is all just my insufficiently educated opinion =)
<Mike_L>
I wish I went to a good university that taught using ml =(
dan2_ has quit [Read error: 110 (Connection timed out)]
dan2_ has joined #ocaml
smimram has quit [Read error: 110 (Connection timed out)]
smimram has joined #ocaml
xav has quit ["leaving"]
Skal has joined #ocaml
_fab has joined #ocaml
pattern_ has joined #ocaml
Submarine has joined #ocaml
<Mike_L>
this room is so quiet
mfurr_sleep is now known as mfurr
<pattern_>
too quiet
<Mike_L>
hmmm LablGL seems very very cool
Skal has quit [Remote closed the connection]
<Mike_L>
I would love to write my application solely with glut but I need international text input and display
joeytwiddle has quit [Read error: 104 (Connection reset by peer)]
Skal has joined #ocaml
batdog is now known as batdog|gone
batdog|gone is now known as batdog
<Mike_L>
any idea how to resolve the problem "The files togl.cma and labltk.cma disagree over interface Tk"?
<Mike_L>
did they update the library and forget to test the examples?
<smimram>
they ? what distro are you using ?
<Mike_L>
I am using ocaml 3.08.3 Win-MSVC, lablgl-1.01, and Tcl/Tk 8.3.5
<Mike_L>
shared libraries causwaste so much of my time =(
<Mike_L>
s/causwaste/waste
<smimram>
sorry I don't know windows very well, I can only advise you to try to rebuild lablgl if you have the courage
<Mike_L>
i do not
<smimram>
:/
Submarine has quit [Read error: 145 (Connection timed out)]
<Mike_L>
can you use lablgl on your system?
<smimram>
yes
<Mike_L>
what versions of tcl/tk, lablgl, and ocaml do you have?
<smimram>
your problem is more likely to be that your lablgl wasn't compiled with your precise version of labltk
<Mike_L>
ok
ngaylinn has joined #ocaml
<ngaylinn>
Hello! I'm trying to parse OCaml code in a C++ program. It'd be nice to take advantage of the ocaml suite to do this, since ocamlc and camlp4 can both produce parse trees, but neither of the formats these programs output are documented to my knowledge.
<ngaylinn>
Does anyone know where I could find some information about these formats, where I could find yacc grammars for ocaml, or anything else that would help me parse ocaml code?
<ngaylinn>
*nods* Thanks. I was hoping someone might have written something for lex/yacc already, though.
<mfurr>
well, the parser used by the compiler is written in ocamlyacc/lex which is fairly similar to regular lex/yacc, have you looked at that?
<ngaylinn>
I can't say that I have. Does the source distrobution include the files used to generate the ocaml parser from ocamlyacc?
<mfurr>
yup, parsing/parser.mly
<ngaylinn>
*nods*
<ngaylinn>
Well, I'll take a look, but I have very little knowledge of yacc.
pango has quit ["Leaving"]
<Amorphous>
hi. anyone can give me advice how to track down where an ocaml application with some c-code in it produces an segv?
ngaylinn has quit ["Leaving"]
<mellum>
My advice is not to use C.
<smimram>
Amorphous: gdb
<smimram>
or valgrind if you think it could come from a memory leak
<Amorphous>
smimram: i would guess it is not even in the c code :)
<smimram>
heh
<Amorphous>
smimram: but i try gdb, thx
<TeXitoi>
Amorphous: you can't have a sigsev in ocaml (except bug in ocaml) in a pure and safe ocaml program
<smimram>
it has proved to work very well for me on similar issues
vezenchio has joined #ocaml
<Amorphous>
TeXitoi: it's neither pure nor safe and it's sometimes realy unclean (i'm talking about mldonkey )
<Amorphous>
TeXitoi: many times in the past we had similar problems due to ocaml
joeytwiddle has joined #ocaml
<Mike_L>
it's because Ocaml is still compiled as a C program :(
<mfurr>
Mike_L: what?
<Mike_L>
as are practically all language platforms
<mfurr>
what do you mean?
<Amorphous>
sure :) but it could also be some other problem with the persons execution environment
<Mike_L>
mfurr: or maybe I am wrong. How does one go about building the ocaml compiler itself?
<Mike_L>
the ocaml compiler and interpreter
<Mike_L>
and libraries
<Amorphous>
or some obscure but in the application that somehow defeats ocamls mem-protection or isn't that possible?
<Amorphous>
s/but/bug/
<Mike_L>
are they not all written in C?
<mfurr>
only the runtime is written in C
<mfurr>
the compiler and all of the libraries are written in pure OCaml
<mfurr>
(well, obviously not the unix lib, and things like that
<Mike_L>
oh excellent
<mfurr>
If you don't use any unsafe operations, OCaml should never crash
<Amorphous>
but the compiler produces binary code and there could be an bug introduced....
<Mike_L>
but still the runtime environment is C, and so it has the potential to crash with segv signals
<Amorphous>
mfurr: what are these unsafe operations?
<mfurr>
yes, but testing has removed most, if not all of those kinds of bugs
<mfurr>
Amorphous: things like String.unsafe_get
<Amorphous>
with that app both the byte code and binary does segv
<mfurr>
or anything from Obj, or any FFI stuff
<Amorphous>
there is much Obj.magic and such things in this application
<Mike_L>
has anyone tried to develop a standalone computing platform supporting a modern language that uses no C code at all?
<Amorphous>
mfurr: what's FFI?
<mfurr>
Then its the athor's own fault it crashes
<mfurr>
Amorphous: foreign function interface. IOW, calling C code
<mfurr>
Mike_L: its hard because the only way to interact with most operating system kernels is through a C api
<mflux_>
how about hops?
<mfurr>
so doing things like I/O can be problematic without that
<Mike_L>
mfurr: the idea is to make a new operating system that supports a modern language
<mflux_>
hmh, I mean hOp
<mfurr>
Mike_L: many have tried, not many have actually caught on to any significant user base
<mfurr>
:-(
<Amorphous>
mfurr: i'm not sure myself why the author chose to use these (for example Obj.magic) in the code. but i guess he did know why...
<Mike_L>
for example, a native standalone implementation of Erlang could consist of a dedicated erlang kernel that handled scheduling, avoiding expensive context switches
<mflux_>
it could be said that not even c is 'good enough' for writing operating operating systems, because actual operating systems always use assembler and c-compiler specific extensions..
<Amorphous>
Mike_L: i heard about some os nearly entierly written in lisp
<mfurr>
Amorphous: its probably because he thinks it will speed things up some small percentage and therefore forfeits all safety to get it.
<mflux_>
so if a non-c-operating system uses a bit of c (w/ extensions) I'd say it's ok
<Amorphous>
mfurr: could there be cases where it would _realy_ speed up things?
<Mike_L>
Amorphous: somehow I don't think that preempting a device driver is a good idea
<Amorphous>
Mike_L: so you say using preemtion in linux is no good idea?
<Mike_L>
Amorphous: well obviously there are some device interfaces that are properly synchronized
<mfurr>
Amorphous: only if the original algorithm was designed poorly, in which case it could be replace with a better, safe, algorithm
<Mike_L>
Amorphous: but how could you run, for example, a sound card driver in a user-mode process?
<Mike_L>
mflux: sweet
<Amorphous>
Mike_L: honestly i have not much knowledge about these things, but i guess it must be possible, as there are no device drivers in the l4 kernel space
<Amorphous>
or perhaps nobody has tried run an sound-card driver under l4 *g*
<Mike_L>
Amorphous: I think that sound card drivers generally have IRQ handlers that disable interrupts while they are executing, essentially disabling preemption. This would not be possible inside a user-mode process
<Mike_L>
TeXitoi: thank you
<Amorphous>
mfurr: do you know if there is some documentation about Obj.magic and other Obj. friends, that is some more verbose thant the ocaml manual?
<Mike_L>
TeXitoi: that project looks very interesting!
<mfurr>
Amorphous: its closely related to how the ffi works (its essentially C functions hoisted into OCaml)
<mfurr>
you need to understand how everything works "under the hood" before using the Obj.* functions
<mfurr>
read the interfacing with C chapter in the manual and you should have a better idea of how they work
<Amorphous>
*sigh* somtimes i realy hate the author
<Amorphous>
mfurr: thx again
<Mike_L>
ok time for bed
<Mike_L>
goodnight
* Mike_L
sleeps
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
<dan2_>
Amorphous: Obj.magic just scratches the type system
<dan2_>
its the equivalent of an automatic C cast
<mellum>
WTF is an automatic C cast?
<dan2_>
mellum: well the type of the Obj.magic obj is inferred at use
<dan2_>
mellum: so at that time then the type is casted
<mellum>
dan2_: yes, I understand that, I'm just not clear which C construct you refer to
<dan2_>
a typecast?
<dan2_>
(int)foo
<dan2_>
(char)bar
<dan2_>
blah
<Amorphous>
dan2_: with "at use" you mean when the specific code part is compiled?
<dan2_>
no when you call a typed function on it
<dan2_>
i.e.
<dan2_>
int -> int applied with 'a
<dan2_>
treat 'a like an int
<Amorphous>
dan2_: do you know about any documentation or examples for Obj ?
<dan2_>
no
<dan2_>
Obj isn't supposed to be used
<dan2_>
thats the point
<Amorphous>
dan2_: yea my problem is, that it is used and it is hard to replace without understanding exactly what it does :) . but thx anyway
pango has joined #ocaml
<Amorphous>
what functions from Obj ( (un)marshal excluded ) can be used to cause an segv?
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
mrsolo has joined #ocaml
<Amorphous>
Obj.magic and Obj.obj and nothing else right?
<mfurr>
most of them can, if used incorrectly
<mfurr>
especially the set_* ones
mfurr is now known as mfurr_away
<Amorphous>
so set_tag, set_field and i suppose truncate are also with that party
<ulfdoz_>
bye
batdog is now known as batdog|gone
batdog|gone is now known as batdog
Snark has left #ocaml []
Aradorn has joined #ocaml
Aradorn has left #ocaml []
joeytwiddle has quit ["Leaving"]
batdog is now known as batdog|gone
TeXitoi_ has joined #ocaml
TeXitoi has quit [Read error: 104 (Connection reset by peer)]