<thelema>
f[x]: how is no circular dependencies a feature? what bugs does it stop?
<f[x]>
order of initialization
<flux>
but the problem with ocaml is that even types cannot be defined in circular fashion across modules
<thelema>
in some cases, initialization is a problem with circular dependencies, sure.
<flux>
and types aren't initialized, so that's not an issue
<thelema>
I imagine this is detectable in general, or at least over-detectable, and warnings/errors issued
<flux>
obviously any solution for ocaml that would end up with uninitialized data would not be permittable
<f[x]>
circular types can be unsound I guess
<thelema>
sure.
<flux>
for one piece of software I had one module that incorporated a big list of types used by various modules, so that the class interfaces could refer to each other without additional jumping through hoops
<f[x]>
detectable -> whole program analysis
<thelema>
sometimes I would really appreciate being able to have spiral inter-module dependencies - module A = abc, module B = xyz, dependencies z -> c -> y -> b -> x -> a
<f[x]>
flux, looks like it a common approach, I've seen that often
_habnabit has joined #ocaml
<zorun>
flux: I actually used the same trick for a project
<thelema>
link-time analysis, and OCaml is already accused of whole-program analysis with its inliner
<thelema>
f[x]: OCaml could do use its value/function detection that it does for weak polymorphism, and if there's a cycle with a value in it, raise an error. This would allow strict functions (with no initialization) to depend on each other.
<f[x]>
between modules?
<f[x]>
this means exposing more in cmi files (much more)
dnolen_ has quit [Quit: dnolen_]
<thelema>
eventually, I hope.
<thelema>
yes, inter-module dependencies of a value would be exposed
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
<thelema>
this just means the initialization order of values would be the result of dep-sorting in case of conflict
<f[x]>
it will probably work in practice, but will it work in theory?
<thelema>
_habnabit: records are a solution to this
<thelema>
err, maybe not...
<thelema>
when you get a folding function out of your list, and apply it to the list of integers, what type should the result be?
<thelema>
despite you ignoring the result, it has to have a coherent type.
<_habnabit>
ah, that's right.
<thelema>
it gives you the error early because it knows you can't use the two folding functions interchangeably
<_habnabit>
maybe I should just make each an object.
<_habnabit>
then I could do this with mutation.
<thelema>
what do you want to do with the result?
<_habnabit>
well, this isn't a complete example; each should have a 'finalizer' function as well that's called after the fold.
ikaros has joined #ocaml
<thelema>
type reducer = int list -> final_type
<_habnabit>
ah, I suppose I could do it that way.
<thelema>
let build_reducer init foldf finalize = fun lst -> List.fold_left foldf init lst |> finalize
<thelema>
val build_reducer : 'a -> ('a -> 'b -> 'a) -> ('a -> 'c) -> 'b list -> 'c
Julien_T has quit [Read error: Operation timed out]
<_habnabit>
hmm. that might work the best after all.
larhat has quit [Quit: Leaving.]
alexyk has joined #ocaml
alexyk has quit [Client Quit]
sepp2k has joined #ocaml
* NaCl
eyes lwt annoyingly
ulfdoz has joined #ocaml
alexyk has joined #ocaml
alexyk has left #ocaml []
sepp2k has quit [Ping timeout: 255 seconds]
sepp2k has joined #ocaml
<_habnabit>
I'm getting a 'stack overflow during evaluation' in the toplevel. is there a way to see what the last couple of frames were?
<_habnabit>
not sure what part of what I'm doing isn't tail-recursive.
<thelema>
it's probably something involving exception handling - `let rec f x = if x < 0 then () else try f (x-1) with _ -> ()` is not tail recursive
Julien_Tz has joined #ocaml
Julien_Tz is now known as Julien_T
<_habnabit>
well, I should clarify: this is just a bunch of calling List.map, really. I replaced the ones I could with rev_map, but I'm still getting the error.
<thelema>
_habnabit: use batteries - its List.map is tail recursive
<thelema>
or compile and run - the backtrace will give you the infinite loop
<_habnabit>
I guess I should figure out how to install that sometime. :(
<_habnabit>
godi-batteries fails when I try to install it.
<_habnabit>
let's see if it still happens.
<thelema>
I assume you've not tried odb
<_habnabit>
I don't know what that is, so probably not.
<thelema>
`ocaml odb.ml batteries` should install batteries and all its deps, assuming you have findlib working
<_habnabit>
ah, I see.
<_habnabit>
and it'll cooperate with godi?
<thelema>
(and you're running a non-crazy unix)
<thelema>
it does normal ./configure && make && make install
<thelema>
(or the _oasis equivalent for many packages)
<thelema>
it'll work fine with godi
<adrien>
if it uses findlib, it should work ok with godi
<_habnabit>
okay.
<adrien>
actually, even if it doesn't I think
* NaCl
wonders if he should continue making rpms
<_habnabit>
oh, I need to put thins on OCAMLPATH, I guess.
<thelema>
_habnabit: if you use --sudo, it'll install as root
<_habnabit>
it's a local godi install. not system-wide.
<_habnabit>
~/fhcrc/godi
<thelema>
ok then, this will want to install to ~/.odb/lib
<thelema>
I think I added an option to change this, but maybe not
<adrien>
NaCl: you have most things done now
* thelema
has to go to a meeting, back in maybe an hour
<NaCl>
adrien: don't have ocamlnet, and many other libs
<_habnabit>
okay, well, that seems to have installed batteries.
<_habnabit>
and it seems to do something if I #require "batteries".
<NaCl>
maybe I should make a package for that
<adrien>
NaCl: how many libs do you currently have?
<NaCl>
22
<adrien>
you're probably not going to use that many more by yourself ;-)
<NaCl>
yup
<adrien>
hadn't heard of http://thinkocaml.com/ until 20 seconds ago (but they have a nice camel picture)
anxt has joined #ocaml
<anxt>
i have this build error for an ocaml program which i dont know how to solve. http://pastebin.com/Bm2QNNht
<NaCl>
the Dynlink module isn't installed
<NaCl>
for some reason
<adrien>
which ocaml version?
<anxt>
the latest 3.12.1 iirc
<adrien>
how did you install it?
<anxt>
make make install
<anxt>
i do not have the privilege of a package manager
<adrien>
you're not root on the machine?
<NaCl>
The path to the ocaml modules is not set correctly
<anxt>
i do have /usr/local/lib/ocaml/dynlink.*
<anxt>
is that an environment variable?
<NaCl>
yes. but I do not know what it is. and I may be completely wrong
<NaCl>
adrien would know more. :P
<anxt>
NaCl: ok
<anxt>
it is a freebsd system, fwiw
willb has quit [Read error: Operation timed out]
<adrien>
anxt: do you have a way to make "make" more verbose? and _your_ hand-compiled version is in /usr/local/?
<anxt>
i have gnu make so i suppose i should be able to
<anxt>
adrien: my hand compiled is under /usr/local, yes
mfp has quit [Ping timeout: 255 seconds]
<NaCl>
adrien: time to make sed. :P
<anxt>
the verbose make shows nothing new as far as debugging
<adrien>
anxt: does it show the ocamlopt invocation?
zorun has quit [Ping timeout: 250 seconds]
zorun has joined #ocaml
<NaCl>
it doesn't use ocamlfind? for shame
<adrien>
does anyone know of a good interval tree implementation in ocaml?
mfp has joined #ocaml
* NaCl
doesn't even know what an interval tree is
<NaCl>
adrien: more fun with treeviews?
<adrien>
selection
<adrien>
(over listviews of course)
<adrien>
I should think about _tree_views too, but I don't need them right away
zorun has quit [Ping timeout: 260 seconds]
<NaCl>
treeviews are just lists of lists anyway
<adrien>
I hope to rewrite a relatively big (and dirty) GUI into something much shorter by using these
zorun has joined #ocaml
<NaCl>
adrien is ambitious
<adrien>
making it fit into FRP should be trivial too
<NaCl>
although, I may be insane mysef into thinking that I should make a new toplevel. :P
<adrien>
NaCl: at least, it can't get more annoying to read
<adrien>
plus it lacked some features
<adrien>
heheh =)
<NaCl>
heh. but, srsly. how hard is it to unload a module? xD
zorun has quit [Read error: Operation timed out]
<adrien>
unload a module? it's close to impossible :P
<NaCl>
wat
<NaCl>
srsly?
jamii has joined #ocaml
zorun has joined #ocaml
<adrien>
probably not but I remember there are limitations on what you'd like to do, be more precise and wait a bit, I'm pretty sure that some people here know better
<anxt>
i didnt see an ocamlopt
<NaCl>
adrien: time to read about algorithms. :P
<adrien>
anxt: the command that failed mentionned ocamlopt, but if it's only "ocamlopt" and doesn't pass any argument to ocamlopt, then it's expected than it fails
* adrien
hops he will find a godi package for 3.12.1 under the christmas tree when he wakes up tomorrow morning
<adrien>
and someone should change /topic
<NaCl>
like gildor
ulfdoz has quit [Ping timeout: 255 seconds]
<adrien>
NaCl: yeah, but I'm not going to start any new code at this time of the day and I'm also waiting for the updated ocaml godi package ;-)
<NaCl>
read a book or something
<adrien>
ah, crap, I know: have to format a trivial patch to the linux kernel (the patch changes _one_ line and I have to read two pages on how to properly submit patches)
<anxt>
can you just submit to a mailing list?
<anxt>
i cant imagine trying to submit a patch to openbsd, you would probably need to sacrifice your firstborn or something
<adrien>
mostly, I need to make sure I don't forget one point ;-)
<olasd>
I'd stick to git, Documentation/SubmittingPatches, checkpatch.pl, et voilà
<adrien>
oh, I use git already, but I expect it to take more than a few minutes when I'm already pretty tired =)
<thelema>
adrien: interval tree = IMap/ISet in batteries
<adrien>
thelema: =/ batterie is too big for yypkg
<adrien>
actually, it's the descendant of AAA batteries now, hmmm
<thelema>
if you get the version in the v2 branch of batteries, there's no external dependencies
<adrien>
what about camlp4?
<thelema>
and if you're worried about the binary size, you should copy the batteries.ml file to your source tree and comment out any parts you don't use - it doesn't *have* to link everything in
<adrien>
that's optimization: I need to build it for/on windows
<thelema>
camlp4 is completely optional for batteries. There's some syntax extensions for list comprehensions and lazy list matching and magic printing
<thelema>
but I don't use them and they're not enabled by default, you have to ask for them.
<adrien>
ok, will try to try during the weekend (KDE BBQ on sunday \o/ )
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
Snark has quit [Quit: Ex-Chat]
<adrien>
btw, any ETA for v2?
<thelema>
adrien: let me know how it goes. It doesn't even have any C stubs for anything - it's pure ocaml still.
<thelema>
batteries v2... unknown. I was thinking I'd get it out this summer, but I just released 1.4.0, and there'd only be removals/renamings in v2
<adrien>
not try on windows this week though
<thelema>
it doesn't seem that urgent
<adrien>
ok
Cyanure has quit [Remote host closed the connection]
<adrien>
I think I'll probably have to wait for 3.12.1 to be fixed for mingw anyway (or hope that 3.11 doesn't have what seems to be a bug I have had with objects when trying my custom model for listviews in lablgtk)
<adrien>
anyway, falling asleep now: good night
lopex has joined #ocaml
sheets has joined #ocaml
sheets has left #ocaml []
willb has joined #ocaml
<hcarty>
_habnabit: odb has a --have-perms option which works well with a locally-installed GODI
<thelema>
hcarty: ah, thanks.
<thelema>
I remember adding that for you, I didn't realize that was what it was for.
<hcarty>
thelema: Thank you for implementing it :-)
<hcarty>
The only real gotcha I ran into was "make install" for programs would try to install to somewhere like /usr/local/bin/
<thelema>
it was 2 new lines of code and 2 changed lines
<hcarty>
That was fixable with a environment variable IIRC, but it was package-specific.
<thelema>
oh, maybe I should still use --prefix on configure?
<thelema>
or maybe there should be two options - one for having permissions to findlib install, and the other for executable install
<hcarty>
thelema: Two options seems like a good idea
<thelema>
now I just need names for these options
<hcarty>
Or a "--local-godi" option which does both :-)
<thelema>
I could do --godi
<hcarty>
--have-perms-lib --have-perms-bin maybe?
<hcarty>
--godi could turn on both, if it's worth having each separately.
<hcarty>
Having both is probably a good idea
<thelema>
actually, godi would only turn on --have-perms-lib
<hcarty>
A user with a self-installed OCaml + findlib in ~/ may still want binaries like oasis in /usr/local/bin/ rather than ~/path/to/ocaml/bin/
<hcarty>
If it's only an alias then I think the --have-perms-* options would be sufficient, along with a not somewhere on their GODI-relevance
lamawithonel__ has quit [Ping timeout: 255 seconds]
<thelema>
"a not somewhere" ??
<thelema>
ah, a note
<hcarty>
thelema: Yes, sorry for the typo
<thelema>
well, a --bindir and --libdir would also be useful for those people who have custom local installs
<thelema>
although really this would be best in a config file, which I'm doing my best to avoid having
Julien_T has quit [Ping timeout: 255 seconds]
ztfw has joined #ocaml
dsheets has joined #ocaml
Anarchos has joined #ocaml
edwin has quit [Remote host closed the connection]