Demitar has quit [Read error: 110 (Connection timed out)]
jlouis has quit [Read error: 110 (Connection timed out)]
bluestorm has quit [Remote closed the connection]
middayc has quit []
thermoplyae has quit [Read error: 104 (Connection reset by peer)]
mib_gDWrgMMG has joined #ocaml
mib_gDWrgMMG has left #ocaml []
mordaunt has joined #ocaml
yminsky has joined #ocaml
rayno has joined #ocaml
\-Catch22-\ has quit []
\-Catch22-\ has joined #ocaml
thermoplyae has joined #ocaml
jonathanv has joined #ocaml
kmeyer has quit ["Leaving"]
konrad__ has joined #ocaml
yminsky has quit []
yminsky has joined #ocaml
yminsky has quit [Client Quit]
jonafan has quit [Read error: 110 (Connection timed out)]
<orbitz>
is it common to return data in an exception? I am looking for a useful idiom to recursively collect data into a list but also signal that an exception has been generated if so
<mbishop>
hmm, well you can do "Exception foo of bar" where bar is a type...as far as I know it can be any type
<orbitz>
it can, but my question is if that is acceptable
<orbitz>
major performance hit to move data up teh stack? poor choice?
<orbitz>
is returning a tuple of (result, error)
<thermoplyae>
i've seen it done plenty of times in Java
<thermoplyae>
as a best case, it's pretty ugly. seems an abuse of the concept
<orbitz>
i agree
<orbitz>
i'm guessing returning a tuple might be best?
<thermoplyae>
sure, if you can make it work
<thermoplyae>
you can keep the exception throwing paradigm if you use continuations
nashdj has joined #ocaml
<orbitz>
basicaly i'm trying ot consturc tan object from an input stream which is easy enough to do recursively but the data might be poor in some places but I can handle it but I want to log it
konrad__ is now known as kmeyer
mrsolo has left #ocaml []
harlos has joined #ocaml
harlos has left #ocaml []
zmdkrbou has quit [Read error: 110 (Connection timed out)]
rayno has quit [Remote closed the connection]
<tsuyoshi>
you want to throw an exception to log it?
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
Mr_Awesome has joined #ocaml
Associat0r has quit []
zmdkrbou has joined #ocaml
AxleLonghorn has joined #ocaml
<AxleLonghorn>
hello
<AxleLonghorn>
anyone out there?
<thermoplyae>
maybe
<AxleLonghorn>
hey
<AxleLonghorn>
is this the only ocaml irc channel?
<tsuyoshi>
probably
AxleLonghorn has left #ocaml []
\-Catch22-\ has quit [Read error: 113 (No route to host)]
thermoplyae has quit ["daddy's in space"]
mordaunt has quit [Remote closed the connection]
ttamttam has joined #ocaml
<jdavis_>
if you have a big tuple, e.g. (1,2,6,4,3,5,6,7), what's the easiest way to access element N?
<pango>
of course it only works for tuples whose elements have the same type
<flux>
jdavis_, if you have a big tuple, consider using records..
robyonrails has joined #ocaml
<jdavis_>
Ah, thanks.
pango is now known as pangoafk
middayc has joined #ocaml
filp has quit [Read error: 104 (Connection reset by peer)]
filp has joined #ocaml
asmanur has joined #ocaml
ygrek has joined #ocaml
pangoafk has quit [Remote closed the connection]
ygrek has quit [Remote closed the connection]
jlouis_ has quit [Remote closed the connection]
jlouis has joined #ocaml
ygrek has joined #ocaml
pangoafk has joined #ocaml
marmottine has joined #ocaml
hkBst has joined #ocaml
petchema has joined #ocaml
marmottine has quit [Remote closed the connection]
ttamttam has left #ocaml []
Demitar has joined #ocaml
marmottine has joined #ocaml
leo037 has joined #ocaml
ikaros has joined #ocaml
Yoric[DT] has joined #ocaml
ikaros has quit ["segfault"]
ttamttam has joined #ocaml
zirhc has joined #ocaml
comg has joined #ocaml
ita has joined #ocaml
zirhc has quit [Read error: 110 (Connection timed out)]
Black_ReZ has joined #ocaml
Black_ReZ has left #ocaml []
middayc- has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
ttamttam has left #ocaml []
leo037_ has joined #ocaml
flux-___ has joined #ocaml
leo037 has quit [Connection timed out]
flux has quit [Read error: 131 (Connection reset by peer)]
dbueno has joined #ocaml
Demitar has quit [Read error: 110 (Connection timed out)]
Demitar has joined #ocaml
|Catch22| has joined #ocaml
comg has quit [Client Quit]
Associat0r has joined #ocaml
ttamttam has joined #ocaml
flux-___ is now known as flux
jedai has joined #ocaml
leo037_ is now known as leo037
|Jedai| has joined #ocaml
pangoafk has quit [Remote closed the connection]
pangoafk has joined #ocaml
Morphous_ has joined #ocaml
jedai has quit [Read error: 113 (No route to host)]
Morphous has quit [Connection timed out]
pangoafk has quit [Remote closed the connection]
pangoafk has joined #ocaml
jonathanv is now known as jonafan
filp has quit ["Bye"]
nashdj has quit [Read error: 110 (Connection timed out)]
<middayc->
I am learning about ocaml and FP ... I would use it mainly for making games so one thing confuses me a little ... (is anybody here?)
<ita>
middayc-: ask your real question
jedai has joined #ocaml
<Yoric[DT]>
Answer to your question: yes, there are people here.
* Yoric[DT]
is always happy to oblige.
<middayc->
when I read about FP reat that things should be immutalbe and that there should be little state or side effects... but if I am making a game I need states all around the place ... a trivial example, I need an x,y and velicity vector of every bullet, particle efect, main character, enemies with more states regarding to their behaviour .. etc... is this ok then or I don't get something
<middayc->
this al naturally matches with O in ocaml because it's easy to timulate all these objects if I use object oriented side of ocaml but I have read somewhere that OO doesn't go that well with FP
<middayc->
timulate = simulate
<hcarty>
middayc-: I've been playing with the Objective part of OCaml recently, and it seems to integrate nicely with the rest
<hcarty>
For the velocity vector example - one way to think about it would be to have your update function return a new "bullet" rather than modifying the old one.
<middayc->
aha ... then it's ok ... because I am new I thought working withouth OO for that reason, but then I need to use a lot of other custom types and stuff to do the same thing and it seemed more messy
<hcarty>
But it's a style choice, and OCaml lets you have it both ways
<middayc->
:) that is an interesting view (new bullet every time)
<middayc->
but would that work efficiently?
<hcarty>
middayc-: Depends on your definition of efficiently :-)
<hcarty>
OCaml is generally pretty quick
<Yoric[DT]>
Objects are relatively slow.
<Yoric[DT]>
But if you use records, that should be quick.
<ita>
middayc-: do you have recursivity in your code ?
_Jedai_ has joined #ocaml
<middayc->
:) ok ... I mean would making each time new bullet take roughly the same amount of time than updating old one? for games speed is important.. thats why I look at ocaml
<Yoric[DT]>
At some point, you'll need to profile your code.
<Yoric[DT]>
But OCaml is often able to optimize this "create a new bullet each time" to "reuse the same bullet".
<middayc->
by roughly the same I mean - less than 10x ...
<middayc->
aha
<middayc->
...then I will try to think this way and see what I manage to get
<middayc->
ita: there is only one recursive loop for the main loop
<ita>
middayc-: then fp might not help in that place
<middayc->
I am really just starting with all this ... I am trying to make something move with SDLCaml
<middayc->
so it's also very little code for now
<middayc->
that "new bullet" philosophy seems interesting to me... I will keep it in mind and try to solve things that way if I will manage to...
<RobertFischer>
middayc- Whenever possible, use many small, rapidly-GC'ed data elements.
<RobertFischer>
Ocaml is highly optimized for that kind of behavior.
<RobertFischer>
All of your ex-Java (or whatever) training which says that "object creation is expensive" needs to go out the window.
<RobertFischer>
You're generally best off using records or tuples (as appropriate) and minimizing the amount of mutable data you have. This will give you the best performance in Ocaml.
<middayc->
aha ... yes I was thinking about GC in that way
<RobertFischer>
Thinking in terms of list/graph processing instead of message passing is also a major performance improvement.
<RobertFischer>
So, when you have a bunch of sprites and a change in the moment in time, don't think of telling each and every sprite to update itself -- that's the OO way to approach the problem.
<ita>
does the use of closures instead of classes change anything speed-wise?
|Jedai| has quit [Read error: 113 (No route to host)]
<middayc->
huh I have no ide what is list/graph processing ...
<RobertFischer>
Do you know what a graph is?
<middayc->
no
<RobertFischer>
A graph is a data structure of data structures.
<middayc->
aha .. like a tree
<middayc->
like list is flat -- a graph is structured?
<RobertFischer>
Yes, where each node is a data structure. So a list of lists, a tree of lists, a tree of maps of lists of map-list tuples.
<RobertFischer>
Whatever.
<ita>
middayc-: {vertex, arcs}
<middayc->
aha ... I begin to understand what you mean by list/graph processing vs object.update()
<RobertFischer>
The more you can just tell OCaml (or any FP language), "Here's how to process each element of that graph, and here's the graph to process", the better off you'll be. See fold and iter of examples of that.
<middayc->
cool ... you should write a book ... you explain it in a way I can quickly understand
<RobertFischer>
If you think of your state as a graph of elements, and can define a function which changes your state and returns the new graph of elements, then you're going to be digging around at the best performance in Ocaml.
<RobertFischer>
I'm doing a podcast and writing a blog.
<RobertFischer>
I'll work on a book later. :-D
<middayc->
aha ... a new graph each time?
<middayc->
I have to invert my brain from stuff I am used to and then it all makes sense
<RobertFischer>
Pretty much.
<middayc->
where is the podcast and blog?
<RobertFischer>
As an OO person, you're used to talking about nouns. As a FP person, you'll be talking about verbs.
<middayc->
yes ... it's quite the contrary ...but also very simple if I look at it as you say it
<RobertFischer>
It's very Java-y (and a bit Haskell-y) right now, but there's some good Ocaml stuff on there, too.
<RobertFischer>
The podcast isn't public yet, because I still have to do post-production. But it won't really be on Ocaml stuff anyway (it's on how the internet is changing our culture).
<middayc->
aha ... also interesting
<middayc->
yes ... So far I like what I saw about ocaml
<middayc->
If I will manage to move few objects on the screen in ocaml then I am in a good way to make something game-like in it
<jonafan>
RobertFischer, i read your blog
<jonafan>
i learned monads from you though i really do not understand them fully yet
jedai has quit [Read error: 110 (Connection timed out)]
<RobertFischer>
The monads stuff isn't me -- that's BHurt.
<RobertFischer>
He does the deep techie stuff better than I do.
<ita>
ah, ok
<jonafan>
oh
pangoafk has quit [Remote closed the connection]
<jonafan>
well it's still a good blawg
<ita>
indeed
<Yoric[DT]>
ita: yeah, I've seen.
<RobertFischer>
ita: And deadlocks are the easiest problem to solve -- many languages solve them outright through immutable data or other language limitations. Even if you don't, there is a kludge that will generally solve your problem: see if a lock takes too long, restart one of the two deadlocking threads, and move on with life.
<RobertFischer>
This is the standard approach in database programming, for instance.
<RobertFischer>
It kills performance, but it'll work. :-D
<ita>
i see
<RobertFischer>
A livelock -- that one's uglier. And priority inversion is tough to even realize is happening before it's too late.
<ita>
any links on priority inversion ?
pangoafk has joined #ocaml
<RobertFischer>
Not really. But the idea's pretty simple.
<RobertFischer>
Given high-priority task A and low-priority task B, something happens which makes A dependent on B, which isn't getting run because it's low priority.
<RobertFischer>
So A won't get run until *after* B gets run, and B will only get run when low-priority stuff is run, so A is actually lower priority than B.
<ita>
ah, thanks
<RobertFischer>
That's a tricky one without some kind of serious help from your concurrency framework.
<ita>
what are live locks ?
ygrek_ has joined #ocaml
kelaouchi has joined #ocaml
<RobertFischer>
Live locks are like deadlocks, except that one of the two threads are busy with a resource (instead of just locking on it).
<RobertFischer>
It's also known as resource starvation.
<RobertFischer>
So, consider a situation where I've got two threads, one reading from a file and one writing to a file. The thread that is reading from the file won't release the lock on the file until after it's read and processed everything.
<RobertFischer>
This means that the thread writing to the file has to wait for the thread reading to finish EVERYTHING.
<RobertFischer>
So I'm basically back to being single-threaded.
<RobertFischer>
That's the reasonably nice form of a livelock.
<ita>
ah
<RobertFischer>
The ugly form of a livelock is when you combine that with a deadlock, and both threads are busy processing with both resources, but want to talk to the other's. :-P
<RobertFischer>
The classic case that comes in is "busy wait locks", where someone decides to implement their own polling.
<RobertFischer>
This is where rifles and pitchforks start coming out.
<Yoric[DT]>
:)
<Yoric[DT]>
The other kind of livelock I know is "hey, let's avoid deadlock by releasing locks and trying again later"... except both threads are doing that and keep hitting the same wall.
ygrek has quit [Remote closed the connection]
Oatschool has joined #ocaml
<RobertFischer>
Oh, yeah, that one is cool.
marmottine has quit ["Quitte"]
leo037 has quit [Read error: 110 (Connection timed out)]
RobertFischer has left #ocaml []
pangoafk has quit ["I shouldn't really be here - dircproxy 1.0.5"]
pango has joined #ocaml
robyonrails has quit ["Leaving"]
middayc has joined #ocaml
middayc- has quit [Read error: 110 (Connection timed out)]
ygrek_ has quit ["Leaving"]
ygrek has joined #ocaml
leo037 has joined #ocaml
jlouis_ has joined #ocaml
ygrek has quit [Remote closed the connection]
jlouis has quit [Read error: 110 (Connection timed out)]
leo037 has quit ["Leaving"]
mlasson_ has joined #ocaml
mlasson_ is now known as mlasson
asmanur has quit [Remote closed the connection]
kelaouch1 has joined #ocaml
pango has quit [Remote closed the connection]
middayc is now known as middayx_
middayx_ is now known as middayc_
middayc_ is now known as middayc
kelaouchi has quit [Read error: 110 (Connection timed out)]
pango has joined #ocaml
filp has joined #ocaml
filp has quit ["Bye"]
ttamttam has left #ocaml []
Demitar has quit [Read error: 110 (Connection timed out)]