<flux>
are you targetting an embedded platform or otherwise very concerned about memory usage?
<shant>
yea i'm concerned about usage
<flux>
but perhaps for other reasons
<flux>
(the bug)
<shant>
and whether or not it grows over time
<flux>
well, it will grow, but Gc will keep the size limited
<flux>
including compaction to avoid fragmentation
<shant>
so what does Gc.major() do?
<flux>
do you btw use a 64-bit platform?
<shant>
yes i do use 64bits
<flux>
the heap map might take an appreciable amount of that 1MB
<flux>
which ocaml version?
<shant>
3.11
<shant>
it is the heap.... i think
<flux>
oh well, I was thinking upgrading to 3.11 might reduce the amount, but perhaps not then
<flux>
actually Gc.full_major () was what I meant, it will collect all currently unreachable blocks
<flux>
actually2 Gc.compact () is even better (but lengthier) operation for that
Submarine has quit [Client Quit]
<shant>
hmm i'll install a callback to those functions
<shant>
and call them
<shant>
and see what happens
tmaedaZ is now known as tmaeda
tonyIII has quit [Read error: 145 (Connection timed out)]
tonyIII has joined #ocaml
<shant>
nope no good
Alpounet has joined #ocaml
ttamttam has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
verte has quit ["Lost terminal"]
_zack has joined #ocaml
onigiri has quit []
julm_ has joined #ocaml
<mfp>
flux, shant: isn't the size of the minor + major heap around 1MB?
<mfp>
OCAMLRUNPARAM=v=52 ./nothing
<mfp>
Initial minor heap size: 256k bytes
<mfp>
Initial major heap size: 992k bytes
julm has quit [Read error: 60 (Operation timed out)]
komar_ has quit [Read error: 60 (Operation timed out)]
komar_ has joined #ocaml
ikaros has joined #ocaml
infoe has quit [Read error: 110 (Connection timed out)]
<myst>
again, maybe I am stupid, but I just can't get why 'e :: list' is many times faster than 'list @ [a]'.
albacker has joined #ocaml
<gildor>
myst: OCaml lists are single-linked list, to find end of the list you need to go through it
<mfp>
myst: e :: list only allocates 1 block in mem corresponding to Cons (e, list)
<gildor>
myst: and in the case of 'list @ [a]' you need to traverse it and then rebuild it (at least 2 * n operations)
<myst>
okay
<gildor>
myst: where in 'e :: lst', you just need to know the head of the least and allocate 1 block
<mfp>
list @ [a] -> say list = [x1; x2; x3], it allocates Cons (x3; [a]), followed by Cons (x2; Cons (x3, [a]), and finally Cons(x1, Cons (x2, Cons(x3, [a])))
<gildor>
least -> list
<gildor>
myst: e :: lst take 1 operation (wrt to lst @ [a])
<myst>
okay
<myst>
thanks for the details
<thelema>
to compare @ with ::, I just think about the immutability of ocaml lists - how to create the combined list without modifying either input.
tonyIII has quit [Read error: 60 (Operation timed out)]
<thelema>
and the only answer is to traverse arg1 and prepend its elements to arg2 in reverse order
<myst>
btw, I need to generate s list of all products of 3-digit numbers. I am doing it this way: http://codepad.org/AaZXiVq4 Is it lame way? Is there bettwer/more nice way to do it?
<thelema>
tail to head
tonyIII has joined #ocaml
<thelema>
well, if you don't want duplicates in your list, use sets
<myst>
this code is inside List.filter <p> (<the_code>)
<myst>
I don't care about dups, I care about efficiency
<thelema>
the way you're doing it shouldn't produce duplicates
<thelema>
do you want a sorted list at the end?
<myst>
no
<thelema>
then you've got it.
<myst>
I just want exactly what the_code does
<myst>
but it's way too ugly after [x * y | x <- [1 .. 999], y <- [x .. 999]]
<thelema>
of course you could rewrite with recursion, but that would just make it harder to read
<flux>
myst, well, there's pa_comprehension around
<thelema>
You could do it that way, but it'd boil down to the for loop solution, and would be slowe
<thelema>
r
<flux>
you could write a function like: let rec foldl_range f v low high = if low < high the v else foldl_range f (f v low) high
<flux>
and build your operation around that
<flux>
but the current code is already quite easy to read
<myst>
okay, so what I've used isn't "you did it wrong"?
<flux>
atleast I don't mind :)
mihamina has joined #ocaml
<myst>
but I do :)
<thelema>
myst: then use pa_comprehension
<myst>
I'll check it
<thelema>
myst: do you program in python a lot?
<kaustuv>
ocaml doesn't have stream fusion, so make sure you really want a 999 * 999 element list
<myst>
thelema, not a lot but regularly
<thelema>
kaustuv: note j = i to 999
<kaustuv>
it's still quadratic
<thelema>
kaustuv: yes, it just doesn't have dups
<myst>
in this prog I don't care about size, I'm just solving Project Euler problems :-)
<thelema>
kaustuv: if it were i = 1 to 999 then that would matter
<myst>
I'm more concerned about elegance, then efficiency, then all else.
ikaros has quit [Read error: 110 (Connection timed out)]
<thelema>
myst: if batteries' Enum had a product function, you could do it reasonably elegantly
<thelema>
you'd have dups, though
<myst>
using bloated uber-libs is inelegant
<myst>
don't mind, 't was IMHO
<thelema>
Enum = bloated?
<thelema>
Enum is kinda fundamental
<myst>
batteries - bloated
<kaustuv>
myst: your priorities are all wrong. You should order them as correctness, then efficiency, then elegance
<kaustuv>
And elegance is often code for "clever", which is a bad idea when writing code that someone must maintain
<thelema>
myst: because the linking problems?
<myst>
kaustuv, often, but this is not the case: elegance = simplicity
<myst>
and no fancy depends
<kaustuv>
the problem here is far too trivial to make any reasonable judgements about elegance.
<myst>
kaustuv, I am solving f*cking olimiade tasks, and I want the solutions to be nice. And I know how to write programs. ;)
<myst>
than just keep quiet, no?
<myst>
I asked concrete question and you started taching me how to program. Isn't it silly?
<kaustuv>
I am not trying to teach you anything. Have a nice day.
<Alpounet>
myst: could you explainb "batteries - bloated" ?
<Alpounet>
explain*
* thelema
is spurred to work more on aaa
<flux>
from what I gathered, it apparently provides too many features he doesn't see himself using
<Alpounet>
heh
<Alpounet>
like any standard library
<Alpounet>
I never used ALL the stuffs provided by a SL
<Alpounet>
+have
<myst>
to get you comfortable: Boost is bloated
<thelema>
myst: because it's expensive compiling with it?
<myst>
because I don't need 95% of it, and never will be
<thelema>
myst: is the python stdlib bloated?
<myst>
sure
<myst>
But I can't get rid of it *sigh*
<thelema>
I think that you mean "large" when you say "bloated"
<thelema>
and I've been surprised at how much of batteries I'm using for my simple projects.
tonyIII has quit [Read error: 60 (Operation timed out)]
tonyIII has joined #ocaml
<thelema>
But bloated is hard to say from a single perspective, because of the 80/20 rule
<myst>
what I say is my personal opinion and nothing more, and it may be subject to change
<myst>
so don't get it personal, just think of me as "another stupid n00b"
<thelema>
understood. I guess it just triggered some self-reflection on at least my part as to whether batteries could be reduced in complexity.
<thelema>
and I only reacted as strongly as I did because batteries really could be reduced in complexity
<flux>
just find The Unifying Concept and everything becomes clear!
<flux>
like reduce batteries to SKI combinators :)
clog has joined #ocaml
_andre_ has joined #ocaml
_andre has quit [Read error: 110 (Connection timed out)]
mihamina has left #ocaml []
infoe has joined #ocaml
<infoe>
hello
<Camarade_Tux>
>zin &
<Camarade_Tux>
bah, qwerty
<Camarade_Tux>
anyway, hi infoe ;)
ski_ has quit ["Lost terminal"]
dmentre has quit ["Leaving."]
ulfdoz has joined #ocaml
<hcarty>
Has anyone here used/tried both Core and Batteries? I'm curious to hear how they compare.
munga has quit ["Ex-Chat"]
smimou has joined #ocaml
verte has quit ["~~~ Crash in JIT!"]
Ched has joined #ocaml
Alpounet has joined #ocaml
willb has quit [Read error: 60 (Operation timed out)]
komar_ has joined #ocaml
<thelema>
hcarty: core definitely beats batteries in consistency and lots of labeled arguments (which really seems a substitute for intellisense-like IDEs)
<Alpounet>
it is :/
<thelema>
hcarty: batteries wins in having more high-level features
<thelema>
e more* parser for ocaml and keep it up to date.
<thelema>
The problem is that we have to create *on...e more*
* thelema
is thinking backwards, it seems
<jonafan>
I tried to get batteries a while ago but it wouldn't build
<orbitz>
It's interesting how little I have to go back to documetnation in langauges liek Ocaml and Haskell
<orbitz>
looking at the name and type of a function generally suffices for knowing what it does
<thelema>
jonafan: Soon there should be a much simpler version of batteries that builds.
<thelema>
orbitz: I have to go back to the docs a *lot* to figure out order of arguments
onigiri has joined #ocaml
ttamttam has quit ["Leaving."]
<thelema>
especially with all the folds out there, and the arguments of the function being passed in
<orbitz>
if you are referring ot List.fold*, the type is generally enough for me to knwo what it wants
caligula_ has quit [Remote closed the connection]
_zack has quit ["Leaving."]
<thelema>
List.fold* Enum.fold Map.fold, Set.fold all seem to have unpredictable argument orders. yes, the type is sufficient, but what's the type of Set.fold?
<thelema>
do you know it without looking it up?
bind_return has quit ["Leaving"]
f[x] has joined #ocaml
<flux>
darn, I guessed wrong
<flux>
it would be awesome if they were unified. but that'd be sort of a big change.
<flux>
and infact there can be cases where that can silently break code
<orbitz>
thelema: no, that is what i'm saying, looking up types is easy and informative
<mfp>
Map & Set like fold_right... same for Enum I guess?
<orbitz>
thelema: i can pop open a repl, typet he name of teh function and i have teh type
<mfp>
yay what do I win?
ikaros has quit ["Leave the magic to Houdini"]
<orbitz>
mfp: this star!
<mfp>
huh this is wrong Enum > val fold : ('a -> 'b -> 'b) -> 'b -> 'a t -> 'b
<flux>
\|/\n-*- <- prize\n/|\
<mfp>
should at least be ('a -> 'b -> 'b) -> 'a t -> 'b -> 'b like fold_right
<flux>
mfp, hey, Set.S.fold has the same signature?
<thelema>
orb: ah, that is better than I'm doing.
<mfp>
flux: that fold is ... -> 'a t -> 'b -> 'b IIRC, not ... -> 'b -> 'a t -> 'b
<mfp>
that fold = Set.S.fold
<flux>
oh, right
<flux>
I looked at the other types :)
ikaros has joined #ocaml
<flux>
but indeed that Enum's signature would be something completely new
<flux>
one could however say that it is quite important that the order of arguments is prederministic
<hcarty>
thelema: Good points. Core does strike me as "stdlib++", while Batteries adds a lot more depth.
<flux>
I mean, otherwise it can be a hindrance to understanding code, whereas using higher order functions should positively be the opposite
sramsay has joined #ocaml
<hcarty>
mfp: With Batteries, Enum.fold matches the signature for List.fold_left.
<mfp>
Batteries' enum <> Extlib's?
<orbitz>
thelema: module M = SomeModule;; is also a nice REPL trick
<mfp>
what's the point of keeping extlib's overall organization if compat is broken?
<hcarty>
orbitz: Batteries one-ups that with '#browse "SomeModule";;' :-)
<thelema>
mfp: batteries is about to drop extlib's organization
<orbitz>
hcarty: ohh sexified!
<thelema>
(at least aaa)
komar_ has quit [Remote closed the connection]
<hcarty>
thelema: I'm still a little confused as to the future of Batteries. Will the syntax extensions be dropped?
komar_ has joined #ocaml
<orbitz>
IMO, batteries soudns liek a real clusterfuck right now
<hcarty>
While they are by no means needed, "open Foo, Bar, Baz" and ther rest are quite useful and they make for cleaner code.
<thelema>
hcarty: I'm working to advance aaa, which will be a minimal subset of batteries. The direction I'm currently going, full batteries (with syntax extensions) will either diverge completely or will have to be re-architected on top of batteries.
<hcarty>
thelema: Ok, that sounds reasonable. So something along the lines of "Batteries - The Library" and "Batteries - The camlp4"
<thelema>
orbitz: it's undergoing a management change. DT isn't able to put in the work needed to maintain his vision of batteries, so I'm picking up where it left off and heading where I think it should go.
<hcarty>
thelema: Keeping the IO system, I hope?
<orbitz>
thelema: i commend you, and don't envy you
<thelema>
The IO system will be kept, although the depth of its integration with Pervasives is under scrutiny
<thelema>
I want people to be able to optionally use IO under batteries.
<hcarty>
The ability to transparently gzip/gunzip a stream of data is a very aspect of Batteries.
<hcarty>
very _nice_ that is
<Alpounet>
yeah
<Alpounet>
it reminds me of slides from DT
<hcarty>
thelema: Would it be better to work from a base like Core if you are going for something more bare-bones than Batteries in its current state?
julm_ has joined #ocaml
<thelema>
hcarty: I think taking batteries and integrating it into core would be... difficult.
<hcarty>
Perhaps I misunderstand the current restructuring plan. Is there a list of the code which will be kept, won't be kept and might be kept in the new Batteries?
<thelema>
I do plan on doing the opposite - taking useful bits of core and integrating them into batteries.
<thelema>
a list? I'm making it up as I go along.
<thelema>
please call it "AAA" or "AAA-batteries" - I'm trying to not step on DT's project too much, in case that's the direction a group of people want to go.
_zack has joined #ocaml
<hcarty>
thelema: Ok, will do. It's unfortunately a little unclear at this point how the two projects relate.
<hcarty>
thelema: I suppose, ideally, "Batteries Full" would sit on top of "AAA"
<thelema>
hcarty: If you look in the batteries list, there's a post where I give my manifesto -- basically: smaller, easier to install, less invasive
willb has joined #ocaml
<hcarty>
thelema: What is the reason for not using DT's proposal - keep Batteries as "Batteries Full" but remove the module hierarchy and make "AAA" a subset of "Batteries Full"?
<hcarty>
thelema: I imagine it would be more work to maintain. But it would also throw away a lot less work that has already been completed.
<thelema>
I'm about to make major changes to batteries to create AAA. if someone wants to follow me making batteries full on top of what I produce, they're more than welcome to.
<thelema>
I don't plan on spending much time keeping compatibility.
julm has quit [Read error: 110 (Connection timed out)]
<thelema>
(with full)
_zack has quit [Read error: 131 (Connection reset by peer)]
_zack has joined #ocaml
shant has left #ocaml []
Amorphous has quit [Read error: 110 (Connection timed out)]
|Jedai| has joined #ocaml
Amorphous has joined #ocaml
Nutssh has joined #ocaml
ttamttam has joined #ocaml
Jedai has quit [Read error: 110 (Connection timed out)]
slash_ has joined #ocaml
tab has left #ocaml []
tab has joined #ocaml
Yoric[DT] has joined #ocaml
Submarine has joined #ocaml
caligula_ has joined #ocaml
Submarine has quit [Client Quit]
Nutssh has quit ["Client exiting"]
_zack has quit ["Leaving."]
Nutssh has joined #ocaml
animist has joined #ocaml
ttamttam has quit ["Leaving."]
kaustuv_ has joined #ocaml
kaustuv has quit [Read error: 110 (Connection timed out)]
_andre_ has quit ["Lost terminal"]
ulfdoz has quit [Read error: 145 (Connection timed out)]
Snark has joined #ocaml
derdon has joined #ocaml
<derdon>
hi
<orbitz>
hi
<derdon>
what is/are the difference(s) between lists and arrays?
<orbitz>
a list is closer to a linkd list, an array is closer to an array
<orbitz>
so O(1) to reach an index in array
<orbitz>
O(n) in list
<Alpounet>
elements of an array are contiguous in memory
<Alpounet>
(which explains the O(1) access to an element when you have an index)
<orbitz>
arrays are kind of second class citizens in ocaml too
<orbitz>
not a lot of fucntinos for them
<orbitz>
array are mutable too right?
<derdon>
dunno :P
<orbitz>
indeed there is a set
albacker has quit ["_"]
<derdon>
oh, I see that I need a list. arrays don't support hd and tl
<derdon>
but Sys.argv is a string array :(
<derdon>
hopely there is coercion possible
<orbitz>
why do you neend hd tail for Sys.argv?
<orbitz>
and tehre is a to_list function for Arrays
<derdon>
I send two arguments (which are integers) to my script
_JusSx_ has joined #ocaml
<orbitz>
and
_JusSx_ has left #ocaml []
<derdon>
I want to make ints of them by using List.map
<derdon>
and Sys.argv.(0) shall not be in this list
<orbitz>
you jus have 2 of hem?
<orbitz>
List.map int_of_string (List.hd (Array.to_list myarr)) looks like a likely candidate
<derdon>
my script expects two integers, yes
<derdon>
orbitz: you mean ``List.tl`` instead of ``List.hd``, right?
<orbitz>
you could jsut o let (i1, i2) = (int_of_string myarr.(1), int_of_string myarr.(2))
<orbitz>
derdon: yes sorry
<derdon>
I think the former is better
<derdon>
and that's what I wanted to write anyway :)
Snark has quit [Read error: 60 (Operation timed out)]
f[x] has quit [Read error: 145 (Connection timed out)]
<hcarty>
orbitz: Why do you say arrays are second-class citizens in OCaml?
<orbitz>
hcarty: I take that back, the Arrays module is realtively complete
<orbitz>
strings are second class citiens though
<hcarty>
Why is that?
<orbitz>
the stdlib comes with pretty much no useful string functions
<orbitz>
IMO
<Alpounet>
there are additional ones in Batteries IIRC
<hcarty>
I suppose that's why we have PCRE
<Alpounet>
yeah, agreed
<orbitz>
yeah, i'm discountign thrid party libs here. in the standard ocaml disribution you get a pretty weak sring type
<Alpounet>
we get a pretty week SL, actually
<Alpounet>
weak*
<hcarty>
orbitz: According to the OCaml devs, that is by design.
<orbitz>
SL?
<Alpounet>
standard library
<orbitz>
oh, yes
<orbitz>
hcarty: Leroy too concerend with this Coq?
<orbitz>
:)
<orbitz>
s/this/his
<hcarty>
They want to minimize their load and leave it to the community to supplement the library as we need.
<hcarty>
I'll admit they have something of an odd attitude when it comes to the guts of the compiler. But there has been repeated noise that they are in favor of the community defining what makes up a "standard" OCaml installation (libraries, tools, etc)
<Alpounet>
without the will to integrate any widely used and accepted modules in the SL
<Alpounet>
:/
<hcarty>
Alpounet: Their argument is that they then become the maintainers of those modules
<hcarty>
Which is what they want to avoid
<hcarty>
A Community OCaml distribution would be one way to work around this.
<Alpounet>
OR, they open a bit more the standard OCaml distribution...
<hcarty>
Similar to what thelema started
<Alpounet>
hcarty, like, say, a Batteries one :p
<hcarty>
Alpounet: Indeed :-)
<hcarty>
Alpounet: Indeed to both comments :-)
<Alpounet>
heh
<thelema>
yes, the ocaml string library is quite weak compared to others.
<thelema>
I plan on using substring as a fundamental type in aaa-batteries, so that splitting and that kind of manipulation is efficient (i.e. not requiring major allocation)
<Alpounet>
try to keep a simple, intuitive and non-obfuscated interface for the modules, though.
derdon has quit []
Nutssh has quit [Read error: 110 (Connection timed out)]
smimou has quit ["bli"]
Yoric[DT] has quit ["Ex-Chat"]
<thelema>
you make it sound easy
Nutssh has joined #ocaml
* thelema
demands feedback
willb has quit [Read error: 110 (Connection timed out)]
<Alpounet>
thelema, I know it is not easy at all
<Alpounet>
but having substring being the core of the string library in aaa can make the interface less straightforward, less simple.
<thelema>
if you can do whatever you want to a substring that you would do to a string, ...
<Alpounet>
yeah, I got it
sramsay has quit [Remote closed the connection]
Nutssh has quit [Read error: 113 (No route to host)]