asabil has quit [Read error: 110 (Connection timed out)]
* thelema
finally got ocamlnet to compile
vixey has quit [Read error: 104 (Connection reset by peer)]
<thelema>
yay, I can compile batteries again!
<Yoric[DT]>
\o/
* thelema
needs to make a branch for 3.11
jackie_ has joined #ocaml
<thelema>
Yoric[DT]: or did we decide to drop support for 3.10?
<Yoric[DT]>
Not yet.
<Yoric[DT]>
We'll also need a feature freeze if we wish to have a Beta version for January.
<Yoric[DT]>
I'll send an e-mail an that subject.
<thelema>
it seems features have self-frozen, although we'll want to add more sometime.
<Yoric[DT]>
Yeah.
<Yoric[DT]>
But we still need people to confirm that they won't add anything at the last minute.
<Yoric[DT]>
Gottago, though.
<Yoric[DT]>
Talk to you later.
<thelema>
cheers
Anarchos has joined #ocaml
jackie_ has quit [Remote closed the connection]
<Anarchos>
how to check out the latest version of ocaml without overloading my local changes ?
seafood has quit []
<thelema>
Anarchos: you've made changes to a cvs version of ocaml
vixey has joined #ocaml
<thelema>
and you want to check out a newer version but keep your current changes?
Snark has quit ["Ex-Chat"]
<Anarchos>
thelema yes
<Anarchos>
i got a modified 3.10.2
<thelema>
can you produce a diff of your current changes to merge in with the new checkout?
<thelema>
are you actually using cvs as your VC?
<Anarchos>
thelema no i just chechout the source in a dir
<Anarchos>
i can do cvs up, but i get stick to 3.10.2
<Anarchos>
i can do cvs diff to produce a diff, but how to merge after that ?
<thelema>
use patch and pray there's not too many conflicts
<thelema>
are you on linux?
<thelema>
my real question is: can you use git?
<Anarchos>
i am on beos
<Anarchos>
i will use patch :)
<thelema>
ok.
<thelema>
if you can use git, I offer my public git mirror for you to publish changes.
<Anarchos>
no thanks : my patch are not stable enough : i can use standard ocaml on beos, but i lack some features, and i don't know how to finish the interfacing with the multithreaded C++ BeOS API
<thelema>
Does anyone else use ocaml on beos?
* thelema
finds that publishing unstable code will sometimes result in that code stabilizing
<Anarchos>
thelema i don't know
<Anarchos>
but there was a port of mldonkey so i think so !
<thelema>
sounds like at least one other beos ocaml user to be found.
<Anarchos>
;)
asabil_ has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
I have troubles displaying an image with lablgtk, I'd just like to display a .png file for the moment, has anyone pointers ?
<thelema>
Camarade_Tux: GdkPixbuf.from_file
<thelema>
make a GMisc.image widget and use #set_pixbuf to display
* rwmjones
notices that harrop is back trolling for F# again ...
* Camarade_Tux
hugs thelema
<Camarade_Tux>
I had tried something different previously but it was much longer and gave me "Exception: Gpointer.Null."
<Camarade_Tux>
now, let's add the ability to move and zoom :p
<thelema>
Anarchos: unlike you, I publish my unstable code. :)
<Camarade_Tux>
thelema, thanks, that should definitely help me
<Camarade_Tux>
now I need to slack off a bit and think more about the ui ;)
<thelema>
project goal?
<Camarade_Tux>
a map displayer, software is only a small part of the project (display map, move around, zoom, have tooltips for specific places, find routes, give bus/metro/... schedules and that's about it), hardware is going to be much more fun...
<thelema>
embedded ocaml?
<Camarade_Tux>
I had asked a few days ago about ocaml on arm ;)
<Camarade_Tux>
but considering that's not that serious (school) and the price to get a prototype, it may never exist
<Camarade_Tux>
so currently the plan is to make it on my laptop and have an external 4" screen ;p
robocop has joined #ocaml
<thelema>
tiny laptops have become quite cheap
<thelema>
also inexpensive
<Camarade_Tux>
a friend of mine just bought an eee 1000, I'll probably borrow it from time to time
Kerris7 has joined #ocaml
<Camarade_Tux>
it was funny, conky was completely wrong on the battery life estimation and gave 1/remaining_time instead of remaining_time so it thought the total battery life was about 20 hours ! ^^
<thelema>
heh.
<Camarade_Tux>
we had looked at it when 20% of the battery remained, I guess that'd be even funnier if we had looked at 0.1% ;p
<Camarade_Tux>
well, let's start slacking, see you
<robocop>
Hello.
<thelema>
hi ro
<thelema>
hi robocop
<robocop>
I don't understant what this code : http://paste.pocoo.org/show/95196/ send me "Exception: Invalid_argument "index out of bounds" when x is different of y...
<robocop>
"
<robocop>
have you got an idea ?
<robocop>
hello thelema.
* thelema
doesn't immediately see the oob error, it's likely a subtle one. can you get a backtrace?
<vixey>
I can only assume it's written in that way for 'efficiency reasons'
<thelema>
exactly. who wants a slow stdlib?
<Gionne>
it's too much for me ;) i've found a simpler one
jlouis has joined #ocaml
<Smerdyakov>
thelema, why [match] on a [bool], instead of [if]?
* thelema
rewrites that code
<thelema>
I imagine it was originally a None vs. Some match
<thelema>
there's some copy/paste style going on in extList.ml
<thelema>
the structure is almost identical to filter_map
<vixey>
thelema, what's this dummy_node() stuff?
<Smerdyakov>
The OCaml compiler does encourage copy-and-paste, with bad inlining for higher-order functions.
<thelema>
vixey: the loop has to have something to append to, but also needs to handle the case of filtering all nodes away
<thelema>
well, I guess maybe not for unique, but for others
<vixey>
thelema, Why isn't it a Hashtbl?
<thelema>
possibly because Hashtbl already depends on List...
<vixey>
I don't understand but I will just assume batteries is completely broken
<thelema>
(or maybe it doesn't)
<thelema>
possibly because this code is much faster for small lists. it has a tiny constant factor
<vixey>
what's wrong with fold_right (fun ys x -> x :: filter (fun z -> x != z) ys) for small lists?
<thelema>
ah, unique needs dummy_node because it keeps the *last* copy of each duplicated item
<thelema>
too much allocation.
<thelema>
O(n^2) allocation
<vixey>
so for small lists it would be better to create a Hashtbl and scan across the list with it?
<thelema>
although if we're talking about small anything, I shouldn't be able to make any sort of O argument
<vixey>
all road lead to rome anyway
<thelema>
well, for really small lists, it doesn't matter
<thelema>
for slightly bigger lists with lots of dups, the extlist code works best
<thelema>
for really big or less duped lists, hashtbl is best.
<vixey>
better than a Hashtbl?
<vixey>
oh I see
<vixey>
why is extlist better for medium sized lists?
<thelema>
overhead of hashing vs. iterating through the tail
<thelema>
s/overhead/cost/
<vixey>
I don't understand
<thelema>
hashtbl lookups have a cost of say 100 foo.
<thelema>
if it costs only 50 foo to find the next duplicate of an element (or determine there isn't one), then hashing loses.
<thelema>
if it costs 50 foo to determine uniqueness by scanning the tail of the list, ...
<alexyk>
what are people using for threads these days?
<thelema>
for small enough lists, or lists with enough duplicates (i.e. [1; 1; 1; 1; 2; 1; 2; 1; 1; 2; 2; 2; 1; 1; 2; 2; 2; 1; 2], iteration would win.
<thelema>
s/win/take less work/
<Smerdyakov>
I would say that wanting to remove duplicates from lists is _usually_ a sign that you're using the wrong data structures or algorithms.
<thelema>
Smerdyakov: agreed.
<thelema>
maybe method 3 to compare is building a Set.
<alexyk>
I have a program which tries to use par_map from prelude.ml, which uses fork, and it gets stuck -- processes call common tcp servers, callers wrapped as ocaml objects, and something gets stuck
<alexyk>
so I wonder what's the right way to do parallel map there is
<alexyk>
e.g. using threads?
<vixey>
Having unreadable confusing code is completely pointless actually
<thelema>
find what gets stuck - processes seem appropriate for parallel map
<vixey>
if anyone wanted to adapt the function to do something different this makes it harder
Kerris7 has quit []
<alexyk>
thelema: it's a whole new territory -- I see my tcp server processes double, with fork it's a whole new fun; and the only semaphores I found are from some ethread package of 2002
<alexyk>
basically I have shared resources and am not sure semaphores work across processes -- the examples are for threads
<thelema>
shared = r/o?
<thelema>
I guess not because you need semaphores
<thelema>
try to communicate over pipes
<Yoric[DT]>
Smerdyakov: perhaps not for short lists.
<alexyk>
thelema: r/o, indeed; they are lists of clients established connections on ports with a fixed sets of tcp servers; the pool of clients is used to do the work, and apparently forked clients step on each other
<alexyk>
the servers are designed to handle multiple connections, but clients don't have any provisions for being cloned
Gionne has quit ["Leaving"]
<thelema>
Can you fork helpers instead of servers?
<alexyk>
thelema: servers are independent, they just listen on ports; clients are simply wrapping the calling logic; apparently something in this setup doesn't fork well... will try to debug
asabil has joined #ocaml
<alexyk>
but in terms of other formalisms, is threading a part of ocaml?
<thelema>
jocaml is keeping up with the ocaml mainline, maybe look there.
Anarchos has quit ["Vision[0.8.5-0418]: i've been blurred!"]
fschwidom has quit [Remote closed the connection]
<Yoric[DT]>
alexyk: what do you mean "other formalisms"?
<alexyk>
yoric: methods to do concurrency
<Yoric[DT]>
Other than the Join-calculus, you mean?
alexyk has quit []
alexyk has joined #ocaml
love-pingoo has joined #ocaml
<flux>
figures, 400M is not enough for compiling godi..
<alexyk>
yoric: simple fork-based or threads
<flux>
(with my set of packages)
<alexyk>
flux: do you manage to compile godi for 3.11?
<flux>
alexyk, no, ran out of disk space..
<alexyk>
flux: but was it taking 3.11? :)
<flux>
yes
<alexyk>
did you start from scratch?
<flux>
no, godi just started recompiling everything
<flux>
but it failed already with ocaml itself :)
<flux>
I was gone for the day
<alexyk>
flux: what did you trigger to do that? godi-ocaml
<flux>
and left it compiling
<flux>
I reconfigured godi-ocaml-src, then told it to recompile godi-ocaml too
<flux>
then it said it's going to recompile x packages
<alexyk>
right, at that moment I got a godu assertion failure in godi plan or something
<flux>
well, I gave it 400M more play space, perhaps that'll help
<flux>
but one thing I'm particularly unimpressed is godis speed
<flux>
merely the checking stage (is proper package retrieved) takes multiple seconds per package - a nearly instant would be what I'd expect
<alexyk>
flux: OTOH, it does things with German precision and care :)
<flux>
I didn't know something could be slower than debian's apt :/
<alexyk>
flux: one may call it a thorough approach
<flux>
actually, fedora core 5's yum was even slower
<flux>
(than debian's apt)
<flux>
I wonder if the bsd system was as slow as this, which this originates from
<alexyk>
well I checked out omake from svn, it's fun to watch in slow motion
<Camarade_Tux>
flux, probably not as it handles thousands of packages iirc
<alexyk>
flux: macports, based on bsd ports too, is fast enough
<alexyk>
how can you find out the pid you're executing in?
<flux>
mfp, perhaps the path in the fix isn't ok? /bin/chmod: cannot access `ocaml/build/mixed-boot.sh': No such file or directory
<mfp>
worked for me
<mfp>
did you chain it with && \ ?
<flux>
rright :)
<mfp>
otherwise it won't be in ${WRKDIR}
<flux>
just added it the path fragment to the chmod command
<flux>
anyway, I already patched this compilation round live
alexyk has quit []
<flux>
apparently once you scroll backwards in godi_console, it is pointless to try to make it follow the tip of the buffer
<flux>
btw, where can I find godi cvs repository? (or similar, should it use some other vc)
<flux>
I'm thinking google has learned my searching habits, or godi has increased in popularity.. godi is the first hit for me in google, it didn't use to be so.
<flux>
1.6.2->1.6.5 seems to have fixed it (which was more difficult than it shoudl've had been..)
<kig>
alexyk: replied to your mail
<alexyk>
kig: thx!
Stefan_vK1 has joined #ocaml
<flux>
File "src/core/extlib.mli", line 725, characters 4-2185:> Error: The variant or record definition does not match that of type> Gc.control - apparently extlib too requires updating for 3.11?-o
<flux>
ah, actually that's part of batteries
<flux>
so just updating that, somehow, should do it
<alexyk>
kig: so I tried to cut out just the parallel combinators from the monolithic prelude, was it fun! I now now what unfoldrOpt is... or not really :)
<alexyk>
kig: what's the status of the refactored prelude? what's the most compact way to get parallel stuff without unfoldlOpt? :)
Stefan_vK has quit [Read error: 110 (Connection timed out)]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
jackie_ has quit [Client Quit]
<flux>
godi with ocaml-311 in summary: godi-omake, godi-ocaml-dbm, godi-ocaml-labltk, godi, batteries, type-conv nor cmigrep don't compile. type-conv was relatively easy to upgrade from 1.6.2 to 1.6.5, after which it worked
<flux>
(and of course their dependencies, among which is lablgl and ocsigen)
fschwidom has joined #ocaml
<alexyk>
flux: time to redistribute as godiflux :)
jeremiah has joined #ocaml
<Camarade_Tux>
ok, sdl was 100 times more appropriate than gtk =/
<det>
what are you doing
<Camarade_Tux>
display an image, move around and zoom
<Camarade_Tux>
I had forgotten sdl was also very good at displaying text and thought gtk would be better there but in fact my needs were very basic
<det>
OpenGL is probably your best best
<flux>
right, sdl was one of the packages I couldn't compile, but apparently because I wanted to use lablgl which again depends on labltk, which I couldn't compile.
<det>
SDL + OpenGL or GTK + OpenGL
<flux>
but ocamlsdl compiles without lablgl too. I want lablgl to work too, though :)
<Camarade_Tux>
flux, lablgl depends on labltk only if an option is set
<flux>
camarade_tux, even in godi? because I disabled the option, but the dependency doesn't go away.. or do I need to restart it?
<Camarade_Tux>
flux I don't think you'd need to restart but the dependancies could be badly-written
<flux>
camarade_tux, so the dependencies depend on package configuration?
<Camarade_Tux>
flux, I thought they did but apparently not, I just tried to disable the option and it still wants to build labltk which is a major annoyance for me
<Camarade_Tux>
det sdl has a simpler api afaik but I'll try opengl too and benchmark both versions
<det>
OpenGL has simple API too
<det>
and hardware acceleration
<flux>
I wonder how the opengl2 bindings are doing, though
<flux>
the labltk patching was simple enough to fix. although required updating the sha1 sum too, godi is quite picky..
<Camarade_Tux>
det, but the program will probably run on hardware unable to provide hardware acceleration
<det>
opengl software is available everywhere
<det>
and hardware almost everywhere
<flux>
well, chances are the software acceleration will suck compared to directly doing the more optimal thing
<Camarade_Tux>
OTOH I'm not sure it will ever run on anything embedded considering the price for prototyping on such hardware =/
<flux>
"GODI_OCAMLSDL_WITH_LABLGL: Whether to include support for OpenGL (yes/no). This adds a dependency to godi-lablgl. By default, this option is disabled."
<flux>
that would indicate there infact can be dynamic dependencies, which is nice
<flux>
..although in actuality such information doesn't appear anywhere
<Camarade_Tux>
so we now only need to ask the lablgl labltk static dependency to be corrected :p
<Camarade_Tux>
hmm, List.iteri would have been nice
<flux>
extlib (and batteries) has it
<Camarade_Tux>
I'm getting increasingly frustrated by that, I guess that's because I'm only starting to write bigger programs now
<Camarade_Tux>
but that was five lines and thirty seconds, I really can't understand why it's not gallium (well, I can understand but it could have been written there since *I* needed it ! ;p )
blizz2 has joined #ocaml
<flux>
let iteri f = ignore (List.fold_left (fun n el -> f n el; n + 1) 0
<flux>
whops, I can't curry l, was being too clever for my own good :)
<flux>
(I actually deleted the l -argument just before sending that)
<Camarade_Tux>
I went for the most stupid code, I'm too tired to think of any other ;)
jackie_ has joined #ocaml
<flux>
whee, I got ocsigen to compile too
<Camarade_Tux>
nice :)
<Camarade_Tux>
and I finally understood where that bad burnt plastic came from...
<Camarade_Tux>
s/plastic/plastic smell/
<kig>
alexyk: unfold creates a list from a function and an initial value until it hits the end value
<alexyk>
kig: see, that I can understand! :)
<kig>
i dunno what's the easiest way to extract them though, maybe push the unfold stuff into splitInto / groupsOf
<kig>
they're very compiler-unfriendly too
Kerris7 has joined #ocaml
* alexyk
studies APL with characters like∆
<alexyk>
kig: your "range" is a masterpiece :)
<alexyk>
I had to pull half prelude.ml to get it
<alexyk>
kig: the most dangerous thing when grabbing pieces of prelude is that you redefine map with rev (rev_map ..)
<alexyk>
one is never sure whether you redefined a name or just renamed it
<olegfink>
alexyk: do you like APL?
<kig>
ah, yeah. that's true
* alexyk
found this piece of APL to deal 25 hands of poker: 25?¨1e5⍴52
blizz2 has quit [Client Quit]
<alexyk>
olegfink: it's fantastic; the above line is a complete program
<alexyk>
the beauty of old languages, pre-perl, is that there more than one implementation :)
<olegfink>
alexyk: I live in some sort of a cave, it's almost impossible to get a recent CS book there
<alexyk>
olegfink: why, DHL delivers to SPb
<alexyk>
need to consult for Dvoika-Monolog and they'll buy you all books you want :)
<olegfink>
tedious
<olegfink>
alexyk, which APL implementation you use?
<alexyk>
olegfink: Dyalog educational
palomer has joined #ocaml
<palomer>
someone remind me what's the term for iterating over a tree
<alexyk>
it's for g-dless Windowz, but I run 'em in a vmware
<alexyk>
the problem with APL/J/Q tehre's no free software
<olegfink>
you mean implementations?
<alexyk>
yeah; even free-beer like are not free-freedom like
<alexyk>
closed binaries
<olegfink>
J's spec is open, there is even an abandoned opensource impl by some crazy russians
<alexyk>
yeah, we know how well they like to finish stuff :)
<alexyk>
that's basically my main philosophical problem -- non-free stuff
<alexyk>
non-freedom-free
<det>
How does J compare to Joy/Cat ?
<alexyk>
but, it reminds me of mainframe days -- vendor manuals, implementation-specific extensions, GUIs, good ol' comp.lang.apl
<alexyk>
det: never heard of those two, what are they?
<vixey>
det, it doesn't
<vixey>
completely different
<det>
Ok, I read first paragraph of description of J on wikipedia
<det>
seemed related
<alexyk>
olegfink: lots of nice J labs by Roger Hui
<det>
Joy/Cat are Concatenative functional programming languages. Joy somewhat of an alternative to lambda-calculus/SKI combinators and Cat introduces typing