<mflux_>
dan2, yeah, but stuff still isn't released immediately after you're done with them, and if you have multiple processes all running gc's of their own - although maybe in such low memory situations it would be better to use threads
<mflux_>
is PPC a supported platform?
<mflux_>
for native building
<TeXitoi>
yes
<mflux_>
does it give any memory savings? one could even expect bytecode version would require less resources
<dan2>
mflux_: surely enough, he could just reduce the runtime to what he needs no?
<pango_>
looking at channel logs, I'd say march
<mflux_>
dan2, yes, that will help a lot
<dan2>
theres probably not much involved in taking stuff out of the runtime
<dan2>
ocaml needs more libraries... it needs to advertise more to the general public
<dan2>
ocaml seriously is a very decent language
<ulfdoz_>
Is the runtime linked in static or shared into the native code?
<dan2>
static I'm sure
<ulfdoz_>
One could save additional memory by linking it shared, so that you avoid to load the runtime more than once, when running several apps.
<dan2>
right
<ulfdoz_>
Unfortunately even linux does not seem to be that smart.
<dan2>
if you compile -fPIC
<dan2>
it does
<dan2>
but PIC code is much slower
dm has quit ["Leaving"]
<mflux_>
then there is that ocaml libraries cannot be shared if you generate binaries
<mflux_>
so in embedded platforms you want to use bytecode (and use ocaml for linking) or use a single binary that does everything?
<dan2>
or create an ocaml runtime loader thingy
* Demitar
seems to remember this discussion from the mailing list... several times. ;-)
cjohnson has quit [Read error: 110 (Connection timed out)]
cjohnson has joined #ocaml
xidaux has joined #ocaml
xidaux is now known as DeadNigger
* DeadNigger
plays Aphex_Twin_-_Drukqs_Mix_(Mixed_by_ThinkToy)_192k.mp3
cjohnson has quit [""We live like penguins in the desert...""]
BleSS has left #ocaml []
DeadNigger is now known as dodecahedron
Purice has joined #ocaml
Purice has quit [Read error: 104 (Connection reset by peer)]
cognominal has quit ["Leaving"]
cognominal has joined #ocaml
cognominal has quit [Client Quit]
cognominal has joined #ocaml
cognominal has quit [Client Quit]
cognominal has joined #ocaml
dodecahedron has quit ["leaving"]
Msandin has quit [Read error: 110 (Connection timed out)]
vezenchio has joined #ocaml
pango__ has joined #ocaml
pango_ has quit [Read error: 60 (Operation timed out)]
pango__ is now known as pango
Boojum has joined #ocaml
Snark has quit [Read error: 60 (Operation timed out)]
Skal has joined #ocaml
Boojum is now known as Snark
mattam has quit [Read error: 104 (Connection reset by peer)]
mattam has joined #ocaml
Smerdyakov has joined #ocaml
Herrchen is now known as Herrchen_
senko has joined #ocaml
bk_ has quit ["Leaving IRC - dircproxy 1.1.0"]
<senko>
hi, is there a way to test if there is something to read in an in_channel?
<Smerdyakov>
I suggest using the Event module of the threads library instead, with threads sending channel input to channels.
<Smerdyakov>
Then you can use nice select's instead of manual polling.
<senko>
ok...
<senko>
found Unix.set_nonblock
<Smerdyakov>
I mean, sending file channel input to Event channels.
<Smerdyakov>
Yeah, but Concurrent ML style is just nicer in general. Who wants to use Unix unnecessarily? :)
<senko>
agree :)
cognominal has quit [Remote closed the connection]
cognominal has joined #ocaml
<mflux_>
besides select wouldn't be of much use with channels that are read-buffered
<Smerdyakov>
How do you mean?
<mflux_>
say you select on a buffer, use a buffered read which reads everything from it when you've requested only one character..
<Smerdyakov>
So?
<mflux_>
so select will report there's no new input arriving
<mflux_>
while the buffers would contain some
<mflux_>
Unix.select that is
<mflux_>
I don't remember if there's a peek operation for in_channels though, it would solve that problem
<Smerdyakov>
I'm talking about Event.select.
<mflux_>
yeah, I was talking about the original problem
<senko>
yes, that was the problem i had...
<mflux_>
if you want to use select, don't use buffered input
<senko>
i want to use a hypothetical peek function :)
<mflux_>
you could just implement buffers yourself
<mflux_>
with some neat framework set up you can bind all the code running around select nicely (using continuation passing style) - much more convenient than the traditional C-program running in a select loop
<Smerdyakov>
mflux_, you don't like my CML suggestion?
<mflux_>
no, it's ok
<mflux_>
well.. it's difficult to stop a thread doing 'read' on something
<Smerdyakov>
So?
<mflux_>
so that's something that can be more easily handled with Unix.select
<mflux_>
but the concurrent ml synchronization/message passing primitives are great
<Smerdyakov>
It's no problem if you have a thread per buffered channel.
<mflux_>
and their lifetime is as long as the descriptor's?
<Smerdyakov>
Surely you know how to write a function to do that.
<dan2>
I know
<eyda|mon>
nm :P
<dan2>
Smerdyakov: its kinda crappy that ocaml lists only let you get it by going through the list
<Smerdyakov>
dan2, that follows from how list is defined.
<TeXitoi>
dan2: list is like that
<TeXitoi>
try queue
Skal has quit ["Client exiting"]
<Smerdyakov>
dan2, you can define your own data type that supports some operations more efficiently.
<eyda|mon>
ok, so I just posted my sumlista function, but it's actually giving me a list in the reverse order than what I had wanted... short of just using List.rev, how could I have written it to give it to me the right way around the first time?
<TeXitoi>
List.rev is the good answer, or use non terminal recursive function
<eyda|mon>
so is List.rev the common solution? or is the non terminal recursive?
<eyda|mon>
I'm not sure what the non-terminal rec function would look like
<TeXitoi>
List.rev the common solution
<eyda|mon>
do you have an example?
<TeXitoi>
a think as:
<TeXitoi>
| x::xs -> (x * cur) :: (sumlista ...)
<eyda|mon>
good thing i'm actually operating on the list twice, so I don't even need to do the List.rev, I guess it gets straightened out on it's own :)
<eyda|mon>
oh
<eyda|mon>
thnks
<TeXitoi>
but terminal recursion is better
<eyda|mon>
faster?
<TeXitoi>
better for memory
<Smerdyakov>
There's no fundamental reason what TeXitoi just suggested isn't a good idea, but the ocaml compiler will give you problems if you use that strategy on large lists.
<eyda|mon>
Smerdyakov: you refer to List.rev ?
<Smerdyakov>
The area of memory used to store the call stack is separate and smaller than the area used for everything else.
<Smerdyakov>
eydaimon, no, you SHOULD use rev.
<eyda|mon>
ah, perfect
<eyda|mon>
I was worrying about interesting through the list again would be more expensive than just putting it in the correct order to begin with
<pango>
eyda|mon: getting alternative factors could be achieved differently...
<eyda|mon>
pango: please suggest
<pango>
eyda|mon: handling list members in pairs, or use two reciprocal recursive functions
<eyda|mon>
i have a hard time seeing a solution using either of those. still a neophyte I'm afraid
<pango>
do you always want 2x factor for the first list member ?
<eyda|mon>
yes
<pango>
(mmmh well actually no, you start with 1x)
<eyda|mon>
I noticed that later. it should be sumlista a [] 1;;
<eyda|mon>
(so I do start with 2)
<pango>
# let rec sumlista intlist res =
<pango>
match intlist with
<pango>
| [] -> List.rev res
<pango>
| [x] -> List.rev (x*2 :: res)
<pango>
| x :: y :: q -> sumlista q (y :: 2*x :: res) ;;
<eyda|mon>
pretty clever
<eyda|mon>
basically you're not doing anything to the thing that
<eyda|mon>
is multiplied by 1 because you don't need to, correct?
<pango>
it's specialization. There's only two cases, each one can be optimized, and they occur at known times, and that can be optimized too
<eyda|mon>
so you're not using the option of handling in pairs nor two reciprocal recursive funcs, because it's specialized
<eyda|mon>
but it's clever because it's specialized :)
<pango>
above code handles list in pairs... hence x :: y :: q to get the two first elements
<eyda|mon>
ah, you could have done y*3 if I was alternatving between 2 and 3 instead of 2 and 1
<eyda|mon>
ok, got it
<eyda|mon>
silly to overlook that
<pango>
the [x] case only happens for odd numbered lists
<eyda|mon>
then I thought I understood it and I don't. why does [x] match odd number and not even?
<eyda|mon>
I thought it only matched a list with one member
<pango>
sure, the last member of list with a odd number of elements
<pango>
s/a/an/
<eyda|mon>
well, if a list only contains one member, it's odd by definition... but would [x] match [1;2;3] which is also odd?
<pango>
no, upon first call, [1;2;3] would match x :: y :: q, with x = 1, y = 2, q = [3]
<pango>
[x] will match [3] on first recursive call
<eyda|mon>
ok, good, then I got it
<eyda|mon>
thnks much
mlh_ has joined #ocaml
Smerdyakov has quit ["I'm gone!"]
<pango>
for completeness :
<pango>
# let rec sumlista2 intlist res = match intlist with
<pango>
| [] -> List.rev res
<pango>
| x :: xs -> sumlista1 xs (x*2 :: res)
<pango>
and sumlista1 intlist res = match intlist with
<pango>
| [] -> List.rev res
<pango>
| x :: xs -> sumlista2 xs (x :: res) ;;
__DL__ has left #ocaml []
Msandin has quit [Read error: 60 (Operation timed out)]
<eyda|mon>
and there the two reciprocal recursives
<eyda|mon>
now will ocaml be able to optimize that as if it was a regular recursive function?
Gueben has quit ["plouf"]
<eyda|mon>
regular tail recursive i should say
<pango>
just as much... ocamlopt does very little optimization anyway
<pango>
only some inlining afaik
vodka-goo has quit [Read error: 60 (Operation timed out)]
vodka-goo has joined #ocaml
gim has quit [Read error: 110 (Connection timed out)]