<AlexR>
Hmmm...does menhir use a considerably different format from ocamlyacc?
Yoric[DT] has quit ["Ex-Chat"]
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
<Skolem>
According to http://www.ocaml-tutorial.org/hashtbl, the way to initialize a hash table is to repeatedly write ``Hashtabl.add my_hash "h" 1;; Hashtabl.add my_hash "g" 2;; ..." I've heard that OCaml is great at eliminating redundant boilerplate from code. How would I write the above initialization without redundancy?
<Alpounet>
hm...
<Alpounet>
> let init = [("h",1) ; ("g",2)] ;;
<mlbot>
val init : (string * int) list = [("h", 1); ("g", 2)]
<Alpounet>
> List.iter (fun (a,b) -> Hashtabl.add my_hash a b) init ;;
<mlbot>
Type Error
<Alpounet>
(error because here my_hash is undefined)
<Alpounet>
(but in your code it'll work)
<Alpounet>
that's a way like another to reduce the init phase code's size
<Skolem>
Alpounet, thanks!!!
<Alpounet>
> let h = Hashtbl.create 100 in let init [("h",1) ; ("g",2)] in List.iter (fun (a,b) -> Hashtbl.add h a b) init ;;
<mlbot>
Syntax Error
<Alpounet>
> let h = Hashtbl.create 100 in let init = [("h",1) ; ("g",2)] in List.iter (fun (a,b) -> Hashtbl.add h a b) init ;;
<mlbot>
- : unit = ()
<Skolem>
Genius.
<Alpounet>
> h ;;
<mlbot>
Type Error
<Alpounet>
fine.
<Alpounet>
Skolem, moreover, you can define a function like "let my_hash_add = Hashtbl.add my_hash", for a given "my_hash", if you use it heavily and on many places in your code.
<Skolem>
Just added your idea to my script. Works perfectly. I like the idea of a custom my_hash_add. I appreciate your help a bunch.
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
verte has joined #ocaml
<kaustuv>
> let hashtbl_of_list ?(size=19) l = let ht = Hashtbl.create size in List.iter (fun (k, v) -> Hashtbl.add ht k v) l ; ht ;;
<mlbot>
val hashtbl_of_list : ?size:int -> ('a * 'b) list -> ('a, 'b) Hashtbl.t =
<mlbot>
<fun>
<kaustuv>
or
<kaustuv>
> let hashtbl_of_list l = let ht = Hashtbl.create (List.length l) in List.iter (fun (k, v) -> Hashtbl.add ht k v) l ; ht ;;
<mlbot>
val hashtbl_of_list : ('a * 'b) list -> ('a, 'b) Hashtbl.t = <fun>
<Alpounet>
kaustuv, 19 ? :-p
slash_ has quit [Client Quit]
Ched has quit [Read error: 110 (Connection timed out)]
Ched has joined #ocaml
det_ has joined #ocaml
det has quit [Read error: 104 (Connection reset by peer)]
Ched has quit [Read error: 101 (Network is unreachable)]
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
komar_ has quit [Read error: 104 (Connection reset by peer)]
komar_ has joined #ocaml
vuln has joined #ocaml
<vuln>
Good night :)
ztfw has quit [Remote closed the connection]
<kaustuv>
I think I've constructed the xmas-tree data structure.
<vuln>
Just one bug, it is taking one iteration more
<vuln>
I will fix it now
<vuln>
(a = b-1)
<vuln>
:)
<vuln>
gotta go
<vuln>
good night
vuln has quit ["leaving"]
T_S_ has joined #ocaml
komar_ has quit [Read error: 113 (No route to host)]
Snark has joined #ocaml
Camarade_Tux has joined #ocaml
<_yziquel>
flux, mrvn: http://paste.debian.net/33918/ is a modification of lazy.ml that does the trick. exceptions are not kept.
komar_ has joined #ocaml
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
Ched has joined #ocaml
Axioplase has joined #ocaml
Gondegal has joined #ocaml
Gondegal has left #ocaml []
monadic_kid has joined #ocaml
komar_ has quit [Remote closed the connection]
<flux>
_yziquel, good that you found a solution :)
<flux>
but, I didn't.. unison still crashes with stack set to 200 megabytes, while the process size itself never grows beyond 650M..
<flux>
I'm on 32 bit. also I think that that unison binary has been compiled with 3.09. 3.11 brought some heap management enhancements, so I better try recompiling with a more recent compiler
_zack has joined #ocaml
<Camarade_Tux>
flux, btw, I'm really not sure but I think you get an Out_of_memory exception when allocating big values (directly on the major heap ?) and are OOM-killed when allocating smaller values (such as t in 'let t = 3, 4') but that's just a wild guess
<flux>
camarade_tux, yeah, well I'm not running out of heap, unless the program allocates a gigabyte in 10 seconds
<Camarade_Tux>
he, that's what the program I'm currently playing with does ;p
<flux>
maybe I should log the memory consumption in a faster loop
<flux>
I'm hoping that ocaml version has just required the heap to be continuous
<flux>
in any case, I'm retrying with memory logging interval at 0.1 seconds
<flux>
(binary compiled with 3.11)
<Camarade_Tux>
something I really don't like is that Gc.compact makes my program use 460MB instead of 260MB (two 16M elements arrays on 64bit)
<Camarade_Tux>
(arrays freshly marshaled from a file)
<flux>
bug?
<Camarade_Tux>
well, I have troubles making a reduced test case but the program where this happens has been changed to only Marshal.from_channel and then call Gc.compact
<Camarade_Tux>
whoa, I found out why I couldn't reproduce it : I was marshaling from the files, using read_line to wait, compacting, using read_line to wait again and calling a function in another module (the one that does the actual work)
<Camarade_Tux>
I always interrupted the program before it called the last function so it was never executed and I thought it had no influence, but I was wrong : with the never-executed line, the problem happens and not without =/
<mrvn>
Camarade_Tux: What did you expect? The minor heap contaisn the 2 128MB arrays and compact copies them to the major heap.
komar_ has joined #ocaml
<mfp>
mrvn: blocks over 256 words are allocated directly in the major heap
<mrvn>
ok, then they are compacted from major to major heap.
<mfp>
OCaml used to employ mmap to get mem chunks, but as of 3.11 it only uses malloc
<mrvn>
well, malloc does mmap too
<mfp>
so if the underlying malloc is not smart enough, the memory won't be released to the OS
<mfp>
but it depends --- you can never know. It sometimes does sbrk too.
<mrvn>
A benefit of mmap would be that it could remap the pages to move data.
<Camarade_Tux>
isn't the problem with mmap that it causes terrific memory usage on 64bit ?
<Camarade_Tux>
and I didn't expect the memory usage to double when compacting =/
<Camarade_Tux>
especially because of something *later* in the code
<mrvn>
Camarade_Tux: why should it? mmap is mmap.
<mrvn>
Does ocaml free the old heap after compacting or does it keep if for the next GC run?
<mrvn>
s/if/it/
<mfp>
for the next GC run?
<mrvn>
the next comacting
<mfp>
the major heap is not a 2-space copying GC
<mfp>
hmmm
<mrvn>
then why does compact double the mem usage?
<mfp>
wouldn't that be rather pointless?
<mfp>
I think that's because malloc is failing to release the memory
<mfp>
Camarade_Tux: try to run under strace both when you observer the pb and when you don't
<mrvn>
maybe 128MB is below the malloc limit
<mfp>
Camarade_Tux: look for brk and m(un)map
<mfp>
*when you observe the ...
<mfp>
Camarade_Tux: if you see no m(un)map, but extra brk calls in the later code, it's a fragmentation pb.
<Camarade_Tux>
mrvn, I mixed a few names up so nvm, btw that's what I had in mind "where blocks allocated by malloc() can come either from sbrk() or mmap(), two areas that are spaced several *exa*bytes apart" ( http://alan.petitepomme.net/cwn/2007.11.20.html#3 )
Associat0r has joined #ocaml
Yoric[DT] has joined #ocaml
komar_ has quit [Read error: 104 (Connection reset by peer)]
<Camarade_Tux>
the code without problem has two additional munmap() calls, the most important one being "munmap(0x7fe926cf9000, 241602560) = 0" which is basically the "missing" memory
<Camarade_Tux>
there are no extra brk() calls however
<Yoric[DT]>
hi
<Camarade_Tux>
hi Yoric[DT]
<Camarade_Tux>
oh, and forgot to mention the problematic code had : "mmap(NULL, 241602560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fedd5d24000"
<mfp>
Camarade_Tux: the OCaml runtime might be at fault then
verte_ has joined #ocaml
<mfp>
Yoric[DT]: got a minute to help me w/ a Batteries build problem? (I'm porting the test suite to OUnit)
<mfp>
testsuite/myocamlbuild.ml is just cut & paste from the main one
verte has quit [Nick collision from services.]
verte_ is now known as verte
<Camarade_Tux>
mfp, ok, I'll check the mantis and maybe open a bug, I should hopefully be able to circumvent the problem, thanks
<mfp>
(I also tried to add <testsuite/*>: pkg_oUnit to the toplevel _tags before realizing that make test was just doing cd testsuite && ocamlbuild stuff)
<mfp>
Camarade_Tux: not sure it's really a bug. It could be that malloc is keeping the mmap'ed areas around for later use, too.
<mfp>
Camarade_Tux: it'd be interesting to see whether OCaml is calling free() in both cases --- if it is, malloc is to blame
<Yoric[DT]>
mfp: let's start with the easy suspects: are you sure that the package name is oUnit?
<mfp>
yes
<mfp>
so says ocamlfist list
<mfp>
*ocamlfind
<mfp>
uh
<mfp>
I tried to add some printfs in myocamlbuild.ml, but the output is seemingly going nowhere (not in _log nor stdout)
<Yoric[DT]>
Yeah, that's one of the numerous annoyances of ocamlbuild.
<Yoric[DT]>
Mmmmhh....
<Yoric[DT]>
Which "main one" are you mentioning?
<Yoric[DT]>
The one in doc?
<mfp>
the one in /
<Yoric[DT]>
For testsuite, you should use the one in doc.
<Camarade_Tux>
mfp, no, no call to free ; the problematic version only calls mmap() after it has read and close the file I'm marshaling from
<Yoric[DT]>
The one in / is full of stuff which only matter for building Batteries itself.
<mfp>
Yoric[DT]: yeah, I removed everything but the OCamlFind module (http://ocaml.pastebin.com/m314492e8), but I see I was missing the Batteries module
<mfp>
anyway, the one in doc fails the same way :|
Associat0r has quit []
<Yoric[DT]>
:/
<mfp>
OCamlFind.after_rules seems not be be executed at all, I added let o = open_out "/tmp/LOGxxx" in Printf.fprintf o "LOGGING YEAH\n"; close_out o; and there's no /tmp/LOGxxx to be found
<Yoric[DT]>
Well, ocamlbuild has a nasty habit of cleaning-up your temporary files without asking.
<Yoric[DT]>
So I wouldn't call this a proof.
<mfp>
is the dispatch (function | Before_option -> ... | After_rules -> ...) all what's needed?
<mfp>
also files outside the build tree?
<Yoric[DT]>
I'm not 100% sure.
<mfp>
tried with Pervasives.open_out and close_out, same thing
<Yoric[DT]>
Try an [assert false], to be sure.
<mfp>
it could also be redefining the Pervasives module, though
<mfp>
uh
<mfp>
I get a compile time warning File "myocamlbuild.ml", line 59, characters 13-25: Warning X: this statement never returns (or has an unsound type.)
<mfp>
but it tries to compile the suite instead of failing in myocamlbuild
<Yoric[DT]>
Mmmmmhhhh....
<Yoric[DT]>
Yeah, I have the same problem.
<Yoric[DT]>
That looks like a bug in our version of ocamlbuild.
<mfp>
another possible bug in the build process I'm seeing:
<flux>
camarade_tux, btw, did you check that not only the virtual size of the process increases but also the resident set?
<mfp>
the ocaml executable is not installed
<mfp>
Yoric[DT]: instead, there's an ocaml.in along with the other custom execs (ocamlbuild, ocamlc, ocamlcp, ocamldep, ocamlopt)
<Yoric[DT]>
That's weird.
<mfp>
seems that everybody had an ocaml file resulting from the expansion of ocaml.in around
<mfp>
since make just installs ocaml*, it worked
<mfp>
but the file was gone after I did a make clean
<Camarade_Tux>
flux, yes : before the compaction, virtual size is about 470MB and resident is 260MB ; after, virt doesn't change much and res reaches 463MB
<mfp>
Yoric[DT]: k, it's regenerated by ./configure
<mfp>
make clean shouldn't remove it, though
<mfp>
(and ocaml.in shouldn't be installed)
<Yoric[DT]>
So, the problem is that you have both batteries/ocaml.in and batteries/ocaml ?
komar_ has joined #ocaml
<mfp>
yes
<mfp>
doesn't really matter
<mfp>
actually, the real problem was that make clean removed [ocaml], which thus didn't get installed afterwards
<mfp>
you could expect that from distclean, but not really from clean
<mrvn>
Camarade_Tux: I believe what you see is just the effect of mark&sweepofthe GC.
Amorphous has quit ["shutdown"]
<mrvn>
Camarade_Tux: I believe what you see is just the effect of mark&sweep of the GC.
_zack has quit [Read error: 110 (Connection timed out)]
<mrvn>
Camarade_Tux: sweeping the heap makes the unused parts seem used.
monadic_kid has quit ["Leaving"]
deech has joined #ocaml
<Camarade_Tux>
mrvn, with linux's memory management, that's most likely the case but the problem remains : it shouldn't have allocated so much
<mrvn>
Camarade_Tux: the moment it allocates a 256MB heap you have lost.
<mrvn>
Should it have allocated a heap that perfectly fits only the array?
<Camarade_Tux>
yeah, that's true, I don't even need to wait, the problem happens as soon as Array.make is called
<Camarade_Tux>
mrvn, I don't ask it to allocate exactly the heap but it currently allocates twice the heap
<Camarade_Tux>
I have just created a 110M elements array, res is 888MB but virt is 1601MB !
<mrvn>
It probably always allocates request*2 when growing the heap.
<mrvn>
Which is good if you have many similar sized objcts but bad if you have one single huge one.
<Camarade_Tux>
another possibility is that an int array is a special case which use less memory but the allocator doesn't take that into account
T_S_ has quit []
<mrvn>
read the source. But there is no bug there. Just a bad guess what the heap size should be. At leastin your test.
ztfw has joined #ocaml
<Camarade_Tux>
that's what I think too now
<flux>
grr, same error. it did get further, from 600M to 800M
<flux>
perhaps I need to rsync that particular branch manually or investigate how to make unison flush to a temporary file
tty56 has joined #ocaml
<flux>
took a better look at the problematic place: Marshal.to_string data [Marshal.No_sharing]
<flux>
16M arrays suck :(
<mrvn>
16M array/string limit sucks. buy 64bit.
<flux>
actually I think I have 64 bit, but I chose to install 32 bit for nicer binary compatibility :)
<mrvn>
und irgendwann wollens alle mal.
<mrvn>
ups
<flux>
yep, Athlon(tm) 64 X2 Dual Core Processor
<mrvn>
64bit ocaml really does have some benefits.
<flux>
perhaps I should make the switch
<Camarade_Tux>
on linux, now, everything is basically ok
<mrvn>
In my FS I have a lot of code that needs to use Int32/Int64 to be 32bit compatible where 64bit could just use int. Sucks.
<Camarade_Tux>
s/everything is basically/basically everything is/
<mrvn>
flux: create a chroot and try it.
<flux>
mrvn, but my kernel is in 32-bit mode..
<mrvn>
flux: for that you need to reboot.
<flux>
my boot medium is compact flash, so given I get a new card it should be relatively safe to try out 64 bit
<flux>
mrvn, I can't have 32-bit userland with 64-bit kernel, or can I?-o
<mrvn>
sure you can
<flux>
without any special tricks?
<Camarade_Tux>
that's what OSX does iirc
<mrvn>
yep. apt-get install linux-image-amd64 and reboot. :)
<flux>
OSX is not linux
<mrvn>
.oO( I do love Debian )
<Camarade_Tux>
but that shows it is possible ;)
<flux>
heyy, my kernel binary package description says Linux kernel image for version 2.6.22 on x86/x86_64
monadic_kid has joined #ocaml
<flux>
so do I just need 64 bit binaries?
<mrvn>
And install linux32 as well. Some broken sources use uname to figure out what arch to build for and will try to build for 64bit then. linux32 ./configure will fix that.
<mrvn>
only kernel.
<flux>
well, gcc will say a pointer size is 4 bytes
<mrvn>
gcc -m64 will say 8
<flux>
it wants something, such as gnu/stubs-64.h
<flux>
installing lib64gcc1 will give me libc6-amd64 too
<mrvn>
Under debian you need gcc-multilib to use -m64.
<mrvn>
But you should really setup a chroot to try 64bit.
<flux>
perhaps I'll just rsync the backup of the current system to another
<flux>
and if things go broken, I can revert the backup with my laptop
<mrvn>
or that
<mrvn>
But then youstill have a 32bit system.
<flux>
debootstrap can set up the chroot environment for me, right? or is there a better alternative?
<mrvn>
flux: -aamd64
<mrvn>
cdebootstrap if you like that better
<mrvn>
do you use dm-crypt?
<flux>
yes
<mrvn>
I believe that is faster in 64bit.
<flux>
raid might also be faster. unless the sse facilities are the same.
<flux>
CFLAGS=-m64 make foo -> foo gives me exec format error
Axioplase has quit ["Lost terminal"]
<flux>
teh interweb claims, on 2007, there's no way to go from 32-bit ubuntu to 64-bit
<flux>
perhaps things are better in the debian land :)
Amorphous has joined #ocaml
monadic_kid has quit ["Leaving"]
Ched has quit ["Ex-Chat"]
Ched has joined #ocaml
<palomer>
hmmm
<palomer>
normal variants are faster than polymorphic variants, right?
<palomer>
man, I remember the days when leetspeak was lame
verte has quit [":("]
<Camarade_Tux>
palomer, yes, p0|y|\/|°Rp|-|l< \/4r|AnT5 R 5|0\/\/3R (sorry...)
<palomer>
much slower?
Kerjean has joined #ocaml
<flux>
benchmark?
<Camarade_Tux>
I haven't benchmarked them but iirc variants are actually integers while polymorphic variants are string that are looked up in a hashtable
<palomer>
yup, noticeably faster
<palomer>
I have a test case where they're faster
<palomer>
if I lookup a string of length n in a hashtbl, I'm looking at O(n) complexity, right?
<Camarade_Tux>
nah, O(1) but with a quite high factor
<palomer>
oh, this is an unrelated question though
<hcarty>
thelema: Sorry for disappearing, my net connection died
<hcarty>
thelema: I think the camlzip library is named Gzip rather than GZip
<flux>
palomer, it is a surprise to you that hash table hashes contents?-)
Ariens_Hyperion has joined #ocaml
<mfp>
Camarade_Tux: polymorphic variant constructors turn into an integer at compile time
<mfp>
there are 2 differences between regular variant types and polymorphic ones:
<mfp>
for the former, the constructor is the tag of the block; for the latter, the hash value of the constructor is stored as the first element of the block (so the block is 1 word longer), and
<mfp>
pattern matching is done with a branch tree in the latter, and an indirect jump in the former
<mfp>
i.e. O(log n) vs. O(1)
<mfp>
but polymorphic variants are said to be competitive with normal ones for up to a dozen constructors or so
<mfp>
palomer: O(n) indeed in the length of the key
komar_ has quit [Read error: 113 (No route to host)]
Amorphous has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
Yoric[DT]: ping
<mrvn>
flux: Where there is a will there is a way. It just isn't pretty.
<thelema>
palomer: strings are not pre-hashed, and it does mix in the whole string into the hash value, so strings would be O(n) to hash
<flux>
mrvn, well, I just actually installed 9.04/amd64 with a install server I set up
<flux>
but I still have to recover functionality.. raid for once :)
<flux>
for one, even
<thelema>
hcarty: you're right about GZip vs. Gzip. It was an intentinal change back in November. git commit id e8691a8a...
<hcarty>
thelema: How do I view a specific commit by hash in git?
* thelema
uses gitk --all
<hcarty>
Ah, I see
<thelema>
if you wanted the diff between that commit and the previous, ...
<hcarty>
gitk will let you go to a hash id
<mfp>
hcarty: git log <hashid>
Amorphous has joined #ocaml
<hcarty>
mfp: Cool, thanks
<thelema>
mfp: that doesn't tell what changed, it just gives the log
<mfp>
-p to see the patch, --stat for summary
<mfp>
thelema: -p
<hcarty>
thelema: Do you know the reason for the change?
komar_ has joined #ocaml
<thelema>
hcarty: I don't.
<thelema>
mfp: didn't know.
<mfp>
also git show <hashid>
<hcarty>
thelema: It breaks pre-Batteries code since Gzip (raw) uses OCaml in_channel and out_channel while GZip (Batteries) uses the Batteries IO
<hcarty>
So code which previously worked with open_in and Gzip.* now fails with a type error
<hcarty>
It is at least worth a mention in the documentation
<hcarty>
I don't know how it should fall with respect to the module naming scheme since the two capital letters are next to one another like IO, not spread out like BigArray
<flux>
hmph, the new ubuntu jaunty is still 3.10. of course, better than 3.09 :)
javax has joined #ocaml
<hcarty>
flux: You could make a PPA :-)
mjonsson has quit [Read error: 110 (Connection timed out)]
<palomer>
8.10 is 3.10, no?
<palomer>
yup, 3.10.2
<palomer>
jaunty wouldn't regress back to 3.09
BiD0rD has quit []
Fullma has quit [Connection timed out]
Fullma has joined #ocaml
<flux>
hcarty, PPA?
<flux>
oh
<hcarty>
flux: Ubuntu Personal Package Archive
<hcarty>
I started making a 3.11 PPA for Intrepid
<hcarty>
It's a bit of an initial investment, but doesn't seem to generally be too difficult as long as the Debian infrastructure has not diverged too far from Ubuntu's last import
<Ariens_Hyperion>
why not just use godi?
<hcarty>
Ariens_Hyperion: It's much easier to type "apt-get install ocaml-foo" or "yum install ocaml-foo" than to go through the GODI installation
<hcarty>
Particularly for someone new to the process
<Ariens_Hyperion>
but the ubuntu repos for all ocaml libs are very lacking
<Ariens_Hyperion>
compared to say
<Ariens_Hyperion>
fedora
<hcarty>
That is certainly true. Hence the attempt at setting up an outside package repository
<hcarty>
That, though, is far more work than installing GODI :-)
<Ariens_Hyperion>
yeah
<hcarty>
It is more usable by others though
<Ariens_Hyperion>
and you had to teach the begginer to add the repo to the software sources
<hcarty>
I still think that is a lot easier than directing them to all of the GODI prereqs
<hcarty>
And helping them with any compilation or other errors which come up
jeanbon has joined #ocaml
<hcarty>
thelema and Yoric[DT]: Would you mind reading over this when you have a chance? It is a list of some of the pitfalls I have faced while porting my code to Batteries. I think sometime similar, though perhaps better written, would be useful to include when Batteries 1.0 goes out the door: http://ocaml.pastebin.com/m541d893e
<thelema>
your specific examples of List.hd and tl make poor examples of exception change - I'd argue that using list.hd/tl is bad form.
<Kerjean>
how can i trace the list of rules followed by ocamlyacc before an error ?
<hcarty>
thelema: It may be bad form, but it is something that is not caught until run time
Ched has quit ["Ex-Chat"]
Ched has joined #ocaml
<hcarty>
And bad form or not, the functions are there to be abused in both libraries
<thelema>
hcarty: my proposal to fix this is to have a Compatibility module, so one can "open Batteries with Compatible" (or whatever the exact syntax is) and have the original exceptions and in/out_channels instead of IO.input/output
<thelema>
You're probably right about IO.No_more_input vs. End_of_file
<thelema>
we have to be compatible with one or the other, and I think stdlib compatibility is more important than extlib compatibility
<hcarty>
I think a "open Batteries with Compatible" would be a good idea for legacy code as it would allow users to take advantage of new Batteries goodness without breaking existing code
<hcarty>
I don't know how difficult it would be to build such a thing though
<hcarty>
IO.No_more_input vs End_of_file makes sense given the new IO infrastructure, but oh my is it a pain to not find until run-time :-)
<thelema>
hcarty: it'd be pretty easy given knowledge of all the places batteries diverges from stdlib in ways that could possibly break things
<thelema>
these kind of exceptions you're naming aren't really exceptional cases - they're examples of using exceptions for flow control
<hcarty>
Exceptions seem to be used often for flow control though, particularly when working in the confines of stdlib
<thelema>
? End_of_file is the only exception I can think of that one would expect to have raised in normal execution
<hcarty>
There are not many functions available in the stdlib to get around that, at least for IO
<hcarty>
Sorry, I meant specifically for IO in that statement
<thelema>
you're right, and that's why I agree on changing IO.No_more_input to End_of_file
<thelema>
hmm... sometimes.
<thelema>
grr, maybe not...
<mrvn>
Not_found is usual too
<hcarty>
List.hd and List.tl may be bad style, but they are tempting functions to use when one is new to OCaml and functional programming. I think these folks are good targets for Batteries adoption so they may be hit by this
<thelema>
mrvn: you're right. I wonder if we changed any of those
<mrvn>
What does hd/tl do different in Batteries?
<flux>
what would be great: a camlp4 extension to 'lint' or possibly even convert non-batteries programs to batteries-conformant
<thelema>
mrvn: it raises Empty_list instead of Failure something
<flux>
but someone(TM) would need to write it :)
<hcarty>
thelema: Yes, I'm not sure regarding IO.No_more_input <-> End_of_file. That is a tough one to judge, given the flexibility of IO
<thelema>
hcarty: well, it would be silly raising End_of_file for an IO that's reading from a string or non-file input
<hcarty>
thelema: Quite
Kerjean has quit ["Vision[0.8.5-0418]: i've been blurred!"]
<mrvn>
Failure "hd" sucks.
<thelema>
but it's not reasonable to change just some of the exceptions, as all the IO-helper functions expect IO.No_more_input
<mrvn>
Maybe Not_found for List.hd/tl would be appropriate too.
<Camarade_Tux>
Bigarray...
<mfp>
alright, I've ported Batteries' testsuite to OUnit (removing much redundancy in the process) & would like to push a branch to the git repos
mjonsson has joined #ocaml
<mfp>
any admin around to add me to the devel list on forge.ocamlcore.org (user mfp)?
Ched has quit ["Ex-Chat"]
Ched has joined #ocaml
<flux>
exceptions would be much nicer if ocamlexc worked
<mrvn>
ocamlexc?
<thelema>
mfp: request to join
<thelema>
n/m, found the box
<thelema>
ok, you're on the list
<mfp>
thanks
<mfp>
what's the devel git repost? ssh+git something?
* mfp
tries to find it on ocamlcore
<mfp>
these forge sites are surprisingly difficult to navigate
<mfp>
(too many links)
<hcarty>
mfp: It's not on the forge, from what I know
<hcarty>
mfp: I think it's git+ssh://git.ocamlcore.org/gitroot/batteries/batteries.git
<mfp>
hcarty: thx, trying
<thelema>
yup, that's it.
<thelema>
mfp: I agree - *forge has a garbage UI
<Ariens_Hyperion>
why did the launch ocamlforce
<Ariens_Hyperion>
coldnt they move everything to github or something else?
<mfp>
Ariens_Hyperion: well, at the time github didn't have issue management, and it's git only. The ocamlcore setup does git, cvs, svn, maybe darcs too.
<mfp>
things would be diluted in the non-OCaml (mostly Ruby) stuff hosted in github
<Ariens_Hyperion>
yeah
<Ariens_Hyperion>
in ocaml forge thingds get diluded because nobody outside ocaml knows it
<mfp>
that said, I much prefer github's to forge's interface for the part it does handle
marteo has joined #ocaml
<marteo>
hello, yet another newbie question ?
<marteo>
is it possible with only caml light to obtain an executable binary ? and how ?
<mfp>
hcarty, thelema: pushed mfp/ounit-testsuite. Once I have the toplevel tests back, I'll be rebasing against master, pushing and killing the branch, if nobody opposes.
<marteo>
kaustuv_, thanks
<flux>
can godi be made to compile stuff with multiple cpu's?
<mfp>
it might be able to parallelize at the package level; I don't think they have patched all the build systems to parallelize within a package, though
<flux>
well, any kind of parallelism would do :)
<flux>
I'm busy busy busy, but my other core is idling :)
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<kaustuv_>
flux: what happens when you launch godi_console with MAKEFLAGS='-j 2' ?
<thelema>
mfp: I'm reading now
_yziquel has quit [Remote closed the connection]
wsmith84 has joined #ocaml
jeremiah has joined #ocaml
<flux>
kaustuv_, I'll try that
<wsmith84>
Good morning, I have a really newbie question.
<flux>
great, godi's make doesn't support -j
<wsmith84>
I have a simple interface to a module:
<wsmith84>
module type THING =
<wsmith84>
sig
<wsmith84>
type a type t val create : a -> t
<wsmith84>
end ;;
<flux>
otherwise that would've worked
<wsmith84>
and a simple implementation:
<wsmith84>
module FloatThing:THING =
<wsmith84>
struct
<wsmith84>
type a = float type t = a let create a = a
<wsmith84>
end
<wsmith84>
;;
<wsmith84>
here is the signature of the create function:
<wsmith84>
The answers they provide are not usable...
<kaustuv_>
flux: godi has its own make? What madness is this?
kaustuv_ is now known as kaustuv
<flux>
kaustuv, indeed
<flux>
kaustuv, iirc it uses some bsd make
<Camarade_Tux>
with Bigarrays instead of bigarrays, the memory usage is basically a fourth of the one with arrays
<Camarade_Tux>
pkgsrc iirc
<marteo>
hmm, it does not seem to work as I expected... I put print_string "Hello World" ;; into a test.ml file, then camlc test.ml
<marteo>
then camlrun a.out does nothing
<kaustuv>
I guess I'm glad I dumped godi for the nice Debian packages (good job to the Debian maintainers)
<flux>
marteo, try print_newline instead
<wsmith84>
kaustuv: your suggestion is not grokked by ocaml, it thinks the ThingVector functor has to abide by the signature of THING.
<flux>
marteo, likely your prompt wipes the result
<marteo>
eh, it's only bash...
<marteo>
under Debian
<flux>
marteo, compare to what happens with: echo -n "Hello World"
<flux>
if something appears, then that's not the problem
<kaustuv>
wsmith: run this through ocaml
<kaustuv>
module type S = sig type a type t val create : a -> t end ;;
<kaustuv>
module Vec (S : S) : S with type a = S.a = struct type a = S.a type t = a array let create x = [| x |] end ;;
<kaustuv>
module Flt : S with type a = float = struct type a = float type t = float let create x = x end ;;
<kaustuv>
module M = Vec(Flt) ;;
<kaustuv>
M.create 3. ;;
<hcarty>
Camarade_Tux: I'm using Bigarrays in several places here due to memory constraints. It can also make data saving sharing simpler in a few cases
<hcarty>
s/saving/saving and/
<mrvn>
> module type S = sig type a type t val create : a -> t end ;;
<kaustuv>
no bot
<marteo>
flux, effectively, bash seems a little bit strange in my new installation... seeing the distro-maintainers
<flux>
marteo, did print_newline fix the program?
<kaustuv>
print_newline works for me, fwiw
<kaustuv>
(also Debian, but zsh, not bash)
<flux>
a recent zsh detects and remedies the situation
<wsmith84>
kaustuv: nice, but if I change "create" to "create2" in module Vec, it fails, and my limited understanding thinks it shouldn't.
<flux>
but that's a relatively recent feature
<mrvn>
kaustuv: So Vec is a functor which return also fits the input signature?
<kaustuv>
mrvn: not necessarily. the abstract types are different
<marteo>
flux, no, it does nothing either
<kaustuv>
wsmith84: if you want Vec not to conform to S, remove the : S with ... bit
monadic_kid has joined #ocaml
<mrvn>
kaustuv: Isn't that waht "Vec (S : S) : S" says?
<flux>
marteo, your whole program is in file foo.ml: print_newline "Hello World";;, you run ocamlc foo.ml, you execute ./a.out, does something come out?
<wsmith84>
Yes, that's what I want, but I want to expose 'a' as public.
<kaustuv>
mrvn: that's not what I wrote. S has two types, a and t.
<wsmith84>
How do I do that?
<wsmith84>
Shyte, it works in your case.
<kaustuv>
wsmith84: if you want create2, you'd have to give it a different target signature, such as:
<kaustuv>
module Vec (S : S) : sig type a = S.a array type t val create2 : a -> t end = struct ... end
<wsmith84>
kaustuv: I'm confused; Vec does not implement S, it's a functor of S. Vec does not declare a signature.
<wsmith84>
Isn't that correct?
<marteo>
flux, a print_newline () works but not print_string "Hello World"
<kaustuv>
wsmith84: whether Vec has a target signature or not is up to you. If you don't want a target signature, don't give it one.
<kaustuv>
wsmith84: but the only way you can expose a and hide t is to give it a signature.
<kaustuv>
(Assuming Vec has both a and t, that is)
<flux>
marteo, programs are supposedly to end their output with a newline
<flux>
marteo, print_string doesn't output one, print_newline does
<wsmith84>
kaustuv: your create function has 'a -> 'a array signature. It should have a -> a array.
<marteo>
oh, I did not know
<marteo>
it works ;) thanks, sorry for th inconvenience
<wsmith84>
kaustuv: I'm trying to change it so it matches my own code problem.
<wsmith84>
kaustuv: in this code, M.create_vec <float> wo'nt work, but shouldn't it?
<wsmith84>
Vec(Flt).a is float
<wsmith84>
it is exported in the signature.
<kaustuv>
wsmith84: do you know what a declaration "type a" in a signature means?
<wsmith84>
I'm not entirely sure anymore.
<wsmith84>
It just exposes it abstractly?
<flux>
hnngh, godi_console is bloody annoying in not displaying the dependencies to the other direction
<wsmith84>
My question is how to make it public, so that you can call M.create_vec .
<thelema>
Your functor uses module type S, thus Vec.a = S.a is abstract
Snark has quit ["Ex-Chat"]
<kaustuv>
wsmith84: I think there is a basic confusion here. A signature does not "make things public". Rather, defines a contract. If the contract says that "type a = float", then the module that ascribes to the contract should have "type a = float". If it says "type a", then the module can declare "type a = string" or "type a = whatever".
<mrvn>
The signature can make the type hidden though.
<kaustuv>
Therefore, if you want the contract for Vec to have "type a = S.a", then the signature should state it.
<flux>
finally I guesed the proper set of packages I needed to remove
<thelema>
kaustuv: his does. He doesn't want Vec to have type a = S.a
<thelema>
kaustuv: err, there's confusion about S (the functor parameter) and S (the type of the functor parameter)
<kaustuv>
I am getting off the wagon here. Figure it out on your own. This ain't rocket science.
<wsmith84>
kaustuv: nice explanation, but I already understood that part. The problem is not this, the problem is that type a = S.a does _more_ than state it, it also seems to _allow_ the usage of create_vec with a simple flaot.
<wsmith84>
I just tried it, repeating the "type a = S.a" declaration in the signature fixes the problem.
<mrvn>
wsmith84: if S.a is public and float then yes
<wsmith84>
kaustuv: thx for your patience :-)
* thelema
was confused...
<thelema>
kaustuv: sorry, you were right. I thought I was reading the signature, but I was reading the struct.
<wsmith84>
The things that is most broken in all this, is that this problem stems from the exercise section in the OReilly book, where you define parameterized vectors of floats, complex, and rational, but you can't use them.
slash_ has joined #ocaml
<kaustuv>
does the o'reilly book come with answers?
<wsmith84>
It does, and they're broken in that specific way.
<kaustuv>
url for the answers?
<wsmith84>
I mean, it compiles and all, but if you try to use those modules, you won't be able to instantiate them.
<wsmith84>
Just mouse over the words in bold, they pop up.
<kaustuv>
not even for structure-level declarations?
<hcarty>
thelema: I don't do that either
<thelema>
well, for structure level function declarations I do.
<thelema>
the contents of a multiline function get indented. But otherwise, no.
<thelema>
well, maybe all multi-line lets (content of let is multi-line) gets indented
<kaustuv>
I don't indent a sequence of let ... ins and don't use ; between them (i.e., change them to let _ = ... in)
<thelema>
kaustuv: you mean [let () = ... in], no?
<kaustuv>
let _ = is more general and shuts up the type checker if the right hand side is not of type unit.
* thelema
wants to know when he's throwing away a value
<hcarty>
kaustuv: let _ = ... can also hide some unfortunate bugs
<mrvn>
kaustuv: which is a bad thing
<hcarty>
I definitely use ; when useful, but ignore (...) seems a better route for throwing away a value if it's absolutely needed
<kaustuv>
I often need to throw away non unit values. The only possible bugs are from incomplete function applications, which I honestly encounter once in a blue moon.
* thelema
agrees on ignore()
<kaustuv>
Besides, ignore() doesn't help me spot incomplete applications any better
ztfw` has quit [Remote closed the connection]
<hcarty>
kaustuv: It does it you otherwise use ; or let () = ...
<thelema>
that's true, but ignore is so big, I avoid using it, and end up with less situations where the compiler doesn't catch incomplete applications
<hcarty>
s/it/if/
<mrvn>
too bad you can't say 'a constraint 'a <> 'b -> 'c
<kaustuv>
mrvn: why would you need such a constraint?
<mrvn>
To say that 'a may not be a partial application
<kaustuv>
I think (conjecture) that if a term can detect whether its polymorphic argument is a function or not then you can construct a case where type inference is equivalent to the halting problem.
<mrvn>
kaustuv: why? Worst case it says the constrained is undecidable and the user needs to type it.
<thelema>
mrvn: it's important that type inference be decidable
<mrvn>
thelema: often enough you need to help it
<mrvn>
like let x = fun _ -> raise Foo
<thelema>
true, but the times you need to help it have to be clearly spelled out.
<thelema>
'a -> 'b
<mrvn>
which gives an error as module
<mrvn>
You can say 'a constraint 'a = 'b -> 'c, right? The negative would be the same.
<kaustuv>
"The functional programming community needs to get out of its Lisp/ML/Haskell rut and move on." (seen on http://ln-s.net/39cb )
<kaustuv>
apparently ocaml is less popular than "I hate FP"
<thelema>
why do people like significant white space?
<mrvn>
thelema: letfoox=x+1
wsmith84 has quit [Read error: 60 (Operation timed out)]
<thelema>
by significant, I mean that there's a difference between \t and \t\t
<thelema>
(or the equivalent in spaces)
<mrvn>
thelema: you must love python
<thelema>
mrvn: not at all
<thelema>
well, not as far as its whitespace goes
<mrvn>
thelema: your irony detector is faulty
tty56 has quit []
* thelema
checks it... oops, I had left it off to save battery life
<palomer>
whoa! different fonts take different times to blit
<palomer>
(or rather, to render)
<mrvn>
And that surprises you?
<palomer>
yes
Ariens_Hyperion has joined #ocaml
<thelema>
palomer how much of a difference are you seeing? 5% 2x?
stolenKadaver has joined #ocaml
<stolenKadaver>
that Jon Harrop guy sure gives Ocaml a bad rep
stolenKadaver has left #ocaml []
Camarade_Tux has quit ["Leaving"]
<palomer>
thelema, 5x
<palomer>
my university library carries harrop's F# for scientist book
AxleLonghorn1 has joined #ocaml
<thelema>
palomer: yay for jon
<palomer>
a 5x difference is huge for me
<palomer>
actually, scratch that
<palomer>
probably a 2.5x difference
<palomer>
still, it was the difference between unusable to perfectly usable
kaustuv has quit ["ERC Version 5.3 (IRC client for Emacs)"]
<thelema>
which two fonts?
Skolem has quit [hubbard.freenode.net irc.freenode.net]
dav has quit [hubbard.freenode.net irc.freenode.net]
lutter has quit [hubbard.freenode.net irc.freenode.net]
bebui has quit [hubbard.freenode.net irc.freenode.net]
gl has quit [hubbard.freenode.net irc.freenode.net]
Ariens_Hyperion has quit [hubbard.freenode.net irc.freenode.net]
komar_ has quit [hubbard.freenode.net irc.freenode.net]
Amorphous has quit [hubbard.freenode.net irc.freenode.net]
mellum has quit [hubbard.freenode.net irc.freenode.net]
patronus has quit [hubbard.freenode.net irc.freenode.net]
Yoric[DT] has quit [hubbard.freenode.net irc.freenode.net]
det_ has quit [hubbard.freenode.net irc.freenode.net]
smimou_ has quit [hubbard.freenode.net irc.freenode.net]
\xs has quit [hubbard.freenode.net irc.freenode.net]
delroth has quit [hubbard.freenode.net irc.freenode.net]
gildor has quit [hubbard.freenode.net irc.freenode.net]
rumbleca has quit [hubbard.freenode.net irc.freenode.net]
sbok has quit [hubbard.freenode.net irc.freenode.net]
Ori_B has quit [hubbard.freenode.net irc.freenode.net]
munga has quit [hubbard.freenode.net irc.freenode.net]
prigaux has quit [hubbard.freenode.net irc.freenode.net]
mfp has quit [hubbard.freenode.net irc.freenode.net]
steg has quit [hubbard.freenode.net irc.freenode.net]
mattam has quit [hubbard.freenode.net irc.freenode.net]
brendan has quit [hubbard.freenode.net irc.freenode.net]
acatout has quit [hubbard.freenode.net irc.freenode.net]
haelix_ has quit [hubbard.freenode.net irc.freenode.net]
mrvn has quit [hubbard.freenode.net irc.freenode.net]
bjorkintosh has quit [hubbard.freenode.net irc.freenode.net]
Mr_Awesome has quit [hubbard.freenode.net irc.freenode.net]
javax has quit [hubbard.freenode.net irc.freenode.net]
r0bby has quit [hubbard.freenode.net irc.freenode.net]
Fullma has quit [hubbard.freenode.net irc.freenode.net]
palomer has quit [hubbard.freenode.net irc.freenode.net]
mbishop has quit [hubbard.freenode.net irc.freenode.net]
olegfink has quit [hubbard.freenode.net irc.freenode.net]
ulfdoz_ has quit [hubbard.freenode.net irc.freenode.net]
bartiosze has quit [hubbard.freenode.net irc.freenode.net]
oof has quit [hubbard.freenode.net irc.freenode.net]
hto has quit [hubbard.freenode.net irc.freenode.net]
bacam has quit [hubbard.freenode.net irc.freenode.net]
authentic has quit [hubbard.freenode.net irc.freenode.net]
totom has quit [hubbard.freenode.net irc.freenode.net]
bzzbzz has quit [hubbard.freenode.net irc.freenode.net]
hcarty has quit [hubbard.freenode.net irc.freenode.net]
_zack has quit [hubbard.freenode.net irc.freenode.net]
slash_ has quit [hubbard.freenode.net irc.freenode.net]
mishok13 has quit [hubbard.freenode.net irc.freenode.net]
pants1 has quit [hubbard.freenode.net irc.freenode.net]
mjonsson has quit [hubbard.freenode.net irc.freenode.net]
ozzloy has quit [hubbard.freenode.net irc.freenode.net]
AxleLonghorn1 has quit [hubbard.freenode.net irc.freenode.net]
monadic_kid has quit [hubbard.freenode.net irc.freenode.net]
jknick has quit [hubbard.freenode.net irc.freenode.net]
Pepe_ has quit [hubbard.freenode.net irc.freenode.net]
ReinH has quit [hubbard.freenode.net irc.freenode.net]
bohanlon has quit [hubbard.freenode.net irc.freenode.net]
jedai has quit [hubbard.freenode.net irc.freenode.net]
holgr has quit [hubbard.freenode.net irc.freenode.net]
Asmadeus has quit [hubbard.freenode.net irc.freenode.net]
tab has quit [hubbard.freenode.net irc.freenode.net]
Hadaka has quit [hubbard.freenode.net irc.freenode.net]
xevz has quit [hubbard.freenode.net irc.freenode.net]
jlouis has quit [hubbard.freenode.net irc.freenode.net]
kelaouchi has quit [hubbard.freenode.net irc.freenode.net]
tarbo2 has quit [hubbard.freenode.net irc.freenode.net]
Demitar has quit [hubbard.freenode.net irc.freenode.net]
jeanbon has quit [hubbard.freenode.net irc.freenode.net]
petchema_ has quit [hubbard.freenode.net irc.freenode.net]
flux has quit [hubbard.freenode.net irc.freenode.net]
ppsmimou has quit [hubbard.freenode.net irc.freenode.net]
tsuyoshi has quit [hubbard.freenode.net irc.freenode.net]
gim has quit [hubbard.freenode.net irc.freenode.net]
ski__ has quit [hubbard.freenode.net irc.freenode.net]
tomaw has quit [hubbard.freenode.net irc.freenode.net]
aij has quit [hubbard.freenode.net irc.freenode.net]
hlab has quit [hubbard.freenode.net irc.freenode.net]
mal`` has quit [hubbard.freenode.net irc.freenode.net]
jeremiah has quit [hubbard.freenode.net irc.freenode.net]
deech has quit [hubbard.freenode.net irc.freenode.net]
ertai has quit [hubbard.freenode.net irc.freenode.net]
TaXules has quit [hubbard.freenode.net irc.freenode.net]
sgnb has quit [hubbard.freenode.net irc.freenode.net]
l_a_m has quit [hubbard.freenode.net irc.freenode.net]
AxleLonghorn1 has joined #ocaml
Ariens_Hyperion has joined #ocaml
slash_ has joined #ocaml
monadic_kid has joined #ocaml
jeremiah has joined #ocaml
mjonsson has joined #ocaml
jeanbon has joined #ocaml
Fullma has joined #ocaml
javax has joined #ocaml
komar_ has joined #ocaml
Amorphous has joined #ocaml
deech has joined #ocaml
Yoric[DT] has joined #ocaml
det_ has joined #ocaml
bzzbzz has joined #ocaml
hlab has joined #ocaml
smimou_ has joined #ocaml
mal`` has joined #ocaml
hcarty has joined #ocaml
ulfdoz_ has joined #ocaml
ozzloy has joined #ocaml
palomer has joined #ocaml
Mr_Awesome has joined #ocaml
l_a_m has joined #ocaml
bjorkintosh has joined #ocaml
mrvn has joined #ocaml
r0bby has joined #ocaml
lutter has joined #ocaml
dav has joined #ocaml
bebui has joined #ocaml
Skolem has joined #ocaml
gl has joined #ocaml
ReinH has joined #ocaml
\xs has joined #ocaml
xevz has joined #ocaml
flux has joined #ocaml
pants1 has joined #ocaml
olegfink has joined #ocaml
mfp has joined #ocaml
patronus has joined #ocaml
mellum has joined #ocaml
acatout has joined #ocaml
authentic has joined #ocaml
Pepe_ has joined #ocaml
Demitar has joined #ocaml
delroth has joined #ocaml
tarbo2 has joined #ocaml
mbishop has joined #ocaml
tab has joined #ocaml
sgnb has joined #ocaml
jknick has joined #ocaml
rumbleca has joined #ocaml
hto has joined #ocaml
TaXules has joined #ocaml
mishok13 has joined #ocaml
Ori_B has joined #ocaml
steg has joined #ocaml
mattam has joined #ocaml
brendan has joined #ocaml
gildor has joined #ocaml
sbok has joined #ocaml
prigaux has joined #ocaml
munga has joined #ocaml
haelix_ has joined #ocaml
bacam has joined #ocaml
tsuyoshi has joined #ocaml
ski__ has joined #ocaml
Hadaka has joined #ocaml
ppsmimou has joined #ocaml
tomaw has joined #ocaml
petchema_ has joined #ocaml
gim has joined #ocaml
Asmadeus has joined #ocaml
jlouis has joined #ocaml
aij has joined #ocaml
holgr has joined #ocaml
bohanlon has joined #ocaml
jedai has joined #ocaml
kelaouchi has joined #ocaml
oof has joined #ocaml
totom has joined #ocaml
bartiosze has joined #ocaml
ertai has joined #ocaml
thelema has quit [Remote closed the connection]
monadic_kid has quit ["Leaving"]
ztfw has joined #ocaml
thelema has joined #ocaml
T_S_ has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
ztfw has quit [Remote closed the connection]
wsmith84 has joined #ocaml
AxleLonghorn1 has left #ocaml []
lief has joined #ocaml
<palomer>
how do you divide a utf8 string into a list of characters?
<palomer>
http://pastebin.com/m939c58 <-- extracting a number out of a Sdlkey.t (if anyone is interested.) for some reason I find this function cool
komar_ has quit [Read error: 113 (No route to host)]