jeremiah has quit [Read error: 104 (Connection reset by peer)]
wsmith84 has joined #ocaml
vuln has joined #ocaml
jeremiah has joined #ocaml
Yoric[DT] has joined #ocaml
<thelema>
mrvn: yes, that seems like a bad #define
<thelema>
hi Yoric[DT]
<mrvn>
preprocessing is such a flawed concept
<Yoric[DT]>
hi
<mrvn>
hi Yoric[DT]
<Yoric[DT]>
How do you do?
<mrvn>
me? fine.
<thelema>
mrvn: I agree. Source transformations that aren't ... sensitive to the underlying program structure are the devil.
det has quit [Remote closed the connection]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<thelema>
I don't mind user-defined code generation, but it's got to be more like forced-inline function definition
det has joined #ocaml
<thelema>
compile-time vs. runtime
<mrvn>
It has to know the grammar
<mrvn>
this code is getting complicated. ocaml->stub->libfuse->stub->ocaml->stub->libfuse and then it returns.
<thelema>
yes, but not just that - camlp4 knows the grammar, and I still consider it severly flawed because it's pre-processing - what people try to do with it needs to have access to better compiler internals to get done properly
* thelema
wonders how perl6's syntax extensibility works
<thelema>
One thing that's missing from pre-processors is scope. But it's difficult to have scope when your transformation is entirely outside the source tree.
jeremiah has joined #ocaml
jeremiah has quit [Connection reset by peer]
_zack has quit ["Leaving."]
wsmith84 has quit [Read error: 110 (Connection timed out)]
jeremiah has joined #ocaml
Ched has joined #ocaml
<thelema>
Yoric[DT] do you have any thoughts on the submitted code?
<thelema>
(I'm just happy that people are submitting code. I just need to get into a workflow for dealing with it)
<Yoric[DT]>
Yeah, me too.
<Yoric[DT]>
At the moment, I'm just too tired to look at it, unfortunately.
wsmith84 has joined #ocaml
<thelema>
n/p. any thoughts on ounit?
<thelema>
more specifically, any objections to including it?
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<thelema>
also, I'd like your thoughts on making sexplib an optional dependency...
<thelema>
if you have any. if too tired, I'll catch you another time
* thelema
should probably post to the mailing list these ideas for async discussion
<Yoric[DT]>
I believe that we should depend on oUnit.
<Yoric[DT]>
Whether this is for 1.0 or post-1.0 is an open question.
<Yoric[DT]>
If we can provide oUnit features in 1.0, then by all means we should go ahead.
<thelema>
hmm... I can make an argument for either way. Since there's enough push already to use it in our tests...
<thelema>
what do you mean by oUnit features?
<thelema>
warren's threatened extensions to oUnit?
<thelema>
or just including oUnit into the batteries mega-module?
<Yoric[DT]>
Batteries mega-module.
<thelema>
that we can do.
<Yoric[DT]>
Plus whatever changes to the interface are required to get it to use/provide enumerations and I/O.
janshei_ has joined #ocaml
* thelema
looks at oUnit again to see where that makes sense
<thelema>
hmm, it's already in my "required" pool for compiling batteries, I bet one of batteries' deps uses it for tests
<Yoric[DT]>
Is it?
<thelema>
I compile from scratch, and I've recently put all the required modules for batteries in one folder. ounit's there.
<Yoric[DT]>
At the moment, I'd be happy to get rid of bug 153.
<thelema>
me too. That seems kind of a blocker for 1.0
<thelema>
but there wasn't any response on the mailing list about the problem
<Yoric[DT]>
Yeah.
<thelema>
at least no useful one.
<Yoric[DT]>
Well, I believe I know how to solve it.
<Yoric[DT]>
But it's work
<Yoric[DT]>
And I don't have much time to do it.
<thelema>
how?
<Yoric[DT]>
Perhaps next week, during my 4-5h of train.
<thelema>
I don't get this part: * replace any occurrence of Extlib.Foo with the corresponding
<thelema>
directory in Batteries
<Yoric[DT]>
Yeah, I should have written "module path" instead of "directory".
<thelema>
ah. that makes more sense.
<Yoric[DT]>
Now, the issue is generating batteries.mli .
<thelema>
if there were a (dep-ordered) master list of all the modules in batteries' interface, it might suffice to go through them in that order, grabbing the associated .mli and concatenating
<Yoric[DT]>
Nah, you also need to do some rewriting.
<thelema>
some magic-comments might suffice as generalized instructions for rerwiting names
<Yoric[DT]>
Yeah, but magic-comments need to be parsed first...
<thelema>
?? I'm imagining a pass to concatenate, a pass to find rewrite-comments and a thord to do the rewriting
<Yoric[DT]>
Plus you can't just grab the associated .mli, sometimes you have to extract some of the contents of the .mli (e.g. you don't want extString.mli, you only want the contents corresponding to module ExtString.String)
<thelema>
hmm, that would make it harder... you'd really have to work from the batteries mega-module too.
jeremiah has joined #ocaml
<Yoric[DT]>
Yep.
<Yoric[DT]>
Now, that mega-module doesn't have to be a .ml .
<Yoric[DT]>
It can be some custom format which specifies
<Yoric[DT]>
* where to find the .mli
<mrvn>
thelema: async liken I/O? libaio based?
<Yoric[DT]>
* what subset of the .mli to take
<Yoric[DT]>
* what to rewrite
<thelema>
mrvn: async like mailing list vs. sync like IRC
<thelema>
hmm, it might be interesting having such a control file generate batteries.ml
<Yoric[DT]>
Well, this file could be used to generate batteries.ml, too.
<thelema>
otherwise there'd be sync problems
* Yoric[DT]
will return.
<thelema>
thanks
<Yoric[DT]>
(still, it's a pain to write)
<mrvn>
Yoric[DT]: Is that a promise or a thread? :)
<thelema>
hmm, it doesn't have to run on users computers - it can be part of preparing the distribution, so it doesn't have to be in ocaml. (I'm imagining a perl solution - quick and dirty works well there)
<mrvn>
please no perl
<flux>
:-)
* thelema
wonders if he'll get kicked off the team for suggesting that
<mrvn>
thelema: I wouldn't find that odd at all :)
* thelema
wonders if sexplib can handle this
janshei has quit [Read error: 110 (Connection timed out)]
<thelema>
all we really need is a sufficiently powerful, human editable config format that can be slurped into a data structure, and used to control the process...
<thelema>
step 1: auto-generating batteries.ml
janshei_ is now known as janshei
<thelema>
but before that, review warren's code, and before that... Lunch!
<mrvn>
dinner
<Yoric[DT]>
mrvn: it's a monad :)
ttamttam has left #ocaml []
Alpounet has quit ["Ex-Chat"]
<wsmith84>
hey guys quick question
<thelema>
ask
itewsh has joined #ocaml
<wsmith84>
I saw that several modules have module.mli and moduleLabels.mli versions
<wsmith84>
some of these are actually QUITE similar.
<wsmith84>
this is in stdlib, not in batteries
<wsmith84>
what's the story there?
<thelema>
yes, stdlib does two modules, batteries does one module, and a submodule with labels
<thelema>
ArrayLabels vs. Array.Labels
<wsmith84>
but... why? (this is a real newbie question)
<wsmith84>
the "labels" version seem to have more type annotations
<wsmith84>
(that's what I see when I diff 'em )
<flux>
wsmith84, you're asking why the labels version exists at all?
<wsmith84>
yep.
<thelema>
yes, that's why. Many people want labeled versions so their code is more readable
<flux>
also, it can be useful when partially applying functions, at times
<wsmith84>
oh... so why not just produce everything the "labels" way?
<thelema>
i.e. it has "embedded comments" saying that this argument is the length and this one is the offset
<flux>
disclaimer: I haven't used them
janshei_ has joined #ocaml
<flux>
labeled functions aren't that compatible with non-labeled functions for one
<flux>
there can be minor invonvenience when dealing with higher order functions involving both of them
<thelema>
if everything had labels, we'd end up with things like [print_int ~item:2]
<wsmith84>
flux: are you saying there's actually two different compiled versions of the functions?
<flux>
thelema, well not really, because you don't need to use labels always
<thelema>
no, just two different interfaces to the same function
<wsmith84>
so using either *does* get linked to the same implementation then, right?
* thelema
has had problems with labels and partial application
<thelema>
yes for batteries, probably yes for stdlib
<wsmith84>
thelema: I see. I guess it's a weakness in the language that it can't accomodate both types of argument calling with a single declaration syntax.
<thelema>
the language wasn't originally designed for labels, it's a fabulous hack that Jacques garrigue pulled off to include them
<wsmith84>
I see...
<flux>
it is difficult to say if they could've been integrated better
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<wsmith84>
Here, my first OCaml program, any comments welcome:
<flux>
thelema, so I take it you don't like labeled/optional arguments, or just not the way they've been implemented?
<thelema>
your parse_args function is quite... byzantine. I think it basically does Array.to_list
<wsmith84>
well, of course a lot of dicking around at the top-level with tuareg-mode :-)
angerman has quit []
<thelema>
I love labeling arguments, I just have some syntactic problems with their implementation in ocaml
<wsmith84>
i like that, Byzantine
<wsmith84>
I have yet to install batteries, I admit
<wsmith84>
I saw it has an optparse module
<thelema>
hah! you implemented the schwartzian transform. I was going to write that for batteries myself.
* thelema
likes
<wsmith84>
thelema: actually, it should do more than that, if Arg is smart about blowing up if you specify invalid options.
<flux>
wsmith84, you've bumped into an annoying feature in ocaml when writing read_data_file
<flux>
wsmith84, your loop isn't actually tail recursive..
<wsmith84>
I did, but it's a little more subtle, than that, the list I sort is actually not the original, it's derived from it.
alexyk has joined #ocaml
<wsmith84>
flux: because of the exn handler?
<thelema>
usually we'd write "End_of_file -> List.rev accum"
<wsmith84>
I see.
<wsmith84>
Here's another question:
<flux>
wsmith84, yes, because of exn handler
<wsmith84>
it happens so very often in func langs that you build a list from another one and in the end end up reversing the accumulator to produce the result
<wsmith84>
i mean, i see it all the time
<thelema>
yes
<wsmith84>
a pattern would be to provide a language level feature to keep a ptr to the tail and update the last cons cell directly
<wsmith84>
wouldn't it be worthwhile and if so why hasn't it been done?
<thelema>
batteries does that internally in its implementation of lots of these functions. It has to cheat and turn a mutable list into an immutable list.
AxleLonghorn has joined #ocaml
<wsmith84>
i spoke with a well-versed in func langs friend about it yesterday, he said some compilers (he mentioned SML IIRC) will compile a recursive call like that correctly, e.g. ending with x :: loop ...
<thelema>
you can append to the tail of a mutable list, but the standard immutable lists can only be prepended.
<wsmith84>
thelema: did you have to define a new data type for this?
<thelema>
doing it like x :: loop ends up filling the stack, possibly to overflow
<wsmith84>
just send a ptr
<thelema>
wsmith84: yes
<wsmith84>
thelema: well apparently some compilers can make those tail recursive, by discovering the pattern at compile time, and creating the "next" cons cell before inserting the goto for the next iteration.
<thelema>
(I have to give credit to the extlib folks, it's really their code, and they give credit to Garrigue.)
<thelema>
nice trick. In the end, it really doesn't save much time or effort. I've benchmarked various strategies, and up to tens of thousands of list elements, they run the same.
* thelema
tries to find the graphs
<flux>
wsmith84, one principle has been outspoken at times: optimizations of the compiler shouldn't be surprising or difficult to see. although, I would like to see that kind of cons-tc-optimization :)
<wsmith84>
flux: I'll ask him for a reference paper on it and post.
<mrvn>
For x :: loop to be turned into tai recursion you have to 1) construct the :: ahead of time with a dummy, 2) pass the :: as final return value down the recursion and 3) pass the dummy as 'use this as your return value'. That is quite a bit of compiler optimization.
<mrvn>
And the compiler has to cheat and make the list mutable like batteries does.
alexyk has quit []
<thelema>
yes, ocaml is great for having the performance of the compiled code correspond very strongly with the performance of the "code-as-written", so there's not a lot of surprise optimizations that are triggered in "just the right circumstances"
<mrvn>
If a function could be flagged as "not looking inside the argument" the same could be done to pretty much any such function call, not just ::
<flux>
still, list processing could be said to be the core of functional programming, having nice facilities for it a good thing to have
<mrvn>
flux: even with the copying and revs list processing is already blindingly fast compared to other languages.
<flux>
mrvn, note also the amount of garbage it (build+List.rev) produces. I think that can add up.
<mrvn>
flux: there is a sharp drop in speed if you exceed the minor heap size.
<flux>
actually I had one program that barely ran realtime (ocaml, ppro 200) and gc time was a big issue there
<flux>
tuning gc parameters helped a lot though
<thelema>
"not looking inside the argument" sounds a lot like "having type 'a" to me.
<flux>
but the annoying thing was that if I would've had had a region memory manager, I could've just dropped everything created after one iteration of a loop
jeremiah has joined #ocaml
<mrvn>
thelema: let foo fn x y = fn x y
<flux>
(the program was basically: while true do draw (Unix.gettimeofday ()); done)
<mrvn>
thelema: ('a -> 'b -> 'c) -> 'a -> 'b
<mrvn>
thelema: Is that looking into the arg or not?
<thelema>
foo doesn't look into x.
<mrvn>
thelema: it does if fn does.
<thelema>
yes
janshei has quit [Connection timed out]
<mrvn>
thelema: But you might be right. If fn in turn has 'a types then it isn't looking into the arg.
janshei_ is now known as janshei
<Yoric[DT]>
thelema: I'm starting to set down a file format which will be used to generate a .ml and a .mli
* Yoric[DT]
is wondering whether that file format should be "mostly .ml with a few custom comments".
<thelema>
Yoric[DT]: is there something generic like yaml or possibly sexplib that we could use?
<Yoric[DT]>
For that purpose?
<thelema>
yes
<mrvn>
thelema: Problem is if the fn is also an argument to the recursion then you can't decide. Should the compiler then create a tail recursive and normal flavour?
janshei has quit ["J'y trouve un goût d'pomme."]
<thelema>
all we really need is the ability to nest associative arrays of strings
chickenzilla has joined #ocaml
<thelema>
string -> array or string
chickenzilla has quit [Client Quit]
<mrvn>
thelema: where is the problem? Just nest them
<wsmith84>
Another newbie question: if I have two record data types with the same field names, is there a way to create one or the other via an annotation? by default I saw that what gets created in the top-level is the last one defined.
<mrvn>
wsmith84: 1) put them in different namespaces (modules)
<mrvn>
wsmith84: 2) write an accessor function for each with different names
janshei has joined #ocaml
<thelema>
Yoric[DT] that's the one. Think it'd suffice?
<mrvn>
wsmith84: otherwise you arescrewed. The 2nd one shadows the first.
<wsmith84>
I see. Nothing even like Erlang's #typename{... }
<thelema>
wsmith84: another important limitation on ocaml - record firld names are scoped to the module, not to the record.
<thelema>
*field
<Yoric[DT]>
thelema: mmmmhhh.....
<mrvn>
wsmith84: type foo = { x : int } let foo_x foo = foo.x let make_foo x = { x = x } type bar = { x : int } let bar_x bar = bar.x let make_bar x = { x = x }
<wsmith84>
ouf
<thelema>
Yoric[DT]: I haven't use it myself, and looking at the spec, it does seem overkill...
<Yoric[DT]>
thelema: yeah
<wsmith84>
Allright, while I've got some attention, one more: is there a way to someone check whether the compiler has made the tail-recursive optimization on a specific function?
<wsmith84>
(other than spitting and having to parse the intermediate code)
<mrvn>
The problem with records with identical labels is that the type system uses the labels to determin the record type.
<wsmith84>
mrvn: thx.
Amorphous has quit [Read error: 110 (Connection timed out)]
<mrvn>
wsmith84: if you wrote it tail recursive then it is. otherwise not.
<wsmith84>
mrvn: right. Seems to me requiring the record name on creation would solve that design issue.
<mrvn>
wsmith84: and need much more typing.
<wsmith84>
well much... dunno... it's one evil for another i suppose.
<mrvn>
It is bad enough you have to write the module path each time.
<thelema>
Yoric[DT]: godi-inifiles?
<wsmith84>
hahah indeed :-)
<mrvn>
let get_x foo = foo.MyModule.Fooish.data.MyModule.Fooish.x
<Yoric[DT]>
thelema: for the moment, I'm thinking about using .ml syntax with custom comments
<mrvn>
After .MyModule.Fooish.data the type is clear so why does one have to repeat the module path again?
<wsmith84>
Is there any concept of co-routines in Caml/ML?
<Yoric[DT]>
wsmith84: no
<mrvn>
wsmith84: you can easily do continuation
<thelema>
Yoric[DT]: is the info on which batteries module matches which extlib module going to be duplicated in the comments, or are we going to have to be very careful with this file's syntax?
<wsmith84>
(These are now pretty ubiquitous in Python, via what they call "generators", and they're used all over the place to define iterators, pretty neat actually)
Amorphous has joined #ocaml
<wsmith84>
A good example somewhere of continuation-passing style Caml?
<Yoric[DT]>
wsmith84: oh, if you mean generators, we have enumerations.
<Yoric[DT]>
But co-routines are much more powerful than this.
<Yoric[DT]>
And there are no co-routines in OCaml.
<Yoric[DT]>
Although you can mostly encode them with continuations (exceptions in co-routines may complicate the task, though).
<wsmith84>
well the generators don't evaluate fully before returning, IYSWIM
<mrvn>
Yoric[DT]: I have to look at them at some point. I need them for my fuse filesystem.
<Yoric[DT]>
mrvn: enumerations?
<wsmith84>
the activation record is kept for the next iteration and code only resumes when you call "next()" for the next item
<Yoric[DT]>
wsmith84: sure.
<mrvn>
Yoric[DT]: I need to iterate over a range of keys in a B-Tree.
<Yoric[DT]>
wsmith84: the difference between a generator/iterator and a co-routine is the same as the difference between [return] and [throw]: it can traverse several layers of stack.
itewsh has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
mrvn: well, don't worry, it's easy.
<wsmith84>
I suppose in that sense Python's generators aren't real co-routines, they only work one level deep.
<Yoric[DT]>
wsmith84: yep.
<wsmith84>
Though there is a hack somewhere else called "greenlets" which does that.
itewsh has joined #ocaml
<wsmith84>
Anyway, thx, I'll look at enumerations.
<wsmith84>
I suppose I could do some of that with delay/force.
<mrvn>
Yoric[DT]: it also might have to readblocks from disk, which means fire of a request, register a callback where to continue and return so something else can run.
<thelema>
good. we just had to get what we were both thinking on paper (well, pastebin) correctly.
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<thelema>
one difficulty is that this .ml file isn't necessarily in dep order, no?
<Yoric[DT]>
Yes.
<Yoric[DT]>
I'll extract the list of .mli, generate them if necessary, let ocamldep and ocamlbuild compute the dependencies and then attempt to sort topologically.
* thelema
doesn't know whether that's 'oui' or 'si'
<Yoric[DT]>
:)
<Yoric[DT]>
"Indeed"
<thelema>
really? you think that's worth automating? don't we already have dep-sorted lists in our .mlpack files?
AxleLonghorn has left #ocaml []
AxleLonghorn has joined #ocaml
<thelema>
(and can this same method get rid of those .mlpack files?)
<Yoric[DT]>
Well, this could get us rid of those .mlpack files.
* thelema
likes.
<Yoric[DT]>
But first I'm going to attempt to solve the batteries.mli problem before checking whether .mlpack files can be obsoleted once and for all.
<thelema>
of course.
<thelema>
priorities
<Yoric[DT]>
Mmmmhhh....
<thelema>
hmm, extracting submodules from .mli files doesn't sound like fun.
<Yoric[DT]>
This file format doesn't specify how we should substitute.
<Yoric[DT]>
No, it doesn't.
<thelema>
I guess it's not too bad, just make some code cleanliness assumptions
<thelema>
how to substitute? module X = Y doesn't indicate that all Y.foo -> X.foo?
<Yoric[DT]>
No, I mean the replacement of InnerIO.* with IO.* .
<Yoric[DT]>
In modules which use InnerIO.
<Yoric[DT]>
That looks like a work for regexp.
<thelema>
maybe a global "special comment" at the beginning to do that.
<Yoric[DT]>
(we can't use camlp4 here because that would screw up with comments)
<thelema>
(*% InnerIO -> IO *)
* thelema
wouldn't suggest camlp4 for this.
<Yoric[DT]>
Mmmmmhhhh....
<Yoric[DT]>
Yeah, special comment it is.
<thelema>
(*% MODULE InnerIO -> IO *)
<Yoric[DT]>
(and regexp :))
<Yoric[DT]>
Of course, if we want depsort, this probably requires generating bogus .mli in which stuff has been replaced.
* thelema
thinks about ropes... string substitutions on big files will churn either CPU to realign or GC to reallocate maybe realigning is the way to go.
<Yoric[DT]>
A bit too low-level for me for the moment :)
<Yoric[DT]>
(especially since that's going to happen in myocamlbuild.ml )
<thelema>
if it's noticeably slow, I have a better implementation in mind.
<Yoric[DT]>
I haven't quite reached that stage yet.
<Yoric[DT]>
For the moment, I'm trying to determine which files need to be generated, patched, read, etc.
* Yoric[DT]
wonders whether it's any easier to use ocamldep or to rewrite his own dependency extractor.
<mrvn>
Yoric[DT]: ocamldep is easier to maintain
<Yoric[DT]>
Yes, but the problem is that I need to generate files that ocamldep can understand.
<Yoric[DT]>
So they must be called .mli, for instance.
<Yoric[DT]>
Which means that I need to maintain two sets of .mli files, the ones required to compile for instance extlib.cm* and the ones required to compile batteries.cm* .
<Yoric[DT]>
I'll need to give them different names.
<mrvn>
the pain of meta modules.
<Yoric[DT]>
yep
janshei has quit [Remote closed the connection]
janshei has joined #ocaml
itewsh has quit [Connection timed out]
itewsh has joined #ocaml
<thelema>
Yoric[DT] a simple prefix sounds like it'd work... meta-xxx
seafood has quit []
<mrvn>
Yoric[DT]: wouldn't it suffice to have "open ExtLib.String" kind statements?
Snark has quit ["Ex-Chat"]
<mrvn>
From ExtLib.mli get the String module.
jado has joined #ocaml
<mrvn>
or "inherit ExtLib.String"
<jado>
hi, i used to use Pcre like that : #use "topfind" then #require "pcre" in order to use the regexp in toplevel mode. but what if i want to compile an executable ?
bacam has quit [Read error: 110 (Connection timed out)]
<flux>
do note that you need that -linkpkg when you're producing binaries. if you're producing object files (.cmo, .cmx) by using the -c -flag, it is not used
<jado>
that seems complicated
<jado>
can't i just use the pcre/pcre.cma in the ocaml lib ?
<jado>
?
janshei is now known as chickenzilla
<flux>
you can
<flux>
but the ocamlfind approach has the added benefit that it works with any library, without requiring the extra effort of listing dependencies
<flux>
also ocamlfind is the one you're doing in the toplevel. "topfind" is provided by ocamlfind.
<jado>
ok
<flux>
I'm not even sure how one would do it without ocamlfind because it's been so long since I've done it, but it's possibly this way: ocamlc -I +pcre pcre.cma -o foo foo.ml
<jado>
but what if the person i will send my code does not have pcre installed ?
<flux>
well, then you want to send him the binary?
wsmith84 has quit [Read error: 110 (Connection timed out)]
<flux>
he cannot compile it without pcre
<flux>
(if by pcre you mean the pcre ocaml library)
<jado>
what if his pc is 64bits and mine 32 ?
<flux>
if it's a linux system it's possibly configured to run 32 binaries also. I don't know about that really.
<mrvn>
flux: hardly.
itewsh has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
<mrvn>
Can ocaml even compile 32bit or 64bit code with a single binary?
<flux>
I doubt that
<thelema>
mrvn: import foo wouldn't suffice, because of the rewriting needed... and besides, I dunno if import even working for mli
<flux>
I wonder if anything else except perhaps OSX supports that?
<thelema>
no, one kind of code at a time.
<thelema>
osx binaries are really a special kind of folder.
<mrvn>
thelema: the rewriter would do the importing.
<flux>
I think some big Unix supported that too..
<mrvn>
gcc does
<thelema>
mrvn: hmmm... we'd have to maintain the list of imports in dep order. If yoric can do this as he's planning, it'd lead to us not having to dep-order anything anymore
coastermaster has joined #ocaml
<mrvn>
I kind of hate this in-order limitation in ocaml. I see no reason why I can't have foo.ml need bar.mli and bar.ml need foo.mli.
<thelema>
they'd have to write the compiler so it'd process more than one input file and produce more than one output file.
<mrvn>
why?
<thelema>
I guess they could have a -drop-error-symbols, and produce as much as possible, and compile in multiple passes
<mrvn>
Parse in foo.mli, compile bar.ml
<mrvn>
Parse bar.mli, compile foo.ml
<thelema>
sorry, misread.
<thelema>
you can't do that now?
<flux>
hmph, apparently not even battery has that map-has-the-superset-of-set-operations -feature
<mrvn>
Nope. doesn't link as each *.mlo file needs the other before it.
<thelema>
I'm with you that it shouldn't need an account
Stefan_vK1 has joined #ocaml
<thelema>
min, max, choose, split?
<flux>
that should be it, yes
<flux>
actually I have function min_elt there, it would be better named min_key
<thelema>
agreed.
<mrvn>
isn't min_elt kind of standard?
<flux>
mrvn, well, for a map, wouldn't you call the stuff you put in 'key and value' or possibly even 'key and element'?
<thelema>
key, value
<mrvn>
key, value.
<flux>
min_elt could be understood to mean searching the smallest right-hand-value
<mrvn>
s/right-hand//
<thelema>
these maps are really just sets of (k,v) ordered by k
Demitar has quit [Remote closed the connection]
<mrvn>
What is min_elt? key or (key,value)?
<flux>
mrvn, key
<thelema>
so min_elt is kind of accurate since it returns (k,v), but I like min_key better because it emphasizes that it'll pick the one with the minimum key
<mrvn>
maybe min_key for key and min_elt for (key,value)
<coastermaster>
What does it mean when I get the error "File "bigint.ml", line 104, characters 11-141:" but there's only 89 characters in line 104
<flux>
oh, right, I forgot it returned the pair
<mrvn>
thelema: What if there are multiple entries for a key? Does it pick the minimum value?
<flux>
there aren't, in a map
<mrvn>
or the last entered one?
<flux>
when a value goes in, the previous binding goes out
<mrvn>
ok.
<thelema>
these maps aren't multi like the hashtables are.
<mrvn>
hashtbl is an array and maps are trees or not?
<thelema>
maps and sets are trees
<thelema>
hashtbl is an array, yes
<thelema>
I think an array of lists, even
<mrvn>
Just for information what kind of tree?
<mrvn>
thelema: yes, to allow for multiple values
<thelema>
hmm, some sort of splay tree if I remember correctly... h(l) - h(r) <=2
<Yoric[DT]>
mrvn: I don't understand your question
itewsh has quit [Read error: 60 (Operation timed out)]
<Yoric[DT]>
<mrvn> Yoric[DT]: wouldn't it suffice to have "open ExtLib.String" kind statements?
itewsh has joined #ocaml
<thelema>
mrvn's idea is to have a template for the batteries.mli file with lots of include/open statements and some magic comments to do the renaming
<thelema>
of course there'd be sync problems with this, but it might end up easier to filter into the final batteries.mli file
<Yoric[DT]>
Well, I don't see how that would be any easier.
<thelema>
you wouldn't have to deal with any dependency orderings or parsing the batteries.ml file
Stefan_vK has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has joined #ocaml
<coastermaster>
I'm trying to write a function that takes two int lists and multiplies them together for an arbitrary precision number library. The numbers are stored LSB first in chunks of three (i.e. the number 12345 is a list [345; 12]. The snippet of code I'm getting, as well as the error is at http://foobarbazquix.pastebin.com/d76efce34
AxleLonghorn has quit [Read error: 110 (Connection timed out)]
<thelema>
grr, split is going to take some work... I don't want to copy bal into extMap.ml
<thelema>
but I need it for join (needed by split)
kaustuv has joined #ocaml
Stefan_vK has joined #ocaml
<thelema>
I'm reviewing it now.
<sanguinev>
coastermaster: Is there any further structure to the numbers? I.e. will it always be 12345 == [345; 12], or is it 12345 == [345; 12] == [45; 123] ... ?
<coastermaster>
sanguinev: no, it will always be chunks of three (with the last int being shorter if need be)
chickenzilla is now known as kuracie
itewsh has quit [Read error: 60 (Operation timed out)]
itewsh has joined #ocaml
kuracie is now known as kylling
<jado>
which option can i use in order to make ocamlc not create object files ?
<mrvn>
jado: not -c
<mrvn>
coastermaster: use an existing library.
<mrvn>
coastermaster: or is it realy just for 96 bit ints?
<jado>
mrvn: ?
<mrvn>
jado: if you don't use -c you get a binary at the end
<jado>
yes but there are also objet files
<jado>
with the binary
<mrvn>
oh. ok. You can't I believe.
<mrvn>
delete them in your Makefile
<mrvn>
or write the makefile so it detects them as intermediate files and it will clean up itself.
Stefan_vK1 has quit [Read error: 110 (Connection timed out)]
<mrvn>
Should work for base <= sqrt(2^30 / <List.length))
<mrvn>
For bigger base you need to use int64
kylling is now known as Genelye
Genelye is now known as Oilo
<mrvn>
.oO(What? No comments on that beautifull piece of code? :)
<mrvn>
I think I have never done multi word integers with lists before.
<coastermaster>
mrvn: it's for an arbitrary length int
Oilo is now known as chickenzilla
<mrvn>
coastermaster: if this is for any real application then use libgmp
<coastermaster>
mrvn: it's a school assignment, so no libs allowed :)
<mrvn>
have you looked at my paste?
<mrvn>
does it haveto copy with negatives?
<mrvn>
s/haveto copy/have to cope/
itewsh has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
<coastermaster>
mrvn: yeah I'm reading it right now, and no it doesnt have to deal with negative numbers...the wrapper function for it will take care of it
chickenzilla is now known as Cthulhu
Cthulhu is now known as chickenzilla
jlouis has joined #ocaml
Alpounet has joined #ocaml
<mrvn>
using arrays would be much better though I think.
<mrvn>
Maybe even to the point of converting list to array
<mrvn>
hmm, or rev both input lists and do a nested fold_left.
chickenzilla is now known as PoneyRutilant
itewsh has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
PoneyRutilant has quit ["J'y trouve un goût d'pomme."]
<mrvn>
or rather more like one would do it with arrays.
<coastermaster>
mrvn: hmmm
<mrvn>
say I have 123*456. I calculate 3 * 456, then I calculate 2*4560 and add that to 912 from before and then 1*45600 and add it to 10488. And each loop calculates from the lowest digit to the highest and takes the overflow long for the ride.
<mrvn>
That way the intermediate result will never exceed base+base+base*base, so it works for base up to 2^15 on 32bit cpus.
<mrvn>
or 14 actually due to the sign bit.
<mrvn>
The first paste was how you do it by hand. First calculate 3*456, 2*4560, 1*45600 and then sum up the columns from the last digit to the first carrying the overflow.
<mrvn>
first paste is way cooler though, especially if you eliminate t1, t2, t4.
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
<mrvn>
coastermaster: Come up with a solution yet?
<coastermaster>
mrvn: I'm working on something, although right now I'm fixing bugs in the other parts of the program. Your pastes have given me some ideas tho
<coastermaster>
So thanks :-D
<mrvn>
coastermaster: You should have seen my mergesort implementation for lists I wrote for my functional programming course.
<coastermaster>
mrvn: my prof showed us an example mergesort....I don't know what it is about functional programming and me...we just don't seem to agree. Our last assignment was in Scheme and that was a disaster for me
<mrvn>
coastermaster: I mapped the list to a list of single element lists. Then I repeadatly merged them pairwise till it was [[list]] and then returned List.hd.
<coastermaster>
nifty
seafood has joined #ocaml
slash_ has quit ["leaving"]
Yoric[DT] has quit ["Ex-Chat"]
Alpounet has quit [Read error: 104 (Connection reset by peer)]