Alpounet changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.1 out now! Get yours from http://caml.inria.fr/ocaml/release.html
Pimm has quit [Read error: 60 (Operation timed out)]
yakischloba has joined #ocaml
Amorphous has quit [farmer.freenode.net irc.freenode.net]
demitar has quit [farmer.freenode.net irc.freenode.net]
acatout_ has quit [farmer.freenode.net irc.freenode.net]
Dodek has quit [farmer.freenode.net irc.freenode.net]
maskd has quit [farmer.freenode.net irc.freenode.net]
tonyIII has quit [farmer.freenode.net irc.freenode.net]
noj has quit [farmer.freenode.net irc.freenode.net]
noj has joined #ocaml
Dodek has joined #ocaml
maskd has joined #ocaml
tonyIII has joined #ocaml
Amorphous has joined #ocaml
acatout_ has joined #ocaml
demitar has joined #ocaml
Amorphous has quit [SendQ exceeded]
Amorphous has joined #ocaml
yakischloba has quit [Read error: 110 (Connection timed out)]
yakischloba has joined #ocaml
Amorphous has quit [farmer.freenode.net irc.freenode.net]
acatout_ has quit [farmer.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
acatout_ has joined #ocaml
tmaeda is now known as tmaedaZ
Amorphous has quit [SendQ exceeded]
Amorphous has joined #ocaml
diml has quit [farmer.freenode.net irc.freenode.net]
safire_ has quit [farmer.freenode.net irc.freenode.net]
gildor has quit [farmer.freenode.net irc.freenode.net]
infoe_ has quit [farmer.freenode.net irc.freenode.net]
willb has quit [farmer.freenode.net irc.freenode.net]
ski_ has joined #ocaml
infoe_ has joined #ocaml
gildor has joined #ocaml
safire_ has joined #ocaml
willb has joined #ocaml
diml has joined #ocaml
Associat0r has quit []
joewilliams has joined #ocaml
joewilliams has quit [Remote closed the connection]
jonafan has joined #ocaml
tmaedaZ has quit [Read error: 60 (Operation timed out)]
tmaedaZ has joined #ocaml
jonafan_ has quit [Read error: 60 (Operation timed out)]
jonafan_ has joined #ocaml
jonafan has quit [Read error: 60 (Operation timed out)]
<det> No String.fold_left, lame :<
ski_ has quit ["Lost terminal"]
r00t_linux has joined #ocaml
<thelema> det: You want batteries - we have String.fold_left and fold_right: http://github.com/thelema/AAA-batteries/blob/aaa/src/batString.ml#L281
r00t_linux has quit [Client Quit]
spies has joined #ocaml
spies has left #ocaml []
_unK has quit [Remote closed the connection]
yakischloba has quit ["Leaving."]
ski_ has joined #ocaml
_zack has joined #ocaml
yakischloba has joined #ocaml
_zack has quit ["Leaving."]
ygrek has joined #ocaml
thieusoai has joined #ocaml
ksson has joined #ocaml
Pimm has joined #ocaml
Pimm has quit [Read error: 60 (Operation timed out)]
bind_return has joined #ocaml
hugin has quit ["leaving"]
Pimm has joined #ocaml
ua has joined #ocaml
ua has quit [Client Quit]
demitar has quit ["Ex-Chat"]
demitar has joined #ocaml
yakischloba has quit ["Leaving."]
ua has joined #ocaml
stan_ has joined #ocaml
demitar has quit [Read error: 60 (Operation timed out)]
yziquel has joined #ocaml
schme has quit [Read error: 104 (Connection reset by peer)]
schme has joined #ocaml
marteo has joined #ocaml
stan_ has quit [Read error: 110 (Connection timed out)]
ski_ has quit ["Lost terminal"]
CcSsNET has joined #ocaml
ski_ has joined #ocaml
Amorphous has quit [farmer.freenode.net irc.freenode.net]
acatout_ has quit [farmer.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
acatout_ has joined #ocaml
acatout_ has quit [farmer.freenode.net irc.freenode.net]
Amorphous has quit [farmer.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
acatout_ has joined #ocaml
acatout_ has quit [farmer.freenode.net irc.freenode.net]
Amorphous has quit [farmer.freenode.net irc.freenode.net]
Dodek has quit [farmer.freenode.net irc.freenode.net]
maskd has quit [farmer.freenode.net irc.freenode.net]
tonyIII has quit [farmer.freenode.net irc.freenode.net]
noj has quit [farmer.freenode.net irc.freenode.net]
sgnb has quit [farmer.freenode.net irc.freenode.net]
ksson has quit [farmer.freenode.net irc.freenode.net]
EliasAmaral has quit [farmer.freenode.net irc.freenode.net]
anders^^_ has quit [farmer.freenode.net irc.freenode.net]
|Jedai| has quit [farmer.freenode.net irc.freenode.net]
Modius has quit [farmer.freenode.net irc.freenode.net]
caligula_ has quit [farmer.freenode.net irc.freenode.net]
peper has quit [farmer.freenode.net irc.freenode.net]
olegfink has quit [farmer.freenode.net irc.freenode.net]
deavid has quit [farmer.freenode.net irc.freenode.net]
patronus has quit [farmer.freenode.net irc.freenode.net]
shr3kst3r has quit [farmer.freenode.net irc.freenode.net]
julm has quit [farmer.freenode.net irc.freenode.net]
lutter has quit [farmer.freenode.net irc.freenode.net]
thelema has quit [farmer.freenode.net irc.freenode.net]
hyperboreean has quit [farmer.freenode.net irc.freenode.net]
tab_ has quit [farmer.freenode.net irc.freenode.net]
diginux has quit [farmer.freenode.net irc.freenode.net]
haelix has quit [farmer.freenode.net irc.freenode.net]
tarbo2_ has quit [farmer.freenode.net irc.freenode.net]
diml has quit [farmer.freenode.net irc.freenode.net]
safire_ has quit [farmer.freenode.net irc.freenode.net]
gildor has quit [farmer.freenode.net irc.freenode.net]
infoe_ has quit [farmer.freenode.net irc.freenode.net]
ygrek has quit [farmer.freenode.net irc.freenode.net]
willb has quit [farmer.freenode.net irc.freenode.net]
ua has quit [farmer.freenode.net irc.freenode.net]
det has quit [farmer.freenode.net irc.freenode.net]
svenl has quit [farmer.freenode.net irc.freenode.net]
mbac has quit [farmer.freenode.net irc.freenode.net]
bzzbzz has quit [farmer.freenode.net irc.freenode.net]
jlouis has quit [farmer.freenode.net irc.freenode.net]
ski_ has quit [farmer.freenode.net irc.freenode.net]
Pimm has quit [farmer.freenode.net irc.freenode.net]
tmaedaZ has quit [farmer.freenode.net irc.freenode.net]
mal`` has quit [farmer.freenode.net irc.freenode.net]
Camarade_Tux has quit [farmer.freenode.net irc.freenode.net]
flux has quit [farmer.freenode.net irc.freenode.net]
Pepe__ has quit [farmer.freenode.net irc.freenode.net]
bacam has quit [farmer.freenode.net irc.freenode.net]
BigJ has quit [farmer.freenode.net irc.freenode.net]
nimred has quit [farmer.freenode.net irc.freenode.net]
prigaux has quit [farmer.freenode.net irc.freenode.net]
rbancroft has quit [farmer.freenode.net irc.freenode.net]
Ori_B has quit [farmer.freenode.net irc.freenode.net]
ozzloy has quit [farmer.freenode.net irc.freenode.net]
quelqun_dautre has quit [farmer.freenode.net irc.freenode.net]
fremo_ has quit [farmer.freenode.net irc.freenode.net]
orbitz has quit [farmer.freenode.net irc.freenode.net]
marteo has quit [farmer.freenode.net irc.freenode.net]
r0bby has quit [farmer.freenode.net irc.freenode.net]
Asmadeus has quit [farmer.freenode.net irc.freenode.net]
my007ms has quit [farmer.freenode.net irc.freenode.net]
WuJiang_ has quit [farmer.freenode.net irc.freenode.net]
lanaer has quit [farmer.freenode.net irc.freenode.net]
srcerer has quit [farmer.freenode.net irc.freenode.net]
rwmjones has quit [farmer.freenode.net irc.freenode.net]
mrvn has quit [farmer.freenode.net irc.freenode.net]
trasz has quit [farmer.freenode.net irc.freenode.net]
yziquel has quit [farmer.freenode.net irc.freenode.net]
CcSsNET has quit [farmer.freenode.net irc.freenode.net]
schme has quit [farmer.freenode.net irc.freenode.net]
bind_return has quit [farmer.freenode.net irc.freenode.net]
thieusoai has quit [farmer.freenode.net irc.freenode.net]
jonafan_ has quit [farmer.freenode.net irc.freenode.net]
zhijie has quit [farmer.freenode.net irc.freenode.net]
fission61 has quit [farmer.freenode.net irc.freenode.net]
mehdid has quit [farmer.freenode.net irc.freenode.net]
animist has quit [farmer.freenode.net irc.freenode.net]
mfp has quit [farmer.freenode.net irc.freenode.net]
mattam has quit [farmer.freenode.net irc.freenode.net]
TaXules has quit [farmer.freenode.net irc.freenode.net]
Tianon has quit [farmer.freenode.net irc.freenode.net]
peddie has quit [farmer.freenode.net irc.freenode.net]
M| has quit [farmer.freenode.net irc.freenode.net]
__marius__ has quit [farmer.freenode.net irc.freenode.net]
mbishop has quit [farmer.freenode.net irc.freenode.net]
brendan has quit [farmer.freenode.net irc.freenode.net]
ertai has quit [farmer.freenode.net irc.freenode.net]
Leonidas has quit [farmer.freenode.net irc.freenode.net]
infoe has quit [farmer.freenode.net irc.freenode.net]
ygrek has joined #ocaml
acatout_ has joined #ocaml
Amorphous has joined #ocaml
ski_ has joined #ocaml
CcSsNET has joined #ocaml
marteo has joined #ocaml
schme has joined #ocaml
yziquel has joined #ocaml
ua has joined #ocaml
Pimm has joined #ocaml
bind_return has joined #ocaml
ksson has joined #ocaml
thieusoai has joined #ocaml
jonafan_ has joined #ocaml
tmaedaZ has joined #ocaml
diml has joined #ocaml
willb has joined #ocaml
safire_ has joined #ocaml
gildor has joined #ocaml
infoe_ has joined #ocaml
tonyIII has joined #ocaml
maskd has joined #ocaml
Dodek has joined #ocaml
noj has joined #ocaml
EliasAmaral has joined #ocaml
det has joined #ocaml
anders^^_ has joined #ocaml
mal`` has joined #ocaml
zhijie has joined #ocaml
fission61 has joined #ocaml
Camarade_Tux has joined #ocaml
peper has joined #ocaml
|Jedai| has joined #ocaml
mehdid has joined #ocaml
flux has joined #ocaml
Modius has joined #ocaml
animist has joined #ocaml
quelqun_dautre has joined #ocaml
svenl has joined #ocaml
caligula_ has joined #ocaml
mfp has joined #ocaml
mbac has joined #ocaml
Pepe__ has joined #ocaml
mattam has joined #ocaml
TaXules has joined #ocaml
bacam has joined #ocaml
Tianon has joined #ocaml
jlouis has joined #ocaml
bzzbzz has joined #ocaml
r0bby has joined #ocaml
Asmadeus has joined #ocaml
julm has joined #ocaml
my007ms has joined #ocaml
olegfink has joined #ocaml
deavid has joined #ocaml
patronus has joined #ocaml
WuJiang_ has joined #ocaml
lanaer has joined #ocaml
lutter has joined #ocaml
sgnb has joined #ocaml
srcerer has joined #ocaml
thelema has joined #ocaml
hyperboreean has joined #ocaml
rwmjones has joined #ocaml
shr3kst3r has joined #ocaml
tab_ has joined #ocaml
BigJ has joined #ocaml
diginux has joined #ocaml
peddie has joined #ocaml
haelix has joined #ocaml
tarbo2_ has joined #ocaml
nimred has joined #ocaml
prigaux has joined #ocaml
M| has joined #ocaml
__marius__ has joined #ocaml
mbishop has joined #ocaml
infoe has joined #ocaml
Leonidas has joined #ocaml
ozzloy has joined #ocaml
rbancroft has joined #ocaml
orbitz has joined #ocaml
fremo_ has joined #ocaml
Ori_B has joined #ocaml
mrvn has joined #ocaml
trasz has joined #ocaml
ertai has joined #ocaml
brendan has joined #ocaml
jonafan has joined #ocaml
animist has quit [farmer.freenode.net irc.freenode.net]
mehdid has quit [farmer.freenode.net irc.freenode.net]
bind_return has quit [farmer.freenode.net irc.freenode.net]
fission61 has quit [farmer.freenode.net irc.freenode.net]
mattam has quit [farmer.freenode.net irc.freenode.net]
jonafan_ has quit [farmer.freenode.net irc.freenode.net]
zhijie has quit [farmer.freenode.net irc.freenode.net]
Tianon has quit [farmer.freenode.net irc.freenode.net]
thieusoai has quit [farmer.freenode.net irc.freenode.net]
CcSsNET has quit [farmer.freenode.net irc.freenode.net]
TaXules has quit [farmer.freenode.net irc.freenode.net]
schme has quit [farmer.freenode.net irc.freenode.net]
mfp has quit [farmer.freenode.net irc.freenode.net]
TaXules has joined #ocaml
mattam has joined #ocaml
Tianon has joined #ocaml
thieusoai has joined #ocaml
cloudhead has joined #ocaml
CcSsNET has joined #ocaml
bind_return has joined #ocaml
jonafan_ has joined #ocaml
zhijie has joined #ocaml
fission61 has joined #ocaml
mfp has joined #ocaml
mfp has quit ["Leaving"]
ulfdoz has joined #ocaml
mfp has joined #ocaml
mehdid has joined #ocaml
animist has joined #ocaml
schme has joined #ocaml
schme has quit [Read error: 54 (Connection reset by peer)]
schme has joined #ocaml
animist has quit [farmer.freenode.net irc.freenode.net]
ulfdoz has quit [farmer.freenode.net irc.freenode.net]
jonafan_ has quit [farmer.freenode.net irc.freenode.net]
zhijie has quit [farmer.freenode.net irc.freenode.net]
bind_return has quit [farmer.freenode.net irc.freenode.net]
CcSsNET has quit [farmer.freenode.net irc.freenode.net]
fission61 has quit [farmer.freenode.net irc.freenode.net]
jonafan_ has joined #ocaml
ulfdoz has joined #ocaml
ulfdoz has quit [Read error: 60 (Operation timed out)]
CcSsNET has joined #ocaml
bind_return has joined #ocaml
zhijie has joined #ocaml
fission61 has joined #ocaml
ulfdoz has joined #ocaml
animist has joined #ocaml
jonafan has quit [Read error: 110 (Connection timed out)]
bzzbzz_ has joined #ocaml
_unK has joined #ocaml
animist has quit [Read error: 111 (Connection refused)]
ikaros has joined #ocaml
ygrek has quit [Remote closed the connection]
ygrek has joined #ocaml
Smerdyakov has joined #ocaml
Pimm has quit [Read error: 60 (Operation timed out)]
ulfdoz has quit [Remote closed the connection]
ulfdoz has joined #ocaml
Pepe__ is now known as Pepe_
marteo has quit ["Debian GNU/Hurd is Good."]
demitar has joined #ocaml
lazz0 has joined #ocaml
Smerdyakov has quit ["Leaving"]
<thelema> "Ease of building new stuff brings fragmentation" -- hmm...
<flux> I suppose it's true, perhaps if it's revised as "When building stuff is easier than reusing existing code, the result is fragmentation"?-)
<thelema> How can we make it easier for people to reuse existing code in ocaml?
ikaros has quit ["Leave the magic to Houdini"]
<flux> we need to implement Xavierippy, the happy interactive guide with suggestive messages "It looks like me you should use Foo.bar here!"..
<flux> or perhaps Clippier
ttamttam has joined #ocaml
<thelema> no, that's not it...
<flux> well, maybe one refinement would be to have a system-wide mapping from module names to required modules, and the modules would magically just work when you refer to them by name
<flux> of course, it's not a 1:1 mapping, but sometimes 1:n mapping..
<thelema> That'd be a huge help - a build system that works...
* thelema finds _tags and OCamlmake files (for compilation) misguided
<thelema> languages that compile at runtime have a nice advantage - putting the source somewhere is sufficient
<flux> doesn't ghc have --make that links in foreign modules?
<thelema> I wonder if ocaml could have such an option in the build system - defaulting to source distributions, where the library code gets compiled when its used.
<flux> or maybe not, I don't really know what it can do :)
<thelema> I dunno.
yakischloba has joined #ocaml
<flux> what advantage does compiling-on-demand bring?
<flux> I would rather see it would just slow down compilation, that being one of the great points of ocaml, rapid compilation speeds
<thelema> trivial installation and usage of others' code
caoliver has joined #ocaml
<flux> should be the same make install for installation
<flux> and considering newbies, they mostly install stuff from their distribution. on windows I don't know.
<thelema> Maybe it'd suffice to have a common method of compilation for installing any module, so that the installer can handle all packages in a common way
<thelema> I'm imagining something like .net, where it's processed by the system at install time.
caoliver has left #ocaml []
Amorphous has quit [Connection reset by peer]
<thelema> So the problem is along the lines that it's complex to compile other people's packages?
<thelema> Or that including other people's code requires installation of 3rd party modules
<flux> in my experience make; make install works usually. however, sometimes it may be make findlib_install or something like that..
<flux> also sometimes building native binaries requires an extra step (or an extra make argument)
<thelema> ocaml packages generally install pretty easily
<flux> so that's not optimal, but.. wasn't there lately discussion about CPAN on the ml?
<thelema> although it'd be nice to have some better dependency management for installing packages that depend on...
<flux> and then we have godi
<thelema> yes.
<thelema> Maybe the linchpin is that it *requires* additional machinery to compile using someone else's library
<flux> and I really like godi, _but_ it requires its own ecosystem. distribution packages don't go along.
<flux> and it requires its own ocamlc too
<thelema> I'll admit that ocamlfind makes it pretty easy - "ocamlfind ocamlc -package foo bar.ml -o bar" is still too complex.
<flux> ocamlfind does one thing, and does it pretty good
<thelema> And with separate compilation, and dependencies between one's source files.
<thelema> it does, but it's amazingly inscruitable.
<flux> but making it "more simple than it is" isn't the thing :)
<thelema> I'd argue it's not simple enough.
<thelema> simple enough to make a trivial project that uses another library.
<thelema> ocamlfind solves a problem that shouldn't need to be solved.
<thelema> is the problem the lack of subdirectory support in module searching?
<thelema> What would come out of being able to specify [open Batteries.Enum] and have the compiler look for $prefix/batteries/enum.cmx
yakischloba1 has joined #ocaml
<thelema> with even a few prefixes it'd look under
<flux> how about that building a database mapping ModuleNames into package names? then find all referred module names that cannot be locally satisfied, and apply magic
<thelema> What parts of findlib could disappear?
<flux> however, that part (finding missing modules) may not be that easy with camlp4
<flux> also, if implemented in camlp4, it make it a mandatory piece basically, when doing 'easy compliation'
<thelema> scoped camlp4 seems much better than whole-file camlp4
<flux> I was thinking camlp4 only for extracting information, it wouldn't provide any new syntax. wouldn't that work more likely?
<thelema> re: database - why not just specify what packages you need at the top of your file?
<flux> well, it's not automatic :)
<flux> but indeed it can be troublesome, given the potential duplicity of module names
<flux> I suppose that kind of situation is bad in any case, though
<thelema> I can see the allure of a DB where module names get looked up to find the package they're from
<thelema> But I wonder if we can do this without adding the concept of packages to the compiler
<thelema> which is why I like the idea of subdirectories being module namespaces
<thelema> a directory containing a bunch of cmx's is virtually a module with submodules
Amorphous has joined #ocaml
yakischloba has quit [Read error: 110 (Connection timed out)]
<thelema> What does this fail to do that packages do?
ski_ has quit ["Lost terminal"]
Pimm has joined #ocaml
ulfdoz has quit [Read error: 60 (Operation timed out)]
ulfdoz has joined #ocaml
CcSsNET has quit [Client Quit]
CcSsNET has joined #ocaml
infoe has quit [Read error: 110 (Connection timed out)]
<yziquel> thelema: this would be a good idea. look at perl4caml. if we could just drop in modules in a directory perl/, we could have a namespace behaviour. currently, a module is completely static, and closed. you cannot just wrap a perl module and just 'drop it' into an already existing module.
<yziquel> i'm having the same problems with ocaml-R.
BigJ has quit ["Leaving"]
<thelema> I had forgotten about perl4caml
<thelema> is there a reason we can't have firectories as virtual modules?
<thelema> *directories
<flux> I don't know. in theory it would fit along the idea that a file is a module :)
<olegfink> java world gets all kinds of fun because of different pathname conventions on different platforms
<thelema> ocaml already has Filename.concat
<thelema> directories would correspond to modules with only submodules inside.
<olegfink> go has taken somewhat opposite approach as modules there are identified by strings (that for now are normally pathnames relative to libdir, but can be any sort of locators)
demitar has quit [Read error: 60 (Operation timed out)]
<olegfink> but indeed that's something I'd really like to have
<olegfink> cpp's #include conventions aren't really that bad
<thelema> that'd be interesting - having URIs to modules
<thelema> cpp's #include conventions succeed in one way that camlp4 fails - one macro can include another.
<thelema> That's not quite it...
<Camarade_Tux> (not sure it's an advantage)
<thelema> maybe it's just that the processing that's done depends more on the contents of the file than the arguments to cpp
<EliasAmaral> having a power i dont need fits well in my programming habits
<olegfink> well, I don't know how useful is URI-specified modules (but at least DTDs in XML documents seem to specify uris...), but I can think of quite some cases when you want to use something not in a local filesystem (e.g. a built-in C module in some embedded setup)
lazz0 has quit [Read error: 54 (Connection reset by peer)]
<thelema> Assuming a module include path that's been properly set up to include the current dir first, the OCaml install dir second, and a dir for local installation of modules, I see virtual modules as a very simple, effective solution to the problem of libraries being hard to include
<yziquel> thelema: that seems ok for source code. and definitely better than the unflattenable -pack option. but for already compiled stuff available with findlib? how do you open a .cma? could it be possible to have findlib consider a directory (adequately pinpointed in the META file) as an 'open' .cmxa or .cma where you could just drop stuff?
* thelema hopes to eliminate findlib as much as possible
<yziquel> thelema: but you'll have to find a solution for already compiled stuff.
<thelema> not that it's bad, it's just solving the problem in the wrong place
<mrvn> re
* mrvn scrolls way way back
demitar has joined #ocaml
<thelema> For most already compiled stuff, I think adding the findlib install dirs to the global search path would suffice.
<EliasAmaral> <thelema> "Ease of building new stuff brings fragmentation" -- hmm... > only if you let the code to evolve "naturally"
<yziquel> hmmm...
<thelema> for anything with more complex linking requirements, I dunno yet where to put that information
<thelema> I just want it off the command line.
<thelema> I think the compiler does some storing linking requirements in .cmx's
BigJ has joined #ocaml
<thelema> Extending the search path isn't the best solution, but it'd work for a transition
<mrvn> thelema: I like apt-get install libfoo-ocaml
<olegfink> hmm, how does java go about .jar's?
<thelema> that part of using external libraries is working great already. This proposal doesn't change that.
<yziquel> thelema: i think having 'open' .cmxa or .cma would be a better way to let people naturally add code.
<orbitz> olegfink: what do you mean?
<olegfink> how does it solve the same problem as with ocaml's .cmx?a about knowing what provides what
<thelema> This proposal (attempts to) solve the problem that ocamlfind solves - compiling with external libraries
<mrvn> What I am missing in ocaml are compile time conditionals
<orbitz> olegfink: .class files contain waht they provide and it dynamically links
<yziquel> mrvn: there's a syntax extension for that.
<mrvn> #if sizeof(int) = 4
<thelema> mrvThat's great, let's work on one idea at a time.
<mrvn> type t = Int64.t
<mrvn> #else
<mrvn> type t = int
<olegfink> yziquel: I kind of agree, I always like plan9's C include-per-library model more than ansi/posix include-per-function
<mrvn> Except they would need to remain in bytecode but not in binary.
<olegfink> (and actually plan9 system include linker hints (pragmas) so the library dependency gets included in object files)
<mrvn> olegfink: include per library?
<thelema> yziquel: what specifically do you want to be able to do with an 'open' cmxa?
<olegfink> mrvn: e.g., for libc you don't have stdlib.h/string.h/assert.h/whatever, but libc.h
<mrvn> olegfink: right. But then I want #use libc, #use libc::string or even more sub-namespaces
<mrvn> or sub modules
<olegfink> mrvn, and thelema, probably if you say you're #usinng or (opening) a .cma you mean you actually open all its contents?
<mrvn> I figure that C has so many include files because having just ONE HUGE file was far too slow to compile and use too much memory.
<yziquel> thelema: have a module A from someone. Someone else wants to write module A.B. Without recompiling and repackaging A for Debian, GODI, whatever, simply add a mecanism to drop module B.cmo into an 'open' A.cma. Something like that.
<thelema> yziquel: child packages
<olegfink> mrvn: yes, plan9 fixed that in other way, but that's irrelevant, because it's not a problem with ocaml
<orbitz> mrvn: the real issue ther ethough is you compile that header PER translation unit, not per build
<yziquel> thelema: dunno. The idea would be to avoid recompilation and repackaging.
<mrvn> yziquel: I don't like that. Another package should not pollute the namespace of an existing one.
<yziquel> mrvn: depends.
<mrvn> yziquel: I want namespaces that are open and sub-modules that are closed.
<thelema> mrvn: this kind of structure is very good for large scale software engineering.
<mrvn> a namespace could be just a directory of that name without a mli file. A closed sub-module would have a .mli file that closes the interface against other people dropping in more files.
<yziquel> mrvn: if namespace = submodule, you cannot have open and closed. therefore you want namespace != modules. that's fine with me.
paritosh1010 has joined #ocaml
<mrvn> yziquel: the difference could be just the existance of the mli file.
<yziquel> mrvn: that would be nice.
<yziquel> mrvn: yes
<thelema> I'm happy with the .mli files for directories. What should it be called? index.cmi?
CcSsNET has quit [Read error: 104 (Connection reset by peer)]
<mrvn> I.e. no .mli file ==> look for the submodules .mli files in the directory automatically.
<mrvn> thelema: normaly I would say .mli but hiden files would be bad.
<thelema> yes
<thelema> foo/foo.mli?
<mrvn> thelema: dir.mli and dir/foo.cmx for the individual objects?
CcSsNET has joined #ocaml
<thelema> i.e. batteries/batteries.mli, extlib/extlib.mli
<mrvn> or dir.cmx? when packed
<flux> directory name is foo, and the cmi-file can be in the same level like foo.cmi?
<yziquel> flux: good.
<flux> and indeed if you wanted, you could provide an .mli-file but its submodules would come from the dircetory
<mrvn> As an extra you could also have different rules for absolute and relative paths.
<thelema> hmmm... That's interesting... What if we allowed .cmxa files to be directories...
<yziquel> thelema: nice.
<thelema> foo.cmxa (a directory) and foo.cmi / foo.mli
<thelema> of course similar for .cma
<mrvn> A.B.C.foo would check a.mli, a/b.mli, a/b/c.mli but C.foo from inside a/b would only check a/b/c.mli.
<thelema> The naming gets ugly if we have to check a.cmx/b.cmx/c.mli
<mrvn> thelema: I would use foo/bla.cmxa instead of foo.cmxa/bla.cmxa
<mrvn> I don't want foo.cmxo/ foo.cmxa/ ..., put them all in foo/
<thelema> And I really think the .mli should be inside the directory, not next to it.
<thelema> foo/foo.mli
<yziquel> thelema: why?
<mrvn> thelema: Then how do you use Foo.Foo.x?
<yziquel> mrvn: exactly
<thelema> partly manageability - better to have all of the foo files in one dir than to have some of them outside foo
<mrvn> thelema: You can have foo.mli + foo.cmxa, or foo.mli + foo/bla.cmxa + foo/blub.cmxa
<thelema> Foo.Foo.x isn't needed - a small cacualty of design.
<thelema> *casualty
<thelema> I want to have package = directory, similar to findlib.
<mrvn> thelema: and then foo/mli + foo/cmxa?
<thelema> foo/META.mli
<mrvn> that would work too.
<thelema> foo/bla.cmxa, foo/blub/cmxa
<thelema> foo/bla.cmxa, foo/blub.cmxa
<flux> thelema, btw, don't forget findlib also knows which C libraries to link in
<mrvn> thelema: no. that would be foo/bla/META.cmxa then
<thelema> although I'd prefer less .cmxa/cma and more .cmx/cmo
<flux> but I suppose your idea was to use findlib, not get rid of it
* thelema wants to have ocamlc/ocamlopt do everything necessary for the simple case
<mrvn> flux: the cmxo should be linked against the C lib already.
<thelema> flux: as to c libraries to link, IIRC, that's already taken care of by the compiler
<flux> hmm, I've at points linked jpeg library with findlib, perhaps it wasn't required then?
<mrvn> flux: .oO(Not saying ocaml already does but it should)
<thelema> --linkall Force all modules contained in libraries to be linked in. If this flag is not given, unreferenced modules are not linked in. When building a library (-a flag), setting the -linkall flag forces all subsequent links of programs involving that library to link all the modules contained in the library.
<thelema> sorry, that's not it.
yakischloba1 is now known as yakischloba
<mrvn> Now something off-topic: I'm writing a small client/server app. Any ideas what to use as handshake?
<thelema> - Libraries (.cma and .cmxa files) now "remember" C libraries given
<thelema> at library construction time, and add them back at link time.
<thelema> Allows linking with e.g. just unix.cma instead of
<thelema> unix.cma -custom -cclib -lunix
<thelema> as of OCaml 3.00
<mrvn> some "me tarzan" "me jane" stuff so they knwo they are talking to the right port.
<mrvn> thelema: yep, that's the one. :
<mrvn> )
<yziquel> gettin rid of findlib on the grounds that it solves a problem that should not exist is one goal. adding namespaces for compiled stuff to ease packaging of binaries and bytecode is another goal. they are orthogonal. but a framework that solves both would be great.
<mrvn> What does findlib actually all do?
<thelema> yziquel: I'm thinking about two birds with one stone.
demitar has quit [Read error: 60 (Operation timed out)]
<thelema> mrvn: findlib adds [-package foo] as a command-line argument to ocaml* such that the given package and its dependencies are automatically included in compilation
<yziquel> thelema: please do.
<mrvn> seems it also sorts them in the right order.
<flux> it also handles threadedness or other predicates
<mrvn> But if the source uses Foo.x then the compiler can easily enough find foo/META.cmi and foo/META.cmx[ao] and so on.
demitar has joined #ocaml
<mrvn> flux: How would you map predicates?
<flux> well, they have little use, other than for threads and bytecode/native
<thelema> it seems to me that almost all uses of findlib are just specifying bytecode/native archive names
<mrvn> hopefully soon also multi-core
<flux> thelema, one point to consider is that how would syntax extensions work
<flux> that's one area where findlib is used
<thelema> flux: how I'd want them to work is to have non-whole-file scope
<mrvn> How does that currently work? Say I use Unix what does -threads change?
<thelema> and to have a declaration that's caught by the compiler that says to pass the rest of the file through a particular filter
<flux> archive(byte) = "unix.cma"
<flux> archive(native) = "unix.cmxa"
<flux> archive(byte,mt_vm) = "vmthreads/unix.cma"
<mrvn> flux: Ahh. So it just adds a prefix to the namespace. That should be simple.
<flux> mrvn, well, I'm not sure that is proper mapping for all packages
<flux> archive(byte) = "equeue.cma"
<flux> archive(byte,mt) = "equeue.cma unixqueue_mt.cmo"
<flux> archive(native) = "equeue.cmxa"
<flux> archive(native,mt) = "equeue.cmxa unixqueue_mt.cmx"
<thelema> It'd be pretty easy for ocaml in threads mode to add a threads/ to the search path
<mrvn> flux: not so easy there
<thelema> is there some situation this wouldn't suffice for?
<mrvn> threads/equeue.cma could be linked against unixqueue_mt.cmo while plain equeue.cma is not.
<thelema> just have threads/equeue.cma include unixqueue_mt.cmo
<thelema> exactly
<flux> well, one problem of this approach in general is that it requires modifying a significant number of packgaes to work in it?
<mrvn> stupid duplication of all the code in the cma though.
<thelema> It wouldn't break anything existing - findlib would still work.
<thelema> people could migrate to this system to make it easier for people to compile their code.
<thelema> now how to do this...
<mrvn> I would really love to have a directory be a namespace. I would love to usr /usr/local/ocaml/mrvn/{unix,graphics,...}.cmi for extended modules of the stdlib and then just say "open Mrvn" in my code.
<thelema> mrvn: This is almost exactly the major part of my proposal
<mrvn> unix.cmi and graphics.cmi would belong to different ocaml packages though.
<thelema> although I'd love to take your extensions of stdlib and merge them with batteries
<mrvn> thelema: sure. but batteries has the same problem.
<thelema> unix and graphics belong to different findlib packages.
<mrvn> batteries/list.cmi, batteries/unix.cmi, batteries/array.cmi or whatever
<thelema> ocaml proper has no concept of package
<mrvn> but I do. :) I don't want to have to make a mrvn.cmi pack.
ttamttam has quit ["Leaving."]
<thelema> well, batteries wouldn't really benefit from it because of how it merges its packages with stdlib
<thelema> ocaml packs are (imnsho) a bad thing, while these directory packs would be much better.
<mrvn> thelema: batteries in debian depends on a ton of other ocaml packages. You could split it up more.
<thelema> mrvn: aaa-batteries depends on findlib, camomile and ocaml. (And ounit if you want to run the tests)
infoe has joined #ocaml
<mrvn> apt-get install ocaml-batteries-included
<thelema> and I could possibly drop the dependency on findlib
<mrvn> libbatteries-ocaml-dev libbatteries-ocaml-doc libbin-prot-camlp4-dev libcamomile-ocaml-data libcamomile-ocaml-dev libcryptgps-ocaml-dev libnethttpd-ocaml-dev libocamlnet-ocaml libocamlnet-ocaml-dev libocamlnet-ocaml-doc libpcre-ocaml libpcre-ocaml-dev libpcre3-dev libpcrecpp0 libsexplib-camlp4-dev libtype-conv-camlp4-dev libzip-ocaml
<thelema> mrvn: that's the old package.
<mrvn> what is the new one? I just pressed <tab>
<thelema> zack has yet to produce a new one
<thelema> what is lib/ocaml/std-lib/camlp4/Camlp4Parsers/Camlp4ListComprehension.cmi
<yakischloba> what is the preferred tool for controlling a projects build like with a Makefile?
<thelema> yakischloba: There's a number of common choices. Makefile is one of them, OMake is another and ocamlbuild is up and coming
<EliasAmaral> omake is "dead"?
<thelema> We're trying to work out a new way.
<yakischloba> thelema: any particular method you would recommend for a newbie with pretty simple requirements?
<EliasAmaral> 'we'?
<EliasAmaral> why a new way? i was reading the docs, it seems great
<mrvn> yakischloba: I just use a Makefile
<thelema> EliasAmaral: OMake works really well, but hasn't been updated in years
<thelema> EliasAmaral: what works great?
<EliasAmaral> yeah, but isn't it open source?
<EliasAmaral> omake seems great
<ksson> yakischloba: define simple requirements :)
<ksson> i have used ocamlbuild with some success
<EliasAmaral> it just loses the huge compatibility that autoconf gives, but ocaml itself isn't that compatible..
<yakischloba> ksson: heh. I have about 8 files that need to be built in a particular order and I link against 1 package :p
<thelema> What I'm trying to design with module directories is a large part of what's needed for users like yakischloba
<yakischloba> ksson: (so far)
<EliasAmaral> ksson, why ocamlbuild instead of omake? just because it's not being updated?
<ksson> EliasAmaral: haven't used omake a lot
<ksson> and ocamlbuild is distributed with ocaml
<EliasAmaral> hm
<EliasAmaral> i just use plain old makefiles
<mrvn> yakischloba: so have a rule for %.cmi, %.cmx and one to link.
<ksson> EliasAmaral: that's ok as well :) (i've done that for quite a while)
<EliasAmaral> ... but when things gets complicated, it's a pain to track dependencies
<yakischloba> mrvn: yea I just never got very familiar with Makefiles so I'm hoping to cheat and use something more simple ;)
<ksson> yakischloba: if you try ocamlbuild, use the findlib plugin
<EliasAmaral> makefiles are simple, but aren't very powerful
<yakischloba> heh. quite simple.
<mrvn> Good enough to write something quickly that might never get published.
ygrek has quit [Remote closed the connection]
<EliasAmaral> kefiles actually are much more powerful than what i usually need. but i just don't know how to do some things (like a variable number of dependencies)
<ksson> EliasAmaral: what do you mean by "variable dependencies"?
<thelema> automatic dependency tracking?
<thelema> s/tracking/management/
<ksson> you mean, changing dependencies during the build?
<ksson> or detecting dependencies automatically (for example between ocaml files)?
<EliasAmaral> i may do "something: $(DEPENDENCIES)" but i don't know how to make it to compute this using a external program (it doesn't need to be something very elaborated)
<EliasAmaral> and i actually never used findlib
<thelema> EliasAmaral: the original ocaml plan (used by xavier) is ocamldep to create a .depend file and [include .depend] at the end of the Makefile.
<EliasAmaral> maybe there is a straightforward way to do it in makefiles. but my makefiles usually are as simple as that mrvn's link
<EliasAmaral> thelema, this is my point: you have to generate another makefile, right?
<ksson> EliasAmaral: yes and no, you can just include the .depend in the Makefile
<thelema> no.
<EliasAmaral> Hmmmmm.
<thelema> makefiles can include other files in them. You generally have to run make twice, once for [make depend] and once for [make all]
<ksson> there is a generic makefile for ocaml by jean-christophe filliatre
<ksson> which uses this trick
<ksson> (bottom of the page)
<EliasAmaral> hmm :)
<EliasAmaral> Jon Harrop is that guy that is working on something called "hlvm"?
<ksson> yeah
<EliasAmaral> I found quite confusing that there is two hlvm: one is his, the other is on top of llvm
<ksson> are there two?
<EliasAmaral> or they are the same?
<ksson> his hlvm is based on llvm iirc
<EliasAmaral> this news doesn't cite jon harrop
<EliasAmaral> and seems to be talking about a unrelated project
<ksson> ah indeed, i wasn't aware of this
<ksson> but they seem to have different goals
<thelema> this hlvm is different
<thelema> apparently jon wasn't aware of this hlvm when he named his language.
<ksson> anyway, this hlvm merged with llvm, as your link states :)
<mrvn> How do I use something from the parent module if the module has something with the same name?
<EliasAmaral> but since they merged, the word "hlvm" in the context of llvm is more likely to refer this merged hlvm and not the jon's hlvm.. even if it was created before
<EliasAmaral> (it seems to be a front-end, not something that was absorbed and became unnamed after the merge)
<yakischloba> I'm trying to some callback-oriented stuff and I need to pass the calling object into the callback function, but you can't pass 'self' to anything outside of the class. What is the way to handle this?
<EliasAmaral> mrvn, i think you have to create a local binding before shadowing the parent's name
<mrvn> EliasAmaral: It is a type
<EliasAmaral> a local type :) if type a = b, a is compatible with b? (i forgot)
<mrvn> let t = Foo type bla = Foo | Bar ... might work.
<mrvn> yakischloba: you can if you cast it
<EliasAmaral> let t? modules are first class values?
<yakischloba> mrvn: oh, how?
<mrvn> yakischloba: (self :> Name)?
<mrvn> EliasAmaral: Foo is a constuctor
<EliasAmaral> mrvn, how a constructor could receive a type as parameter?
<mrvn> EliasAmaral: it doesn't. the type ... is a new line
<yakischloba> mrvn: works great, thanks.
<EliasAmaral> mrvn, oh
<EliasAmaral> i remember now, this is _exactly_ what prevented me to use this approach yakischloba. to see that i would need a coercion seemed that this whole idea is bad
<mrvn> EliasAmaral: let t = Foo;; type bla = Foo | Bar;; let f = function Foo -> parent_f t | Bar -> bar
<EliasAmaral> but maybe now i am more pragmatic
<yakischloba> EliasAmaral: shrug. perhaps there are implications that I am not aware of.
<mrvn> EliasAmaral: that you need a coercion is just a little bit of syntactic lebertran
<mrvn> (opposite of suggar)
<yakischloba> I am still clinging to concepts from other OO languages, I don't expect that I will be able to do everything the 'right way' immediately :)
<mrvn> yakischloba: There is a difference between returning the self type or the Name.
<EliasAmaral> but i needed to make many :> across the code.. it was ugly. ultimately i was a bit sad with ocaml OO *just because of this small syntax problem* (but after this, i discovered that OO from most other languages can't do the things I consider "essential"...)
<mrvn> EliasAmaral: why do you return self so often?
<EliasAmaral> i don't remember very well. but it was this callback problem: I needed to make a method in a object that would pass itself to a function that could call many of its other methods
<EliasAmaral> i just liked this idiom :)
<mrvn> EliasAmaral: why not make the callback a method of the object?
<ksson> i don't see the problem ...
<ksson> could you give an example?
<mrvn> ksson: I think you can't write: let call_with_self foo fn = foo#fn
<ksson> ah, taking the method to call as an argument
<ksson> no, indeed you can't
<mrvn> EliasAmaral: you could write your callback as (fun () -> self#bla)
<EliasAmaral> no, it was something like: let f obj = if .. obj#somethign .. else if .. obj#somethingelse ..
<EliasAmaral> so i had a method like: method pass_itself = f (self :> class)
<mrvn> EliasAmaral: then use let f obj = obj#f and put the if into the class.
<EliasAmaral> i wanted to have some freedom to change f, so actually it was method pass_itself f = f (self :> class)
<EliasAmaral> or to switch between many fs
<ksson> EliasAmaral: i think that should work
<mrvn> EliasAmaral: yeah. I know the problem.
<ksson> maybe you need some type annotations
<EliasAmaral> and this works. with the annotations.
<mrvn> coercion is fine there or wrapping the obj into a closure.
<mrvn> matter of taste
<EliasAmaral> i think that some ocaml gurus here said it had something to do with type inference. it would become too complicated without this coercion
<EliasAmaral> (or maybe impossible)
<ksson> do you mean sth like this?
<ksson> i had to put an annotation there, though
<EliasAmaral> do you know that site that actually runs the code?
<EliasAmaral> a pastebin that runs the code (in c++, c, ocaml..)
<EliasAmaral> i don't remember the name
<ksson> me neither :) but i think i have seen it already
<EliasAmaral> method pass_itself f : 'a = f self , the annotation you needed was.. that : 'a?
<EliasAmaral> ah.
<EliasAmaral> yeah, and that ['a]
<mrvn> But then you have type 'self instead of Name.
<ksson> yes, otherwise ocaml complained about type variables that can't be generalized
<EliasAmaral> i don't understand very well why that ['a] is necessary. and why this is instead of the (self :> a) i was thinking..
<ksson> EliasAmaral: it's not a coercion, it's an annotation
<EliasAmaral> :> is a coercion
<EliasAmaral> : is an annotation
<EliasAmaral> right?
<mrvn> EliasAmaral: With 'a don't you need coercion when calling foo_derived#pass_itself foo_wanting_function?
<ksson> mrvn: what's Name ? (i think i missed some lines in my client)
<mrvn> ksson: The name of the class.
<ksson> ah
<EliasAmaral> mrvn, i don't know anymore, i though i did
<mrvn> With (self :> Name) you don't as it already coerces to the base class.
<mrvn> usualy I would write a as_base method and the pass_itself f = f (self#as_base)
<EliasAmaral> Hmmm.
<mrvn> if you need the (self :> Name) in mutliple methods.
* EliasAmaral don't know exactly why the coercion to the base class is needed. maybe because he doesn't know what is a coercion
<ksson> ah ok, so you mix this with inheritance, and hence the coercion
<mrvn> ksson: yep, only reason why it needs it
<EliasAmaral> hmm
<ksson> ok
<mrvn> When you want to put types Foo and Bar (based on Blub) into a Blub list then you need to use (foo :> Blub) and (bar :> Blub) or foo#as_blub and bar#as_blub in my case.
<mrvn> Can't remember why the #as_blub was better.
<mrvn> bed calls
<EliasAmaral> hm, bye
<EliasAmaral> i will maybe try this again later
<ksson> bed calls me too
<yakischloba> hmm. is it common for ocaml programs to seg fault?
<EliasAmaral> if you turn down some verifications, yes
ksson has quit [Read error: 60 (Operation timed out)]
<EliasAmaral> or if you use Obj.magic
<EliasAmaral> or if you use external functions to C
<EliasAmaral> yakischloba, there is a compiler switch to do exactly this
<EliasAmaral> it disables array bound checking
<EliasAmaral> wow, how you executed this?
<yakischloba> i presume it's happening using Unix.recv
<EliasAmaral> it was compiled by ocamlopt?
<yakischloba> yes
<EliasAmaral> Unix.recv will not do any crash if you use the bound protections.. i think
<EliasAmaral> the ocaml wrappers are "safe"
<yakischloba> what do I do to use the bounds protection?
ikaros has joined #ocaml
<EliasAmaral> yakischloba, what are the compilation options you are using?
<EliasAmaral> you use them by default.. and, after this, it will just throw an exception
<EliasAmaral> man ocamlopt (i don't have it installed here)
<yakischloba> ocamlfind ocamlopt -linkpkg -package unix -o my_executable file1.ml file2.ml file3.ml
<EliasAmaral> o.o
<yakischloba> heh. i suspect this is a bug.
<EliasAmaral> ok maybe you need someone else to verify this. but, ocamlfind has a dry run?
<EliasAmaral> yakischloba, this may be a bug in your program, but it shouldn't crash. :(