smimou changed the topic of #ocaml to: OCaml 3.08.3 available! | Archive of Caml Weekly News: http://sardes.inrialpes.fr/~aschmitt/cwn/ | A free book: http://cristal.inria.fr/~remy/cours/appsem/ | Mailing List: http://caml.inria.fr/bin/wilma/caml-list/ | Cookbook: http://pleac.sourceforge.net/
mercy has joined #ocaml
mercy has quit [Client Quit]
Skal has quit [Remote closed the connection]
bk_ has quit [""(quit)""]
vezenchio has quit ["Ayn Rand encapsulates the rage that every teenager feels on finding that his first paycheque has had taxes taken out of it"]
dvanhorn has joined #ocaml
gim has quit ["bininuit"]
er has joined #ocaml
<er> it seems that streams created using Stream.of_channel are incompatible with the stream parser - as the docs say as well.
<er> any ideas on how to go about creating a stream that can be used?
pango_ has quit [Remote closed the connection]
Smerdyakov has joined #ocaml
ulfdoz_ has joined #ocaml
er has quit [Read error: 113 (No route to host)]
cognominal_ has quit [Ping timeout: 14400 seconds]
ulfdoz has quit [Read error: 110 (Connection timed out)]
Smerdyakov has quit []
Herrchen has joined #ocaml
Nutssh has joined #ocaml
Herrchen_ has quit [Read error: 110 (Connection timed out)]
y6cmE has joined #ocaml
y6cmE has quit [Read error: 145 (Connection timed out)]
mrsolo has quit ["Leaving"]
Saulzar has joined #ocaml
<ulfdoz_> re
<Saulzar> Hmm, what is the simplest way to do non blocking io with the ocaml libs? I've been using an in_channel for reading across a network, I see two options a) use threads b) switch to lower level socket functions and use select... neither look particually fun
<Nutssh> Depends on what model your software uses? Event driven or multithreaded.
<Saulzar> My software is very small :)
<Nutssh> I think you've outlined the two options you have.
<mflux_> saulzar, the select-way may not be that bad if there's a proper framework..
<Nutssh> It depends on the nature of your program.
<Saulzar> Hmm, true - I guess it's just a little extra typing
<mflux_> it's undocumented and incomplete of course ;)
<Saulzar> It's a small bot connecting to IRC to do absolutely nothing, presently - just something attempt to learn ocaml with
<mflux_> but, basically, it's continuation based select framework
<Saulzar> Cool - thanks. Perhaps I'll try both.
<Saulzar> mflux_, What do you mean by continuation based?
<mflux_> saulzar, the functions (ie. write) have an argument for a function which will be called with the 'return value' of the function
<Saulzar> Ahh
<mflux_> so basically you call functions like read sock (fun s -> Printf.printf "You received %s\n" s; write sock (fun () ..)) etc
<mflux_> and at each point the function actually returns and adds the operation to the pool of operations to do, and the main select loop then calls the functions
<mflux_> what the framework currently really misses is some abort mechanism
<Saulzar> Hmm.
<mflux_> (some communication mechanism could overcome that)
<mflux_> btw, if you haven't checked it yet out, the Event-module in ocaml somewhat inspired me to write that
<mflux_> (but better check the net for some concurrent ml documentation with examples on how to really use them; for me the documentation itself wasn't a real eye-opener)
pango has joined #ocaml
<Saulzar> Cool, thanks. Will do.
_JusSx_ has joined #ocaml
Skal has joined #ocaml
Nutssh has quit ["Client exiting"]
_JusSx__ has joined #ocaml
_JusSx_ has quit [Read error: 110 (Connection timed out)]
Snark has joined #ocaml
<Demitar> Saulzar, you may also want to check out Equeue (the only case when it becomes a bit complicated is when you want (soft)realtime scheduling control, say a game).
cognominal has joined #ocaml
<Snark> slt
Saulzar_ has joined #ocaml
gim has joined #ocaml
Saulzar has quit [Read error: 113 (No route to host)]
_JusSx_ has joined #ocaml
_JusSx___ has joined #ocaml
_JusSx__ has quit [Read error: 113 (No route to host)]
_JusSx_ has quit [Read error: 110 (Connection timed out)]
oliver__ has joined #ocaml
_shawn has joined #ocaml
oliver__ is now known as Saulzar
_JusSx___ is now known as _JusSx_
Saulzar_ has quit [Read error: 110 (Connection timed out)]
shawn_ has quit [Read error: 110 (Connection timed out)]
* Snark searches how to express that a function will return an object that does "at least those methods..."
vodka-goo has joined #ocaml
more has joined #ocaml
Aradorn has joined #ocaml
<more> Is it inherently more difficult to program GUIs with Ocaml than with C++?
<sieni> why would that be the case except probably for lack of support for toolkit libraries?
<more> I have no facts about GUI programming in ocaml, I just know imperative languages (C++/Python) and recently got a strong feeling that functional would be better for most purposes.
<sieni> I don't know how relevant that is, since ocaml has decent support also for imperative programming
<more> Ok. I just want to gain an understanding on how easy or difficult it would be to program guis using more of a functional approach.
<more> sieni: are you using ocalm for computational physics?
<Snark> lablgtk2 is nice
<Snark> callbacks are much easier to program with a functional language
<sieni> more: No, I haven't been using ocaml at all, but am planning to. I use C and Scheme at work
<sieni> closures are coolest invention since sliced bread
<dan2> uhh no
<dan2> first class functions and type abstraction already take that spot
<more> I have been using 'buttoncmd = lambda x = y: jopo(x)' with Python Tkinter programming. This is a closure, right?
<dan2> no, its an anonymous function ;)
<Snark> hmmm... let's say I have a class foo, with a method "thing" returning a bar ; baz inherits from bar, foz inherits from foo, but in foz the "thing" method returns a baz
<Snark> ocaml doesn't seem to think it is a sane situation...
<dan2> I don't think many people use classes in ocaml at all
<dan2> I don't see any value
<Snark> inheritance?
<more> I am not a great fan of inheritance, at least as it is defined and used in C++ (with 15 years professional day-job experience), but at this stage I know nothing about inheritance in ocaml. Is it any better there?
<dan2> I've never used inheritance in ocaml
<Snark> C++ sucks at OO
<Saulzar> Why do you say that?
<more> I have not been using inheritance in C++ for the last two-three years, unless I had to due to library structures.
<Saulzar> I don't think most things require inheritance, but some types of application it fits nicely
<more> dan2: if my python example does not qualify as a closure, could you demonstrate the difference between closure and what I represented?
<Saulzar> Could you write say 'buttoncmd = lambda x = y: jopo(x) * foobar' where foobar is part of the current environment? From what I can see a closure is about capturing the current (relavant?) environment with your function...
<Saulzar> Though I could very well be wrong :)
<more> With python lambda, you can fix a couple of the parameters to form a new function with those parameters fixed
<more> >>> def jopo(a,b): return a * b
<more> >>> j = lambda x, y = 2: jopo(x, y)
<more> >>> j(9)
<more> 18
<dan2> most closures don't have function arguments
<more> You could also give a reference to an object, which would lead to a part of the current state to be later referenced by the called function.
<dan2> closures don't exist in ocaml
<dan2> ocaml has first class functions
<dan2> haskell does
<Snark> http://rafb.net/paste/results/j6PoCj48.html yields there's a problem in line 20 "This expression has type baz but is here used with type bar"
<Saulzar> Seems to me that if ocaml doesn't convert types it would also not do covariant return types for the same reason
<dan2> Snark: it appears to me you can't initialize a baz instance unless you inherit from it, or unless its in the first class
<Demitar> method thing = (new baz :> bar)
<dan2> first class meaning it is at root level, it inherits from nothing
<sieni> dan2: what's the difference? I understood that a closure is just a function + bindings of all variables in the lexical context where the function was created
<Demitar> Since method thing : bar.
<dan2> ahhhh
<Snark> the problem is I really want a baz
<dan2> method thing = (new baz :> baz)
<Demitar> Yes, well it should override the foo type imo so it's a tad odd.
<Snark> method thing: baz = new baz gives "The method thing has type baz but is expected to have type bar"
<Snark> but a baz is a bar :-/
<Demitar> Sorry. Wrong error.
* Demitar pauses his brain for a while...
<Snark> hence my previous question: how could I express that method thing from foo will return something that conforms to bar (but perhaps not bar itself)
<Saulzar> Consider the case when you have a foo (which really IS a foo)
<Snark> yes
<Snark> then 'thing' gives a bar
<Saulzar> Err, which really IS a foz :)
<dan2> Demitar: I think he needs to inherit from baz
<Snark> no
<Snark> the no was for Saulzar
<Demitar> dan2, actually I wouldn't listen to what I say right now, need to get something to eat first. :)
<Saulzar> (Was correcting my statement)
<dan2> that didn't work either
<dan2> bah
<Saulzar> Then you call thing
<Snark> ah, a foz "casted" as a foo... then thing will return a bar (really a baz, but still a bar)
<dan2> Snark: use functors for gods sake
<Snark> dan2: does it give me inheritance?
<Saulzar> It returns a baz - but ocaml doesn't convert types like that...
<dan2> no, it slashes the object system
<dan2> Snark: using functors and structures gets rid of the object systems use
<dan2> Snark: then everything is just a function like in C
<more> type inference and pattern matching are probably smarter than inheritance -- I do not see much reason to move to ocaml and then program with objects and imperative mechanism
<Saulzar> What you're looking for is covariant return types, but I doubt ocaml will do that
<dan2> ocaml is too strictly typed for covariant return types
<Saulzar> It's just a convenience (mostly)
<dan2> I've never found a need for it
<dan2> passing around structures works for me
<dan2> classes and inheritance are a headache imho
<Saulzar> When I used C I never found a use for OO either - when you have a hammer...
<dan2> but see
<dan2> ocaml isn't quite like C
<Snark> I must admit I don't know much about functors
<Saulzar> I'm not comparing them :)
<dan2> it has type abstraction, first class functions, curried functions, generic functions
<Snark> will they allow me to partially implement things?
<dan2> Snark: you'll remove your class based design if you use modules
<Saulzar> I must admit I like the way the module system works - but I think it takes some serious effort to "get" OO
<dan2> Saulzar: generic functions are the biggest benefit of ocaml: val map : ('a -> 'b) -> 'a list -> 'b list
<Saulzar> Just like I do not understand functional programming especially well just now :)
<Saulzar> Yep, I like it a lot.
<dan2> Snark: functors allow you to create a similar templates on a C++ struct
<Snark> could someone point me to some good doc how functors can do things usually done in OO?
<Snark> ok
<Saulzar> I don't think they can provide the entire spectrum of OO - but mainly encapsulation and static polymorphism
* Snark goes reading
<Saulzar> I got into this area from C++, but ocaml is god knows how much easier to do generics
<dan2> Saulzar: I know ;)
<dan2> if ocaml had a strong C++ interface
<dan2> I'd be using it for all of my work
<Saulzar> That said I take half an hour to write a small segment of Ocaml fighting the syntax which would take me 30 seconds in C++ currently :)
<dan2> ocaml has nice clean free form syntax
<dan2> hmm
<dan2> Snark: that wasn't a really good example of functors, see the manual
<Saulzar> I looked at haskell initially, haskell programmers seem to find bizzare ways of doing things.
<more> I started out with trying to learn Haskell, too. Pretty soon I thought that I must have something different and here I am, trying to learn ocaml.
<more> dan2: where do you prefer C++ over ocaml?
<Saulzar> I think it is less bewildering, haskell I just couldn'd fathom how to do certain things... Maybe it makes sense after a time
<dan2> I don't, but I have to use it to do a lot of the work I do
<more> Is it a closure, if one is able to carry a function using a reference?
<more> basically, who needs to be able to gain a get/set access to the variables within the closure -- for the closure to be closure?
<Saulzar> I think it's about capturing the environment... ie. let x = 3 in let func = (fun () -> x + 4) ... do something with func
<Saulzar> So then you could pass that function somewhere and it would work (using x) even far away from the source
<dan2> closures are executable code blocks
<dan2> it'd be stupid to use closures in ocaml because it has first class functions and anonymous functions
<Saulzar> The book "developing applications with ocaml" gives a definition here http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora015.html
<dan2> Saulzar: I love functors because they're ocaml's way of bringing all the good parts of templates without the nasty syntax
<Saulzar> Or rather gives an explanation ... I'm not arguing that ocaml does have closures but it basically states that all functions are closures?
<Saulzar> Which seems to make sense to me in the way I've seen the word used...
<Saulzar> dan2, Yeah - all the typing really gets to you
<Saulzar> Though the name 'functor' seems a little strange, given it's use elsewhere
<dan2> templates are the best thing C++ has to offer
<more> If the url you shared with us is right, then my Python example (using currying and anonymous functions) should also qualify as closures?
<dan2> closures don't usually have function arguments
<dan2> so, function () -> x + 4
<Saulzar> It's similar - it's just more 'automatic'
<dan2> is a closure really
<more> ok.
<dan2> then here's an IntOrderedType
<more> dan2, I really like templates, but C++ template implementations are sometimes a bit costly in machine code size.
<dan2> module IntOrderedType =
<dan2> struct
<dan2> type t = int
<dan2> let compare (a:int) (b:int) = if a = b then Equal else if a < b then Less else Greater
<dan2> end;;
<dan2> module IntOrderedType :
<Saulzar> Ah, I guess that makes sense
<dan2> more: if size matters, you shouldn't be using C++
<Saulzar> But why not just call it a parameterised module? They allow a class to be parameterised too
<dan2> because functors _instantiate_
<dan2> they're almost exactly like templates in C++ iirc
<Snark> hmmm... I don't really see how functors will help me :-/
<Saulzar> Hmm, I see. Where as classes only instanciate when you create them.
<dan2> right
<more> functors will lead to faster code?
<Saulzar> But you could put global runnable code in a functor? Not that that would be a good idea ;)
<dan2> functors do add typing to generic methods
<dan2> s/do//
<Saulzar> Is ocaml better in that respect (code size)?
<dan2> ocaml has a pretty small footprint
<dan2> and threading is a beauty
<dan2> Saulzar: since if you don't use the class system, most things are immutable types... threading is soooooo easy
<more> parallelisation possibilities are inherently better in functional languages
<dan2> more: its all about immutable types
<Saulzar> Though I read earlier that ocaml doesn't actually allow threads for paralell execution
<dan2> Saulzar: thats not true
<dan2> Saulzar: it has very good threading facilities
<Saulzar> Are you sure? let me find the mail... it states that for various reasons (threaded GC being the main one) that ocaml threads are userspace threads only
<dan2> thats bullshit
<dan2> you can use native thread
<dan2> just put -thread when compiling
<dan2> uses native threads by default then
<pango> but afaik GC is protected by a big lock
<more> Still, the main stream parallelisation is done with MPI in the C/Fortran/C++ world. Do MPI and Ocaml fit together nicely or is it still a works-in-progress?
<Saulzar> Apparently it uses a mutex to explicitly stop 2 threads running at once
<dan2> pango: are you serious?
<Saulzar> Here
<dan2> hmm
<dan2> what if the code is entirely immutable
<dan2> there is no need for a garbage collector to be running
<pango> still, given the high allocation rate of ML languages, that's a problem...
<Saulzar> Er, you still manipulate structures
<more> dan2: there were two separate issues in that url, one about eval and another about gc; the code is immutable, but the data is not, and it seems that the GC for ocaml data is not thread safe
<dan2> hmmm
<dan2> ocaml gc should be fixed
<dan2> even boehm gc is somewhat threadsafe
<dan2> heh
<dan2> java doesn't have this issue and ocaml is even less oriented to memory
<pango> given that Xavier Leroy is both ocaml's main father, and behind Linux threads implementation, there must be good reasons it's the way it is
<dan2> or a bad design
<pango> probably not
<pango> just too high cost for common case, or something
<more> I suppose Leroy's thread implementation is Linux has been replaced with something else.
<Saulzar> hmm, sleep time - nice talking.
<dan2> pango: or he needs someone better at designing threadsafe garbage collectors and memory mangement
<dan2> management
<pango> ocaml memory management is the result of many years of research, but in some aspects looks like a simplified version of some previous versions
<pango> so it's probably a design choice
pango is now known as pangoaway
<dan2> pango: but, if the data is immutable, then the garbage collector shouldn't be getting called anyway
<dan2> pangoaway: the design choicce is going to be a bad one because welcome to dual-core world
<more> Even in Microsoft Visual C++, multiple threads cannot allocate memory simultaneously, but there is a semaphore locking the other threads gaining access to memory allocation.
<dan2> thats OS dependant probably
<dan2> on linux malloc is threadsafe
<more> Microsoft malloc per se is threadsafe, but threadsafety is implemented by locking other threads.
<dan2> ugh
<dan2> linux malloc is extremely fast because the kernel tries to analyze where to send VM
<more> There are other mallocs (like microquill smartheap) that allow parallel allocations on M$ platforms
<dan2> they just pool memory and redistribute
<more> According to my experience, linux memory management seems to be much more efficient.
dvanhorn has quit [Remote closed the connection]
<dan2> more: if you look into the design of the vm architechture, you'd understand why
<dan2> more: and on linux, it really pools memory without you knowing ;)
<dan2> i.e.
<dan2> when you free() it gets thrown right back in the vm
<more> that's impressive.
<dan2> which essentially makes free() a much cheaper call
<dan2> more: I've never developed software on windows, I don't want to start now ;)
<dan2> NPTL is linux's new amazing threads
<dan2> there were some benchmarks, but it was extremely fast
<dan2> and it doesn't have the VM allocation issues because it does on-demand paging
<more> dan2: I am an old-time Unix programmer, who got converted to being a Windows programmer 12 years ago, and ever since I have wanted to come back, but failed. ;-)
<dan2> more: I've pretty much moved most of my development to java
<dan2> more: lots of libraries, portability, strong userbase, relatively good threading (as of Java5), good business development architechture (J2EE)
<more> dan2: I have only written some J2ME code. Not a great experience.
<dan2> I didn't say I liked java
<dan2> but it is usable
<more> do you know if it is a good idea to do bit nibbling in ocaml?
<dan2> bitshifts?
<dan2> I still haven't figured out how ;)
<more> is there a native 64-bit integer in ocaml on 64-bit platforms?
<dan2> probably
<dan2> tho there wouldn't be a 128bit int setup
<more> There seems to be something called 'Int64' module, which provides bit shifts, too
<dan2> haven't tried it
<dan2> more: the Int32 lib lets you do bitshifts
<dan2> it is kind of weird to use Int32 lib tho
<more> why?
<dan2> look at the interface
<dan2> you'd have to do
<dan2> Int32.add (Int32.of_int 5) (Int32.of_int 4)
<more> How do you start defining a variable being of type Int32 ?
<dan2> you mean int32
<more> yep
<dan2> let a = Int32.of_int <insert number here>
<more> great
<dan2> but heres what I'd do
<dan2> we're on a 32bit platform
<dan2> let (>>) x y = Int32.to_int(Int32.shift_right (Int32.of_int x) y);;
<more> It seem you can do "777l" (the last char is a letter l)
<dan2> in ocaml operator creation is simple
<dan2> so I just wrap the shift and logical operations to standard operators
<more> Yep, there is no need to readily pollute the operator name space for some wierd bit operators that nobody is going to use anyway ;-)
<dan2> thats one of my favorite things of ocaml
<dan2> easy operator creation
<dan2> it really doesn't get any simpler than that
<more> Can I assume, that the code complies to somewhat optimized code, if I use these kinds of operations heavily?
<more> (bit shifts etc.)
<dan2> I'm not sure
<more> ok, I will try it out.
<dan2> since I have a feeling that of_int and to_int operations are just typecasts
<dan2> yes
<dan2> and remember
<dan2> in ocaml you're only really able to use 31 bytes of an integer
<more> btw, 99l gives an int32, whereas 99L gives an int64
<more> that does not apply to the int32?
<dan2> hmm
<dan2> I'm not sure
<dan2> int32 is a typecast on 32bit platforms
<dan2> thats for sure
<dan2> but ocaml always uses the last bit
<dan2> so you're limited to 31 bit integers
<dan2> probably 30 bit if its signed like I think it is
<more> # 2000000000l;;
<more> - : int32 = 2000000000l
<more> # 3000000000l;;
<more> Integer literal exceeds the range of representable integers of type int32
<more> int32 is really int32, not int31
<dan2> hmm
<dan2> ok
<dan2> regular ints are int 31
<more> that's a bit strange.
<Demitar> to_int and of_int are in this case stupid. :) Look at Pervasives.lsl/lsr/asr
<more> they must have really needed that bit a lot for some purpose.
<Demitar> One reason only: Speed. It allows ints to be handled unboxed (without messing with the garbage collector).
<more> A bit like those old time 36 bit computers, with a couple of type bits...
<dan2> Demitar: wasn't a bit of ocaml developed before 32bit platforms were mainstream
<Demitar> dan2, perhaps, but what difference would that make in the end?
<dan2> they like keeping old crap working
<Demitar> Remember that int is 63bits on 64bit platforms.
<dan2> heh
* dan2 looks at list operations
<dan2> the biggest issue with ocaml lists is that they aren't doubly linked
<dan2> it takes O(n) time to get the tail of a list
<Demitar> a) is that really that a big issue b) use one of the doubly linked list implementations (extlib perhaps?)
<vodka-goo> you can find some double linked list modules
<vodka-goo> i made one (savonet.sf.net) but maybe in that super-stdlib (don't remember the name)
<vodka-goo> extlib:)
<dan2> I wonder why the stdlib worries about '@' being non tail recursive
<dan2> its a constant operation
<dan2> readjusting 2 pointers usually
<Demitar> It's not constant, singly linked list, remember?
<Demitar> (And immutable.)
<dan2> oh bah
<dan2> which means it makes a whole copy of the new list doesn't it
<more> Demitar: if normal ints are 31/63 bits for speed, does it mean that int32/int64 are slower? does this apply to arrays of int32/int64?
<Demitar> Yes.
<Demitar> floats are unboxed in arrays however.
<more> But int32/int64 are boxed in arrays??
<Demitar> As far as I know, yes.
<Demitar> more, what conclusions do you draw from that message?
<more> X. Leroy states that in32, int64 are unboxed intra-function (whatever it means), and claims that a global unboxing is too expensive for GC?
<more> BTW, it is my first time in IRC for about 10 years ... how do you send private messages with this X-Chat? or what client should I be using?
<Demitar> /msg <nick> ...
Msandin has joined #ocaml
<more> Demitar: ahh, that has not changed during the years... this is exactly the same as in the first client.
<Demitar> (Or you can right-click the nick and select the bottom option (whatever it reads in english).)
<more> (not me!)
<dan2> I usually use /querry <nick>
<dan2> /query
<more> X. Leroy claims that monomorphisation does not appear viable in ocaml due to modules (and functors)? Could someone elaborate on this subject?
<more> (in the compilation of ocaml)
<more> Is there a command to inspect the scope in the interactive mode? like dir() in Python?
maml has quit ["Leaving"]
<dan2> no
<dan2> well
<dan2> you can have some fun with the module keyword
<dan2> hmm
<dan2> module Unix = Unix;; for exampl
<dan2> more: but not really int that sense
<dan2> in
<dan2> more: programming in ocaml is based on the fact that you understand everything that is going on
<dan2> more: if you don't understand everything that is going on, join the OO bandwagon ;)
<dan2> OO has been around for decades
<dan2> and nobody completely understands it
<dan2> which is terrible
<dan2> OO needs to be ditched
<more> Thanks dan2, I did not have the Unix module, but module Int32 = Int32;; worked for me
<dan2> to get the Unix module
<dan2> #load "unix.cma";;
<Demitar> OO has the advantage of duck-typing and actually groups data and code together in an acceptable way.
<more> I agree, OO creates more problems than solutions, especially in the hands of junior programmers with a great belief in simplistic "Cat derives from an Animal" solutions
<dan2> Demitar: but now that we're moving closer and closer to multiprocessor machines, it all breaks
<more> Still, compile time monomorphism is a simple way to get exterme performance - with the cost of the executable size, of course
<dan2> OO was never made to work properly with threads
<dan2> functional and imperative style programming was just acceptable
<more> dan2: the only way to benefit really from the multiprosessing at the moment is MPI
<Demitar> dan2, the larger problem is usually the ability to express things efficiently and not so much raw performance.
<more> the SMP model breaks down as soon as there are 16 or more processors, the memory bandwidth is a problem and the crossbar latencies become too high
<more> that will lead to a NUMA type of HW, which is not that compatible with threading, but benefits more from separate processes.
<more> there, something like the MPI is a nice solution.
<dan2> you mean more hardware like the power5
<dan2> software running on power5 is insane
<dan2> more: we're not going that way, people think more processors == better
<more> dan2: Power5 is just one processor from IBM? I mean that after the first phases of multi core wave, we will end up having 128 processors and more. At that stage, threading is no longer the best programming model, but we need something more expressive and.
<dan2> threading is important because it allows the ability to combine multiple processing attributes into a single application
<more> ... and MPI is a model that is compatible with hardware scaling.
<more> threading is a non-scalable solution, it breaks down when we move into NUMA, which is the second wave in multi-core, multi-chip processors.
<dan2> heh
<more> I am serious.
<more> ;-)
<dan2> they'll make it work
<more> I will "work", but will not get you the best performance.
<dan2> you'd be surprised how useless more cpu power is
<dan2> parrallelization helps make program design simpler
<dan2> most applications are I/O bound
<dan2> (at least they should be)
<mflux_> dan2, for write-bound problems you can always use the CPU with compression ;)
<more> I agree. Much of the complexity in apps is for speed optimization, which could have been partially avoided by parallelization.
<more> I am using in-memory compression for some volumetric grids.
<Demitar> I wonder how much a compiler could automagically thread applications properly using control inversion.
<mflux_> wasn't there some parallel haskell variant that would implicitly parallelize the code? or maybe I've been dreaming, I couldn't find it last time I looked around ;)
<more> ;-)
<more> glaskow parallel haskell?
<more> s/glaskow/glasgow
<mflux_> it didn't require using par(/seq)?
<more> It seems to be using PVM, hinting that it has not been maintained. Nowadays, everyone in HPC is using MPI.
<mflux_> is mpi somehow nicer/more efficient?
<more> Yep, GHC is not an automatic system, but just adds par/seq
<more> s/GHC/GPH
<more> It seems that I can also do "module Pervasives = Pervasives;;"
<mflux_> what does that give you?
<more> It lists the Pervasives symbols (in interactive mode)
<more> Why are some of the symbols starting with %?
<Demitar> IIRC they are optimized in the native compiler.
<more> Is it possible to create infinite sequences, like in haskell [1..]?
<more> (of course it is possible, but how easy is it?)
<mflux_> more, use streams
<mflux_> more, they don't offer backtracking though
<Demitar> You may need to use camlp4...
<mflux_> but otherwise they are very cool
<dan2> more: labels
<mflux_> more cool stuff you mean?-)
pango_ has joined #ocaml
pangoaway has quit [Read error: 60 (Operation timed out)]
Msandin has quit [Read error: 60 (Operation timed out)]
vezenchio has joined #ocaml
pango_ is now known as pango
Smerdyakov has joined #ocaml
Smerdyakov has quit [Client Quit]
Submarine has joined #ocaml
<pango> dan2: lists are single linked because they're immutable. (are there efficient implementations of immutabe double linked lists ?)
<dan2> good question I don't know
Smerdyakov has joined #ocaml
<dan2> well, a double linked list loses value when its immutable
<pango> but they lose interesting properties by not being immutable
<mflux_> well, it depends what you're using them for
<dan2> I mean
<mflux_> and there are some tricks too. like constructing the list while you're traversing it.
<dan2> if I have two double linked lists, I want to be able to splice them
Submarine has quit ["Leaving"]
<mflux_> hmm
<mflux_> one after another?
<mflux_> while iterating, at some point simply switch to the other?
<more> In haskell, you can define recursive lists, just because they are single-linked.
Amorphous has joined #ocaml
<mflux_> so you could have something like type 'a dllist = Simple of ('a list * 'a list) | Concat of ('a dllist * 'a dllist) or something. but it really depends what operations you want to do with it..
<pango> immutable/double linked/fast. pick 2
<mflux_> inspiration can be sought on after the 'fifo with immutable lists' algorithm..
<mflux_> which still is O(1) (amortized)
vodka-goo has quit [Read error: 110 (Connection timed out)]
<dan2> hmm
<dan2> how do I make a recursive sequence
<dan2> doesn't like this
<dan2> et rec fib = 0 :: 1 :: 1 :: [List.hd(tail fib) + List.hd(tail2 fib)];;
<dan2> let
<dan2> or even
<dan2> let rec fib = 0 :: 1 :: 1 :: (List.nth fib ((List.length fib) - 1)) + (List.nth fib ((List.length fib) - 2));;
<mflux_> you wouldn't want to do that anyway, as that would be an infinite list, and in an eager language like ocaml would cause the heap to be exhausted?
<mflux_> I think it needs to be a function in that case
<mflux_> the infinite list hack (let rec a = 0 : a) is just that, a hack ;)
<mflux_> so, let rec fib () = 0 :: .. (List.hd (tail (fib ()) ..
<mflux_> as you may imagine, it would be horribly slow
<dan2> oh but I know
<dan2> ;)
<dan2> haskell has the lazy evaluate sequences tho
<mflux_> hmm, but how about streams
<mflux_> or is your example rotten in some other aspects ;)
<more> isn't haskell defined as non-strict rather than 'lazy', leading to possibilities in infinite loops depending on implementation?
Aradorn has quit ["( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )"]
<dan2> no, haskell is very lazy
<mflux_> I believe that that is atleast partially true, in that laziness is just one way of implementing a non-strict language
<mflux_> or was it vice versa?-)
<mflux_> there is 'eager haskell' too, but I'm not sure how that works
<mflux_> I would imagine it would still have the capability to handle for example infinite lists
<mflux_> so it would be eager only to a point
<mflux_> I've also heard of some approaches that would only make the programs 'more eager', to be more efficient.. I don't know any names for such projects though
<mflux_> ok, so: "In order to cope with this problem, Eager Haskell uses resource-bounded execution. The system tracks the resource usage as a computation unfolds. If resource demands get too high (for example because we are unfolding an infinite data structure as shown above) then we fall back to lazy execution."
<mflux_> (this problem = folding infinite data structures)
<mflux_> hm, not folding, but something else ;)
<more> If I am not completely wrong, you can define something like the following in haskell:
<more> a = 1 : a
<more> which is implemented as 1, which the next pointer pointing to the first element
<mflux_> this works in ocaml too: let rec a = 1 :: a
<more> or, a = 1:b:c, where b=2:c, c=77:b
<more> and that is implemented as a recursive structure?
<mflux_> hm, do you think that works with plain pointers?
<mflux_> I don't think that can be written as neatly with ocaml anymore
<more> that's how it is usually represented (pointers)
<more> (in power point presentations that is .. I have never checked what is the real implementation...)
<more> how do you slice ocaml lists? like in python you can do a[2..5] to get a new array ranging from 3rd to 5th element, or use 'take 7' to take 7 first elements in haskell... ?
<pango> as you said those aren't lists, but arrays
<pango> if you want to do that efficiently use arrays
<more> ok. but is there a 'take n' in ocaml?
<pango> with arrays ?
<mflux_> you can check the List module for such functions, but I don't think so
<more> with lists, like in haskell
<mflux_> atleast I've written my own take-funktion
<mflux_> and takeWhile, drop, dropWhile..
<mflux_> and zip, and zipWith (List.combine requires both lists to be the same length)
<pango> more: it's not a 'simple' operation on lists, but it's not easy to define it
<mflux_> you mean hard?-)
<pango> uuuh yes
<mflux_> and then it's useful to have a function for converting a string to a list and vice versa
<more> thanks guys. this helps me a lot.
<more> like string.split in python?
<pango> but if you use such operator with lists, you may get O(sqr n) algo when you think you expect an O(n) algo
<mflux_> while you're at it you (looking at haskell style) you might want to define let (@@) a b = a b and let (@.) a b c = a (b c) ;)
<pango> you think you expect... damn heat
<pango> ;)
<pango> more: too keep it short, take isn't a O(1) operation on lists
<mflux_> but still sometimes useful
<pango> it's just a warning :)
<mflux_> in any case, if it isn't fast enough, you'll propably notice ;)
<mflux_> so learn now, worry later ;)
<more> basically, if lists are immutable, take n should just return a function, that generates the elements without copying the list?
<mflux_> not really, in ocamls lists are really lists, not computation thunks
<mflux_> but you could use streams..
<more> ok, so this is why haskell has take n, but ocaml does not have it.
<mflux_> which are basically type 'a stream = Stream (unit -> 'a * 'a stream) | End
<mflux_> (I hope I'm not lying a lot)
<dan2> pango: sqr?
bk_ has joined #ocaml
<dan2> or do you mean n^2
<pango> yes
_JusSx__ has joined #ocaml
Smerdyakov has quit [Read error: 60 (Operation timed out)]
Aradorn has joined #ocaml
_JusSx_ has quit [Read error: 110 (Connection timed out)]
Nutssh has joined #ocaml
Smerdyakov has joined #ocaml
Aradorn has quit ["( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )"]
_JusSx_ has joined #ocaml
Aradorn has joined #ocaml
Msandin has joined #ocaml
_JusSx__ has quit [Read error: 110 (Connection timed out)]
Msandin has quit ["Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"]
araujo has quit ["Programs must be written for people to read, and only incidentally for machines to execute"]
araujo has joined #ocaml
Smerdyakov has quit [Read error: 54 (Connection reset by peer)]
Snark has quit ["Leaving"]
Smerdyakov has joined #ocaml
<ulfdoz_> bye
pattern_ has quit ["..."]
Nutssh has quit ["Client exiting"]
Smerdyakov has quit [Read error: 131 (Connection reset by peer)]
Smerdyakov has joined #ocaml
cmeme has quit [Read error: 104 (Connection reset by peer)]
cmeme has joined #ocaml
cmeme has quit [Remote closed the connection]
cmeme has joined #ocaml
pattern_ has joined #ocaml
mlh_ has joined #ocaml
vezenchio has quit [Read error: 110 (Connection timed out)]
mfurr has joined #ocaml
cognominal_ has joined #ocaml
cognominal_ has quit [Remote closed the connection]
cognominal has quit [Read error: 110 (Connection timed out)]
cognominal has joined #ocaml
_JusSx_ has quit ["leaving"]
joeytwiddle has joined #ocaml