Ched has quit [Read error: 110 (Connection timed out)]
tmaedaZ is now known as tmaeda
mjs22 has joined #ocaml
mjs22 has quit [Remote closed the connection]
thrasibule_ has quit [Read error: 104 (Connection reset by peer)]
thrasibule has joined #ocaml
mjs22 has joined #ocaml
mjs22 has quit []
thrasibule_ has joined #ocaml
thrasibule has quit [Read error: 104 (Connection reset by peer)]
dyaso has quit [Read error: 110 (Connection timed out)]
thrasibule_ has quit [Read error: 104 (Connection reset by peer)]
thrasibule has joined #ocaml
mjs22 has joined #ocaml
thrasibule has quit [Read error: 60 (Operation timed out)]
jeddhaberstro has quit [Client Quit]
mjs22 has quit []
caligula_ has joined #ocaml
caligula__ has quit [Read error: 145 (Connection timed out)]
mishok13 has quit [Read error: 60 (Operation timed out)]
mishok13 has joined #ocaml
f[x] has joined #ocaml
bluestorm has joined #ocaml
rwmjones_ has quit [Read error: 148 (No route to host)]
_zack has joined #ocaml
ulfdoz has joined #ocaml
nodie has left #ocaml []
julm has quit [Read error: 60 (Operation timed out)]
_zack has quit [Read error: 113 (No route to host)]
Snark has joined #ocaml
hkBst has joined #ocaml
tmaeda is now known as tmaedaZ
mjs22 has joined #ocaml
Pepe_ has joined #ocaml
Pepe__ has quit [Read error: 113 (No route to host)]
marteo has joined #ocaml
ski_ has joined #ocaml
mjs22 has quit []
Ched has joined #ocaml
kaustuv has quit ["ERC Version 5.3 (IRC client for Emacs)"]
stan_ has joined #ocaml
smimou has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
r0bby has quit [Connection timed out]
pveber has quit ["ChatZilla 0.9.85 [Firefox 3.0.11/2009071415]"]
Ched has quit ["Ex-Chat"]
tmaedaZ has quit [Read error: 110 (Connection timed out)]
Ched has joined #ocaml
tmaedaZ has joined #ocaml
cmeme has quit [Read error: 60 (Operation timed out)]
cmeme has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
<Camarade_Tux>
I've written something to group objects in a plane according to their proximity to each others, now I'd like to make some visualization of it
<Camarade_Tux>
Graphics is easy to use but doesn't produce very beautiful graphics, any advice?
<bluestorm>
cairo gives reasonable results for it's ease of use
<Camarade_Tux>
he, the api looks like Graphics' : move_to, line_to ... :p
<Camarade_Tux>
anyway, gonna try that, thanks :)
<det>
Camarade_Tux, opengl ?
<det>
I once wrote something similar, kdtree grouping of objects and used opengl for visualization
<Camarade_Tux>
vam-split here ;)
<Camarade_Tux>
opengl could be overkill if I'm only doing 2D though
* Camarade_Tux
begs flux to merge his search patch to godi_console ;p
<det>
I was only doing 2d
<det>
OpenGL is great for 2d
<det>
depending on what you are drawing
<Camarade_Tux>
cairo-ocaml doesn't seem available in godi so I'll maybe turn to opengl first
<bluestorm>
no harm done :D
<Camarade_Tux>
(wasn't there a discussion about cairo-ocaml a few months ago for newhope? can't remember exactly how it turned out)
<Camarade_Tux>
now I need to see what I could use for opengl in ocaml :D
Ched has quit [Read error: 54 (Connection reset by peer)]
Ched has joined #ocaml
<flux>
hmph, tuareg-mode doesn't know about <:foo<>>-quotations
<bluestorm>
yes, that's a pain
<bluestorm>
I've considered trying to fix that but I'm really not up-to-speed on elisp
BiD0rD has quit [Read error: 110 (Connection timed out)]
BiD0rD has joined #ocaml
<flux>
bluestorm, btw, I'm not sure the feature <:update< foo >> (without |) is worth keeping
<flux>
bluestorm, I've had one serius bug due to a missing WHERE-clause :)
<flux>
infact, I would mind if it required an expression 'true', even in real SQL..
<flux>
same holds true with delete
<flux>
although happily the update with omitted | produces a warning about an unused variable row :)
<bluestorm>
hm
<bluestorm>
(yeah the unused variable error message is a nice side-effect of the will to play nice with OCaml variable scope)
<bluestorm>
flux: do you really think all-table update is frequently a mistake and should be made explicit ?
<flux>
bluestorm, well, do you really think all-table update is common in any way?
<flux>
I imagine it is extremely rare compared to the number of partial updates..
<bluestorm>
well, ok, I can disable the syntax
<bluestorm>
(for update and delete)
<flux>
great
<bluestorm>
(btw. I just had a look again at the tuareg-mode code, and it really is too much for me to handle, I think we should rather try to get in touch with one of the maintainers instead)
<flux>
bah, it looks like it would require touching to tons of places, if {< is any indication
<flux>
hm, I have a feeling it'll mess up if someone uses operator >>..
<flux>
nope, it looks impenetrable to me too :)
Yoric[DT] has joined #ocaml
stan_ has quit [Client Quit]
<Camarade_Tux>
why do none of the toplevels for GUIs have to fail when you alt+f4/close the window, sure it's the programmer's task to handle that gracefully but it'd be nice the toplevels didn't die
<Camarade_Tux>
(Graphics also dies but not immediately)
<flux>
a graphics lib written with top-level usage in mind would be nice
<flux>
would run in its own thread etc
<flux>
(thinking back the cool F# demos..)
<Yoric[DT]>
Mmmmmhhhhh....
<Yoric[DT]>
Yeah.
<Yoric[DT]>
Sounds like a good idea.
* Yoric[DT]
adds this to his own todo list :)
<flux>
must be getting pretty long :)
yurug has joined #ocaml
<Camarade_Tux>
he had to migrate to 64bit to get longer strings for his todo ;)
ulfdoz has quit ["kernel-update"]
<Yoric[DT]>
:)
<Yoric[DT]>
Unfortunately, adding stuff requires swapping to disk.
<Camarade_Tux>
I'm considering 8GB machines, it's like 80 euros ;p
onigiri has quit [Client Quit]
onigiri has joined #ocaml
r0bby has joined #ocaml
Anarchos has joined #ocaml
BiD0rD has quit [Read error: 110 (Connection timed out)]
kaustuv has joined #ocaml
ulfdoz has joined #ocaml
r0bby has quit [SendQ exceeded]
_zack has joined #ocaml
<flux>
does someone have a thread-based pmap/piter/etc around?
<Anarchos>
no sorry
<Yoric[DT]>
What would it do?
* Yoric[DT]
was actually considering implementing one for his demo on Thursday.
<flux>
mapping/iteration functions for parallelizing io-bound operations
<flux>
..or operations that use Unix.system to do their dirty work..
<flux>
yet they would be able to use Event.* for communicating with the rest of the system
<flux>
I need to do a parallel map on a set of documents I have (conversion) that request other documents by need
<flux>
the conversion itself is cpu-bound
<flux>
actually there are two levels of conversions, one for document pages and one for the documents themselves
<flux>
the first one is cpu-bound, the second one isn't
slash_ has joined #ocaml
<flux>
but, again, the cpu-boundness happens under Unix.system, so I don't mind if I lose true concurrency due to GC lock
<Tux|Jedi>
(I'm sure that page will load one day, one day)
<bluestorm>
(same thing :p )
<flux>
indeed, it took a while, and a few retries, to me too
<flux>
but I'm behind a 2G/3G link, so I was thinking it's just me
<Tux|Jedi>
tried on two different connections ;)
<Tux|Jedi>
make that three
<flux>
in nutshell it is: try (resource = new ResourceFoo(); resource2 = new ResourceBar()) { insert code using resource and resource2 here; }
<bluestorm>
hum
<bluestorm>
F# has related "use" keywords
<flux>
however for a Complete Solution I would like to see a way to 'detach' a resource explicitly, in case I decide to pass the resource to another thread or store it or something
<flux>
I figure implementing that in ocaml can be slightly tricky
<bluestorm>
hm
<flux>
would be simpler if all resources were usually objects with a disposing method
<bluestorm>
without an elaborate type system, you can't guarantee ressources won't leak
<flux>
well, a guarantee isn't required
<flux>
making it slightly more difficult to leak than not leak is sufficient :)
<flux>
or, maybe someone can write a linear type system for ocaml..
<bluestorm>
batteries does not support that (yet), support for try .. finally and "try binding" is however scheduled
<Yoric[DT]>
Yep.
<Yoric[DT]>
bluestorm: by the way, don't you have Batteries-related homework? :)
<bluestorm>
yes I do
<orbitz>
Does anyone have an opinion on RAII? Hardcore C++ enthusiests seem to think it's the only way to do resource managmetn, so anythign GC'd is not up to snuff
<bluestorm>
I have ton's of something-related homework
<bluestorm>
-'
<Yoric[DT]>
:)
<Yoric[DT]>
orbitz: well, I like region-based resource management, does it count?
<orbitz>
I don't know, i'm asking out of curioustly because I'm not familiar enough. what is region-based?
<Yoric[DT]>
This is based on an abstract notion of region. Regions are just a way of grouping resources (such as memory) conceptually, by dependencies.
<Yoric[DT]>
Whenever you allocate a resource, you specify statically (or the compiler adds it automatically) a Region to which the resource belongs.
<flux>
orbitz, I think I'm of the same opinion, it is the best solution for resource management
<flux>
unfortunately I don't feel it would be the best solution when the resource in question is memory
<Yoric[DT]>
With a little static analysis, you can then perform deallocation at statically-predictable points, without the need for complex garbage-collection tricks.
<orbitz>
As I understand the value of RAII is 1) When the object is created then you know that resource has been allocated (no zombie objects) and 2) When that object goes out of scope/dies, you know that resource is free'd. I think 1 happens in languages with GC (Java/Ocaml/Erlang), it's part 2 that is not predictabl,e ocrrect?
<Yoric[DT]>
Well, going out of scope is predictable. Going out of the dependency graph is much trickier, yes.
<flux>
support for scoped variables ala c++ would be an interesting trick
<flux>
going out of the dependency graph would then be determined with reference counting
<orbitz>
Ocaml doesn't support anthing like finalize does it? (I have to call close_in)
<Yoric[DT]>
It's feasible, technically.
<Yoric[DT]>
orbitz: finalize exists.
<Yoric[DT]>
(with essentially the same [lack of] semantics as in Java)
<orbitz>
ok
<orbitz>
in/out channels just don't have it?
<Yoric[DT]>
flux: there's a paper by Oleg on the topic, for Haskell, and I've ported it to OCaml about three years ago, to see if it was possible.
<Yoric[DT]>
(it is)
<Yoric[DT]>
(just not nice without typeclasses)
<Yoric[DT]>
orbitz: they don't take advantage of it.
<Yoric[DT]>
orbitz: in Batteries, though, they do.
<orbitz>
awesome
<Yoric[DT]>
(but it's tricky and I'm still not 100% certain that we got it right)
<orbitz>
does one hav eto wrap in/out channels in an object to take advantage?
<orbitz>
object/class?
<Yoric[DT]>
Nope.
<orbitz>
where can i read up on it?
<Yoric[DT]>
Mmmmh....
<flux>
orbitz, it's not a good idea to rely on it, though
<orbitz>
why is that?
<orbitz>
is it because the GC might not keep up with how fast i open/close in/out channels?
<flux>
orbitz, for example your cp-clone might work, but it fails after you copy 1020 small files
<flux>
because GC might not just decide to release fds
<flux>
I would most preferably like installed finalizers just produce a warning if and fd goes released non-closed
<flux>
an fd, even
<orbitz>
flux: so you can track down those places you forgot
<Yoric[DT]>
Perhaps this should be an option.
<flux>
orbitz, yes
<flux>
yoric[dt], perhaps through an environment variable
<orbitz>
It can be nice to just hand over ownership of something ot someone else and let it clean up whenever they are done though
<Yoric[DT]>
auto-releasing is probably a better choice for short programs, as you don't have to clutter them with resource management
<orbitz>
Yeah
ski_ has joined #ocaml
<orbitz>
luckly a lot of my programs I get away with just using using stdin for all input
<hcarty>
Yoric[DT], flux: I'm (slowly) working toward making PLplot+Cairo+lablgtk a useful toplevel-friendly graphics combo
<orbitz>
hcarty: as in how one would make a UI lib in a functional language, not just a weak wrapper?
<hcarty>
With the idea being that the graphics window would run/update from a separate thread.
<Yoric[DT]>
hcarty: that's great
<Tux|Jedi>
if you need testers :)
<hcarty>
orbitz: That would be wonderful (a cleaned up FrGui, which is looking less likely)
<hcarty>
Tux|Jedi: You can grab the latest PLplot svn to get most of the existing pieces :-)
<Yoric[DT]>
That would be great, too.
<bluestorm>
the ocsigen peoples are considering using functional reactive programming for javascript-side UI
<bluestorm>
they might end up maintaining a frgui library
<orbitz>
that sounds prety cool
<hcarty>
Tux|Jedi: They are not tied together yet, but I have written stand-alone GUIs with it. Threading is something I am currently unfamiliar with though, so I'll have to get a handle on that. Or someone else can :-)
<hcarty>
bluestorm: That would be nice
<Tux|Jedi>
hcarty: will check that right after my vam-split visualization is done (which means after I've slept enough and stopped procrastinating...)
<Tux|Jedi>
hcarty: hehe :P
<hcarty>
I've been playing with a simple-ish lablgtk wrapper, which is visually similar to what currently exists for FrGui, but minus the "Fr" and in general not as powerful.
<Tux|Jedi>
I still have to try them but the last one I tried didn't build (or was that qt-caml?)
<hcarty>
Tux|Jedi: If you do, please let me know how it goes. PLplot is, at its core, a C library but I wrote the included OCaml bindings.
<hcarty>
And I am working on a more friendly and OCaml-ish interface for PLplot.
dyaso has quit [Remote closed the connection]
ched_ has joined #ocaml
<bluestorm>
hcarty: was there not a related Jane Street summer project ?
<bluestorm>
(the first year)
julm has joined #ocaml
ched_ has quit [Client Quit]
<hcarty>
bluestorm: Yes, that is the one I mean
<Yoric[DT]>
bluestorm: er...
<Yoric[DT]>
That would need a complete reimplementation of FrGui, wouldn't it?
<bluestorm>
?
<hcarty>
The author is not able to maintain it at this time. It's mostly working, but not complete. I tried digging in to the code, but it was beyond what I was able to dedicate time to.
<bluestorm>
ah
<bluestorm>
I really don't know Yoric[DT]
<bluestorm>
actually there a few existing functional reactive toolkits for ocaml, not only FrGui
<hcarty>
There's React
<Yoric[DT]>
FWIW, at mlstate, we have something yet different for web/gui programming.
<Yoric[DT]>
It's not in OCaml, of course, it's in our language.
<hcarty>
And someone has a functional reactive web/javascript toolkit they posted to the mailing list some time ago.
<bluestorm>
and there also is the issue that they're in a hostile environment (running ocaml bytecode in javascript -__-)
<Yoric[DT]>
Yep :)
ulfdoz has quit [Read error: 110 (Connection timed out)]
<sgnb`>
hcarty: froc?
sgnb` is now known as sgnb
ched_ has joined #ocaml
<hcarty>
sgnb: Yes, thanks. That's the other one.
Ched has quit [Read error: 110 (Connection timed out)]
Snark has quit ["Ex-Chat"]
<bluestorm>
flux: I implemented a command-line-option to make the ending | for update/delete optional (it is mandatory by default)
<bluestorm>
.. and was delighted to run into a small camlp4 trickery
<bluestorm>
there is the documentation left to be updated, and I'll push the patch
ofaurax has joined #ocaml
knight[rage] has joined #ocaml
<knight[rage]>
hey guys. so i'm new to ocaml (but not new to programming) and i cant for the life of me figure out why im getting the error 'Unbound value string' for this code: open String class task = object (self) val mutable name = ( string ) end;;
<knight[rage]>
im just trying to make a 'task' object that will (for now) have only that one data member
<Tux|Jedi>
knight[rage]: ':' instead of '=' ?
<Tux|Jedi>
and you don't need to "open String"
<Tux|Jedi>
also, the code you pasted tries to set name as string which would be a *variable* your class should take as constructor
* Tux|Jedi
can't speak/write properly, need sleep
<bluestorm>
knight[rage]: you're getting that message because the "string" value you use is not declared in your code
<bluestorm>
also, if you're an OCaml beginner you should definitely not begin with Ocaml Object Oriented system
<bluestorm>
it's not the easier to approach, nor the most widely used part of the language
<bluestorm>
and you're most likely going to try to reproduce your habits of other oo languages
<bluestorm>
if that's your first functional programming language, please try to learn functional programming before taking the OO route
BiDOrD has joined #ocaml
knight[rage] has quit [Read error: 110 (Connection timed out)]
dabd has joined #ocaml
thrasibule has joined #ocaml
_zack has quit ["Leaving."]
ulfdoz has joined #ocaml
ulfdoz has quit [Read error: 110 (Connection timed out)]
r0bby has joined #ocaml
stan__ has joined #ocaml
yurug has quit ["KVIrc Insomnia 4.0.0, revision: , sources date: 20090115, built on: 2009/03/07 00:45:02 UTC http://www.kvirc.net/"]
LeCamarade|Away has quit [Read error: 145 (Connection timed out)]
LeCamarade|Away has joined #ocaml
stan__ has quit [Client Quit]
Yoric[DT] has quit ["Ex-Chat"]
Anarchos has quit [Read error: 145 (Connection timed out)]
Pepe_ has quit [Remote closed the connection]
Pepe_ has joined #ocaml
bluestorm has quit [Remote closed the connection]
smimou has quit ["bli"]
thrasibule_ has joined #ocaml
thrasibule has quit [Read error: 110 (Connection timed out)]