<Payo543>
whats that whole graph thing in ocaml is it a part of the graphics library or is that a part of lablgtk i cant find it nor remember
<buluca>
Payo543: I think graph is actually a library for graphs (nets)
<Payo543>
hmmmmm
<Payo543>
buluca, i am trying to make a graph and save it as a image
<Payo543>
but trying to make it look pleasing to the eye which is possible with GD or imagemagick .........GD is kinda outdated i think though ...imagemagick is only like a year old
<buluca>
Payo543: I don't know... sorry
dibblego has left #ocaml []
dibblego has joined #ocaml
<abez>
Payo543: would gnuplot or R work?
<Payo543>
gnuplot is good
<Payo543>
but
<Payo543>
its not very eye pleasing from what i saw
slipstream has quit [Read error: 110 (Connection timed out)]
shawn has quit [Read error: 110 (Connection timed out)]
pango has quit [Remote closed the connection]
ikaros has quit ["Verlassend"]
ikaros has joined #ocaml
<ikaros>
is there a good ocaml plugin for eclipse?
yondalf has joined #ocaml
llama32 has joined #ocaml
<llama32>
i'm considering developing an animation/video editing application... i'm happy with gtk2 for the general UI, but how is canvas support with ocaml?
Skal has joined #ocaml
<zmdkrbou>
llama32: you want to write your whole video editing app in ocaml ?
<llama32>
yeah
<zmdkrbou>
are you sure ocaml is the right language to do this ? :)
<flux__>
why not?
<flux__>
albeit true multiprocessor support wouldn't hurt
<flux__>
and bindings to video codec libraries would need to be written
<llama32>
it's more for my own purposes than appealing to everybody's needs... like i don't mind if i have to make it spit out 500 pngs and invoke imagemagick to convert them to an mpeg or other formats, and have it pipe out some raw audio [if i even add audio editing] to some program to add it onto the mpeg
yondalf has quit ["leaving"]
mikeX has joined #ocaml
Snark has joined #ocaml
pango has joined #ocaml
<knobo>
flux__, zmdkrbou: which language would you use for that?
* zmdkrbou
wouldn't do that :) but would think C is best suited for this kind of apps
<zmdkrbou>
though i don't know if there are libs bindings
<zmdkrbou>
don't think there is gstreamer in ocaml or stuff like this
<knobo>
so, the reason is the libs, not the language?
<zmdkrbou>
no no, reason would be the language
<zmdkrbou>
ocaml is not that fast :)
<knobo>
but, I wouldn't be conserned with the speed of the language. The speed should be in the libs
<llama32>
lisp isn't really that fast... like there are some implementations that optimize pretty good, but the executables end up huge and eat up more memory than java, so it's not really practical
<knobo>
Looks to me that ocaml is fast enugh for most things
<llama32>
yeah
<yip>
also yay for haskell :]
<knobo>
yay?
<llama32>
there's no reason other than garbage collection that it would be slower than C if used in a similar manner [ie cutting down on closures/passing functions around, etc.], and the speed should be pretty acceptable if used in a more natural manner :)
<knobo>
a branch of the Tai languages ???
<pango>
knobo: I don't comparing it to Perl speed says much
<pango>
s/don't/don't think/
ikaros has joined #ocaml
<knobo>
pango: it was random, mostly for the link
<pango>
llama32: actually even Gc could be the other way around
<zmdkrbou>
llama32: if you write imperative code in ocaml to improve speed, then why do you use ocaml in the first place ....
<pango>
llama32: there's a paper about there comparing locality of memory references of SML/NJ, saying it has actually better locality than C or Fortran
<llama32>
GC has proven to be faster in some rare cases, but generally is a slight [or in java's case, massive] bit slower
<pango>
s/about/around/ (grr)
<llama32>
zmdkrbou: so i can write the other 99% of the code in functional ocaml without having to use 2 languages
<llama32>
hmm
<pango>
(from princeton uni I think... Hope I can find the link again...)
yondalf has joined #ocaml
<flux__>
I had one app (toy) where gc took something like 30% of cpu
<flux__>
too bad it could've been 0%, because the application essentially threw everything away after each iteration
<pango>
increase size of minor heap, for example
<flux__>
tuning gc parameters helped to bring that number down, though
<flux__>
maybe I should try again, being older and wiser ;-)
<pango>
or check how you're allocating memory in the first place
<pango>
in ML you tend to allocate a lot, but some kind of code allocate more than a lot ;)
yip has quit [Read error: 110 (Connection timed out)]
yip has joined #ocaml
Snark has quit ["Leaving"]
Wild_Cat has joined #ocaml
lmbdwr has quit [Read error: 104 (Connection reset by peer)]
bluestorm has quit ["Konversation terminated!"]
yip has quit [Read error: 110 (Connection timed out)]
buluca has quit ["Leaving."]
<Payo543>
anyone here have any experince in making a bidning for a c library ?
<postalchris>
I recommend CamlIDL
<Payo543>
postalchris, ?
<Payo543>
well theres alot of libraries in ocaml that neeed updating
<Payo543>
GD invluded
<postalchris>
payo543: camlidl is a wrapper for the c interface functionality that works really well if you don't have really crazy data structures to work with
<Payo543>
postalchris, well im just trying to update things like GD and stuff nothing real big
<postalchris>
what's gd?
<Payo543>
you know what imagemagick is ?
<Payo543>
and upgrade lablgtk+ to its most recent version
smimou has quit ["bli"]
<postalchris>
You can probably figure out what to do with the old code + the online Manual
<Payo543>
yea
<Payo543>
i was just wonderign if its super difficult or its not exactly all that hard ti implement a c function in ocaml code
Wild_Cat has quit []
buluca has joined #ocaml
Ben81 has joined #ocaml
chessguy has joined #ocaml
<postalchris>
payo543: it's not all that hard. there's an unfortunately confusing naming convention, but beyond that it's pretty much: call a function to turn a C value into an Ocaml value.
<postalchris>
Yes, but only once, and not happily.
<Payo543>
lol
<Payo543>
postalchris, what do you mean ?? is it that difficult ?
lmbdwr has joined #ocaml
<postalchris>
No, it's just annoying.
_fab has quit []
Ben81 has quit ["zzzzzzzzz"]
dark_light has joined #ocaml
<Payo543>
postalchris, well what would be faster wiritng a binding or calling a exec and calling GD form command line within the code
<postalchris>
payo543: I have no idea. The former is a lot simple...
<Payo543>
well im wondering if just calling it from command line is just as fast as writing a bidning for it
lmbdwr has quit [Read error: 110 (Connection timed out)]
<postalchris>
If you're going to do it several hundred or thousand times a second, write a binding, it not, just call it from the command line.
rillig has quit ["exit(EXIT_SUCCESS)"]
falconair has joined #ocaml
<falconair>
I've been told that ocaml is not very good for concurrent (multi-threaded) programming, is there any truth to that?
<pango>
yes, Gc (hence memory allocation) is protected by a big semaphore
<falconair>
so if i wanted to build some sort of server which had to do many things at once and serve many clients (web server/app server/db server/data server)...ocaml may not be a good idea?
<pango>
not with threads, at least
<falconair>
is there another way?
<pango>
processes, for example
<pango>
or a mix of the two; I actually don't know what performs best
<falconair>
crap, does ocaml have continuations or something so threads can be built on top of ocaml's existing functionality?
<pango>
there's closures, so I think there's continuations
<falconair>
ok, thanks pango
buluca has joined #ocaml
<Payo543>
holy crap that GD image binding looks impossible
<Payo543>
anyone else here have any experience in working with writing bindings to C libraries
<Payo543>
cause the GD library needs an update ........hasnt been updated in years
<Payo543>
also there needs ot be a better alternative to the ocaml hump
<pango>
go ahead
<Payo543>
yea i will
<Payo543>
casue half the libraries that are there are dead
<Payo543>
the files should be stored on the server
* pango
nods
<Payo543>
i will do it in a few days and collect what i can from the HUMP and put it on the server
<Payo543>
atleast most of the most common libs are still working
<pango>
lots can be recovered using the web archive
<Payo543>
but not files
<pango>
depends
<Payo543>
just html and some images
<pango>
already recovered tar.gz's
<Payo543>
i never saw that
<pango>
other times you recover the archive name, and that's enough for finding copies around
<Payo543>
took forever to find the jabber library and it was crap :X
<pango>
I remember that. And libraries that aren't crap may still be outdated (vs. compiler version)
<pango>
it's sad
<Payo543>
pango, the least developers could do is update libraries
<Payo543>
i think if ocaml had better community support or should i say more organized it owuld be far better then any other language
<Payo543>
and for all the c and c++ lovers i think D if it had better of the same would be far superior
<pango>
I guess most of those libs were just developed to satisfy their own needs at time t
Skal has quit [Read error: 104 (Connection reset by peer)]
<Payo543>
i would guess that also is what i am going to do
<Payo543>
buuuut i guess the positive thing is most libs will work some what .......but things like GD that have changed alot over the last 2 years is sol
<Payo543>
but atleast things like gtk sdl open gl all those are pretty up to date
<pango>
what would improve the situation is if all this code what put in CVS or similar, so that it can be updated by people
<Payo543>
pango, but hopefully by the time i am done i will have a few good libraries to commit
<Payo543>
jabber for one
<pango>
but that will require checking correct licensing of each lib
<Payo543>
hopefully GD for second
<Payo543>
do you know benchmark between ocaml top level and like python ?
<pango>
another thing that would improve the situation is integration of those libs in a common packaging framework like Godi
<Payo543>
i know the compiled is faster but what about interpted ? i assume faster as well
<Payo543>
i dont really like all those packagers and crap
<Payo543>
like rubny gems n stuff
<Payo543>
i am not really a fan of that crap
<pango>
comparing the efficiency of two implementation of different languages is difficult
<Payo543>
i understand
<Payo543>
theres alot of ocaml libns out there
<Payo543>
between sf.net ocaml hump freshmeat and a few sites on google
<pango>
the benefit of a packaging framework is that people are less prone to go cut&paste of the libs they need
<Payo543>
if they were just all collected in one space ......so they could be guanreteed to be there that would be alot better
<pango>
which in the end transforms in its own kind of maintainance nightmare