testcocoon has quit [Quit: Coyote finally caught me]
frogfoodeater has quit [Ping timeout: 256 seconds]
tootooroo has quit [Ping timeout: 256 seconds]
ggole has joined #ocaml
ttamttam has joined #ocaml
tootooroo has joined #ocaml
tootooroo has quit [Quit: Brain.sys has encountered a problem and needs to close. We are sorry for the inconvenience.]
tootooroo has joined #ocaml
ocp1 has joined #ocaml
<adrien_oww>
\o
<emias>
o/
eikke has joined #ocaml
ontologiae has joined #ocaml
tane has joined #ocaml
Neros has quit [Ping timeout: 258 seconds]
beckerb has joined #ocaml
tootooroo has quit [Ping timeout: 245 seconds]
eikke has quit [Ping timeout: 260 seconds]
eikke has joined #ocaml
eikke has quit [Ping timeout: 240 seconds]
eikke has joined #ocaml
Neros has joined #ocaml
jbrown has joined #ocaml
mort___ has joined #ocaml
ggole has quit [Remote host closed the connection]
ggole has joined #ocaml
tootooroo has joined #ocaml
mfp is now known as mfp_
tootooroo has quit [Ping timeout: 256 seconds]
LeNsTR is now known as lenstr
mfp_ has quit [Ping timeout: 256 seconds]
mfp_ has joined #ocaml
ulfdoz has joined #ocaml
osa1_ has joined #ocaml
ollehar has joined #ocaml
Yoric has joined #ocaml
mfp_ is now known as mfp
mcclurmc has joined #ocaml
<flux>
so what's the best safe way to do programs employing multiple cores in ocaml these days? jocaml?
<flux>
or just try to formalize everything as map/reduce and use parmap?-)
<emias>
G'old processes + message passing? (If you don't need shared memory.)
<flux>
well, it's a chore to arrange all that
<flux>
is there a library to make it simple?
<rixed>
flux: It's a chore to work with many threads aas well
<flux>
well, yes. but let's consider a model similar to Apple's Great Central Dispatch.
<flux>
you have n worker threads, n = amount of cpu's
<flux>
then you have a function to submit work
<flux>
val submit : (unit -> unit) -> unit
<flux>
and whenever a task ends up blocking, it is put back to the work queue
<flux>
add some Lwt-like magic over top of that and you would have a very nice system for splitting all kinds of work into smaller pieces
<flux>
I think that would end up costing a lot if it were done in a process model. but maybe I'm wrong. maybe I should implement something like that :)
<companion_cube>
isn't mmap doing this?
<flux>
what mmap?
<companion_cube>
or nmap, I can't recall
<flux>
mmap is a system call, nmap is a port scanner :)
<flux>
you don't mean parmap?
<adrien_oww>
:D
<companion_cube>
nproc
<flux>
ah, it's on my to-check-out-list
<companion_cube>
sorry, I'm confused by all those names ^^
<flux>
purple link in google :)
<companion_cube>
I just remembered having seen something like this on the ML
<flux>
nproc seems, from the comments of nproc.mli, quite similar to what I'm talking here
<flux>
it doesn't support exceptions though. could be built upon it I imagine.
ontologiae has quit [Ping timeout: 264 seconds]
<ousado>
flux: have you seen ocamlnet?
<flux>
ousado, I've seen it, but it doesn't cover my criteria of safety
<flux>
but I suppose that's one thing I should try out as well
<flux>
sadly I've done lately only one computationally expensive ocaml progra, and not much anything else. and that was covered very nicely by Parmap
<flux>
but I should say that my interest in this has greatly increased since I got my 8-core AMD this week...
<mfp>
flux: the reason why nproc does not support exceptions is that you cannot marshal and catch them across processes
<flux>
mfp, hmm, why not?
<mfp>
iow., if you marshal say End_of_file and try to catch it in another process with | End_of_file -> ... it will not match
<flux>
lack of support? or is it very difficult to support?
<mfp>
the way exns are implemented
<mfp>
there's an entry in the BTS for that
<mfp>
too expensive to enable cross-process catching IIRC
<flux>
mfp, do you happen to know some nice keywords for that bug?
<flux>
ah, bug 1961
<flux>
" This explains why you can't marshal an exception in one process, send it over a channel, unmarshal it in another process, and expect it to make any sense at all, because the linker's tag selection is likely to be different in the two processes."
<jbrown>
https://github.com/mlin/forkwork (that I posted yesterday too, but still haven't actually tried :-)) supposedly has some solution for handling exceptions from child processes
<flux>
but isn't the tag going to the same in this case
<flux>
as the processes are the 'same', just forked
<flux>
or are the tags being lazily generated..
<mfp>
read on "Why doesn't it work within the same process? This is most likely because the exception tag is ..."
<flux>
ah, it explains 8-)
<flux>
how about a special exception marshalling feature to be used in this case.. it could preserve those pointers as is?
<flux>
of course, it still wouldn't be able to copy recursive structure that might contain exception values
<flux>
but at least there would be a way to make them pass
<flux>
in fact, maybe that kind of marshalling could be written in plain ocaml, by (ab)using the Oo module?
<flux>
hm, Obj-module that is
<emias>
flux: Why do you think your model would cost a lot when using processes? Unless you make heavy use of shared memory, processes should usually be more effective in making use of multiple cores than threads.
<ousado>
I don't think there's a real difference
<emias>
ousado: You save all the register synchronization foo required by POSIX thread semantics when using processes.
<ousado>
threading done right uses some kind of message-passing, you can use lock/wait-free queues for that
<ousado>
on most architectures at least
<flux>
emias, well, I don't have a good reason. emias, it just feels to me that if I have code that manipulates all pixels in the screen in a distributed manner, it results in the whole screen being copied, possibly multiple times, maybe with less cache benefits
<emias>
ousado: Sure, but the OS still has to do much useless work just in case you access the shared memory.
<ousado>
emias: in case of threads that would be any memory
<emias>
flux: Yes, stuff like that might be a good use case for threads with shared memory.
<emias>
flux: But there are many use cases where I'd view separate processes and message passing as the appropriate model, not just because OCaml has no proper thread support. And emulating that model using POSIX threads is not necessarily the most effective solution.
<flux>
emias, well, I have at least one counter example: exceptions don't work in OCaml across processes 8-)
<flux>
but, off to find to food ->
groovy2shoes has joined #ocaml
<ousado>
emias: the only benefit for threads over processes I see is in being able to pass substantial amounts of data between threads without actually copying.
<emias>
ousado: Yup.
* emias
needs food as well.
<ousado>
.. and for scenarios where that's important, one would like to avoid having a multi-threaded GC around, I guess
ollehar has quit [Ping timeout: 245 seconds]
groovy2shoes has quit [Quit: Computer has gone to sleep]
Neros_ has joined #ocaml
Neros has quit [Ping timeout: 240 seconds]
frogfoodeater has joined #ocaml
<Kakadu>
You will never beleive me but OCaml+QML forces me to hack opam, because I use ocaml-syck package which is available only in bazaar repo
groovy2shoes has joined #ocaml
<flux>
but maybe some reasonable combination of message passing with some sharing where needed would be nice
<flux>
sadly there is no One Package to do it all, but maybe Netcaml and Nproc work together
groovy2shoes has quit [Quit: Computer has gone to sleep]
osa1__ has joined #ocaml
osa1_ has quit [Ping timeout: 264 seconds]
_andre has joined #ocaml
cthuluh has quit [Ping timeout: 256 seconds]
cthuluh has joined #ocaml
thomasga has quit [Quit: Leaving.]
thomasga has joined #ocaml
mcstar has joined #ocaml
testcocoon has joined #ocaml
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
sepp2k has joined #ocaml
sepp2k has quit [Remote host closed the connection]
sepp2k has joined #ocaml
Neros_ has quit [Ping timeout: 240 seconds]
ulfdoz has quit [Ping timeout: 245 seconds]
ikudrautsau has quit [Ping timeout: 240 seconds]
ontologiae has joined #ocaml
zbroyar has joined #ocaml
ousado has quit [Ping timeout: 260 seconds]
ousado has joined #ocaml
ikudrautsau has joined #ocaml
q66 has joined #ocaml
ttamttam has quit [Quit: ttamttam]
chambart has joined #ocaml
awm22 has quit [Ping timeout: 245 seconds]
xavierm02 has joined #ocaml
RagingDave has joined #ocaml
ulfdoz has joined #ocaml
anderse has quit [Quit: anderse]
ttamttam has joined #ocaml
chambart has quit [Ping timeout: 256 seconds]
frogfoodeater has quit [Ping timeout: 248 seconds]
thomasga has quit [Read error: Connection reset by peer]
thomasga has joined #ocaml
fraggle_laptop has joined #ocaml
smondet has joined #ocaml
chambart has joined #ocaml
ocp1 has quit [Ping timeout: 246 seconds]
hkBst has quit [Quit: Konversation terminated!]
awm22 has joined #ocaml
chambart has quit [Ping timeout: 256 seconds]
zpe has joined #ocaml
smondet has quit [Ping timeout: 246 seconds]
chambart has joined #ocaml
smondet has joined #ocaml
r126l has quit [Quit: leaving]
sgkim126l has joined #ocaml
darkf has quit [Quit: Leaving]
walter|r has joined #ocaml
cago has left #ocaml []
mika1 has quit [Quit: Leaving.]
<tonyg>
hi all. is oc4mc alive at all? what are people doing these days to make use of multiple cores? is there a feature akin to Racket's "places", for example?
<Kakadu>
tonyg: afaik, OCamlPro is doing something but it is named other way
<walter|r>
and /usr/local/godi/lib/ocaml/pkg-lib/sdl/sdl.cmxa
<walter|r>
both define a module named Sdl
<walter|r>
Command exited with code 2.
<sgnb>
walter|r: try without "-lib sdl"
<sgnb>
it is redundant with -package foo
milosn_ has quit [Ping timeout: 260 seconds]
tootooroo has quit [Quit: Brain.sys has encountered a problem and needs to close. We are sorry for the inconvenience.]
<walter|r>
when i remove -lib sdl, i get
<walter|r>
Undefined symbols for architecture x86_64:
<walter|r>
and it lists a bunch of symbols from libSDLMain.o
rossberg has quit [Read error: No route to host]
<sgnb>
walter|r: is there any example to play with?
<sgnb>
well, I've just tried testsdl_1.ml from http://wiki.njh.eu/OCaml_and_SDL with "ocamlbuild -use-ocamlfind -package sdl test.native" and it works
<sgnb>
...on Debian... maybe something is wrong with your installation
<sgnb>
walter|r: could you try it on your side?
mort___ has quit [Quit: Leaving.]
<walter|r>
i think something is wrong with my installation of sdl
<walter|r>
it works on ubuntu for me
mattrepl has joined #ocaml
Kakadu has quit []
cthuluh has quit [Ping timeout: 255 seconds]
cthuluh has joined #ocaml
eikke has quit [Read error: Operation timed out]
wwilly has quit [Quit: Leaving]
<sgnb>
good
Yoric has joined #ocaml
UncleVasya has joined #ocaml
tootooroo has joined #ocaml
walter|r has quit [Quit: This computer has gone to sleep]
yacks has joined #ocaml
yacks has quit [Max SendQ exceeded]
UncleVasya has quit [Ping timeout: 252 seconds]
yacks has joined #ocaml
<vbmithr>
Hi
<thelema_>
hi
thelema_ is now known as thelema
<vbmithr>
Do somebody knows the diff between the -cclib and -ccopt options of ocamlopt ?
<thelema>
vbmithr: yes, argument order in the gcc commands that are constructed
<thelema>
--ccopt goes before the compiled library
<thelema>
-cclib goes after
<vbmithr>
-cclib <opt> Pass option <opt> to the C linker
<vbmithr>
-ccopt <opt> Pass option <opt> to the C compiler and linker
<vbmithr>
The doc says that
<vbmithr>
apparently -cclib is just for the linker, in addition of that
<thelema>
true.
<vbmithr>
Ok, thank you very much
<vbmithr>
I’m trying to fix the OCaml build rules in Xen
<thelema>
but normally the c compiler isn't used to compile
<vbmithr>
what do you mean ?
<thelema>
gcc is mostly used by ocamlopt for linking
<vbmithr>
yeah, I see
<thelema>
only if you're compiling C programs using ocamlopt does -ccopt get used for compiler arguments
<vbmithr>
C is compiled directly using the cc
<vbmithr>
ok
<vbmithr>
understand
<thelema>
almost always -cclib and -ccopt go to linking
ontologiae has joined #ocaml
yacks has quit [Ping timeout: 260 seconds]
anderse has joined #ocaml
osa1_ has joined #ocaml
anderse has quit [Client Quit]
milosn has joined #ocaml
cdidd has quit [Remote host closed the connection]
ikudrautsau has quit [Ping timeout: 248 seconds]
tianon has quit [Ping timeout: 240 seconds]
osa1_ has quit [Ping timeout: 248 seconds]
ousado has quit [Ping timeout: 276 seconds]
ttamttam has quit [Remote host closed the connection]
ttamttam has joined #ocaml
Kakadu has joined #ocaml
ousado has joined #ocaml
walter|r has joined #ocaml
awm22 has quit [Quit: Leaving.]
yacks has joined #ocaml
yacks has quit [Max SendQ exceeded]
yacks has joined #ocaml
yacks has quit [Max SendQ exceeded]
* Kakadu
hopes he'll share his QML+OCaml experience next week
<orbitz>
nice
<Kakadu>
the main problem is building all of that
<Kakadu>
generator depends on ocaml-syck which is not available in opam. More of that: it only available in bazaar. I have created some patches to opam but it will take some time to integrate them
beckerb has quit [Quit: Konversation terminated!]
walter|r has quit [Quit: This computer has gone to sleep]
<Kakadu>
and also it depends on Qt5 which take some time to compile
chambart has quit [Ping timeout: 256 seconds]
anderse has joined #ocaml
anderse has quit [Client Quit]
Anarchos has joined #ocaml
ousado has quit [Ping timeout: 245 seconds]
ousado has joined #ocaml
<wmeyer>
Kakadu: great! and my requriments regarding GUI are rather simple :-) If you polish the code generator, I'd be just very happy to see it.
<Kakadu>
translate from OCaml language to Polish language? Are you serious? :)
<wmeyer>
I'd prefer if we had more resources on wikipedia at first :-)
<wmeyer>
regarding ocaml-syck, I'd just commit that in git out of source tree
mort___ has joined #ocaml
<wmeyer>
and I say rather good things always, about bindings for toolkits.
<wmeyer>
additional are always welcome
zpe has quit [Remote host closed the connection]
yacks has joined #ocaml
ocp has joined #ocaml
yacks has quit [Max SendQ exceeded]
<orbitz>
Hrmm.. this is going to be a fair amount of work i think
<Kakadu>
not so much. QML differs from other toolkits. I don't need to write bindings to many classes because they are does not exist
<wmeyer>
orbitz: no, if the bindings for GUI are good, they are not too difficult to maintain.
leoncamel2 has quit [Ping timeout: 252 seconds]
<wmeyer>
and at this stage I will stop and go to bed, and wait for the warmer weather to take my netbook outside tomorrow :-)
<Kakadu>
is it snowy in the UK?
jonafan_ is now known as jonafan
<wmeyer>
it's a bit cold here, not snowy
<wmeyer>
but windy
<orbitz>
wmeyer: oh i'mtalking about my own problem
<Kakadu>
hehe
<orbitz>
trying to do an initial stab at uCore
<wmeyer>
orbitz: oh micro core
<wmeyer>
cool project
<orbitz>
indeed
<Kakadu>
on 1st April The winter have dropped 30sm of snow
<orbitz>
basically I'm cloning core, and just deleting stuff to get to my size goal (100kb)
<Kakadu>
it's a little bit snowy today. So, wmeyer, don't say that your weather is cold)
<wmeyer>
Kakadu: ok, thanks, and sorry to hear that
<wmeyer>
orbitz: It's a worthwhile project and I like your approach
<orbitz>
first thing to delete: sexp and bin_io
<orbitz>
i don't know anything about oasis/omake though
<wmeyer>
picking the modules is not easy, all of them are precious
<wmeyer>
Core uses some shell scripts
<wmeyer>
to generate Oasis
q66 has quit [Remote host closed the connection]
<orbitz>
Well the way I look at it: I need to remove a lot of the sytnax stuff, most of the containers (if RAM is your concern, you're not going to be doinga lot of fancy datastructures)
<wmeyer>
I'm happy with it, but it's a complex build system
q66 has joined #ocaml
troydm has joined #ocaml
<mfp>
orbitz: how about an automated rewrite to get rid of the Core pack?
<mfp>
then let ocamlopt link only the required modules
<orbitz>
mfp: what about things in modules?
<mfp>
that should be a good start... then you could simplify manually the modules you do use
<orbitz>
mfp: by getting rid of the pack, do you mean making a core.ml(i) and doing module String = Core_string yadda in it?
<mfp>
no no
<mfp>
proceed as follows:
<mfp>
for each xxx.ml(i) file, rename it to core_xxx.ml(i)
<mfp>
then in all other files, do s/Xxx/Core_xxx/g
<mfp>
and remove open Core (if any) from all source files
<orbitz>
can I still keep the open Core.Std for users somehow?
<mfp>
that way, each module refers only to the compilation units it does use, not to a monster module/pack that will link everything into your app
<mfp>
that wouldn't work, you'd be back to the pack thing
<mfp>
unless you want to provide a Core.Std for lib users, but allow to use e.g. Core_bag directly for those who care about exec size
<orbitz>
You can do it without a pack, I thought. for example Std in Core has a module String = Core_string
<mfp>
that's basically equivalent to a pack
<orbitz>
ok
<orbitz>
becuse Std references all these modules, even if you don't call them they will get linked in
<mfp>
right
<mfp>
who's the end user here?
<orbitz>
people who like the interface to core but want small execs
<mfp>
or rather, what are you optimizing? the size of some executable or a lib provided to 3rd party users?
eikke has joined #ocaml
<orbitz>
the most preferable method would be if they only use the subset of Core that is small, they can just change waht library the ylink against and still get a reasonable exe size
<mfp>
then the mechanical rewriting I described would do
<orbitz>
But, if I can provide that, and a method to make it smaller if the ycare about by accessing just the modules they want to use, taht would be nice
<orbitz>
mfp: thanks
<mfp>
it'd essentially allow to use Core the same way as batteries -> open Batteries, use XXX for convenience, or referer directly to the module BatXXX
<orbitz>
nice
<mfp>
you can have both the monster module with all the aliases for convenience and the largely independent modules, which can be linked separately
<orbitz>
and from there I can delete things in modules that make individual libraries too small (for example each modulbe includes' a lot of other modules to offe rcontianers
<mfp>
hmm in fact, there's no open Core in core's own modules, is there?
<mfp>
not needed/possible
<orbitz>
There are a few
<orbitz>
oh no
<orbitz>
./info.ml: open Core.Std
<mfp>
so all you really have to do is, for each xxx.ml(i), generate a core_xxx.ml that does include Xxx
<orbitz>
only one I see
gnuvince has quit [Remote host closed the connection]
* mfp
was looking at some old sources (107.01) with no open Core whatsoever
<mfp>
then if you can work around that one/rewrite that code/rm info...
<mfp>
you just have to generate core_xxx.ml* and you're done :)
<orbitz>
hah
<orbitz>
well a little bit more (I think) :)
<orbitz>
if I can do it mechanically like this it makes it easy to create the lib, just provide a shell script!
<orbitz>
I think mv'ing would be preferred, if possible, if this were to become a standable lib
<mfp>
now, if the namespace thing delivers, this might not be needed in a few months (?)
<adrien>
(besides the fact the namespace discussion has/had nothing to do on platform@)
<adrien>
the last proposals of namespaces I've seen were pretty far from perfect
<adrien>
I'd expect this to take some more time
<mfp>
they seem more ad-hoc than the initial exposition
<orbitz>
It also doesn't address issues if individual modules are too large, for example String module in Core offers half a dozen containers
yacks has joined #ocaml
<mfp>
Gabriel Scherer's formalization
anderse has joined #ocaml
gnuvince has joined #ocaml
mcclurmc has quit [Ping timeout: 256 seconds]
awm22 has joined #ocaml
ggole has quit []
mcstar has quit [Quit: mcstar]
smerz has joined #ocaml
Cyanure has joined #ocaml
foo303__ has quit [Ping timeout: 252 seconds]
foo303_ has joined #ocaml
<wmeyer>
adrien: mfp: orbitz: I think the chalenge would implementation at the moment, sadly I can't see this to be evening job
<orbitz>
wmeyer: implementation of what/
<adrien>
namespaces
<wmeyer>
orbitz:of namespaces
<orbitz>
oh, I don't have much faith in namespaces yet
<wmeyer>
but we need them!
<adrien>
wmeyer: that's actually also one of the thoughts I had with the proposals I've seen
<wmeyer>
and spec is not enough
<adrien>
they all seem fairly complex
<wmeyer>
they are complex, and don't propose any gradual phases and deliveries
<orbitz>
I forget who suggested it, but I'm a fan of just fixing 'packs'
<wmeyer>
what Alain Frisch done was the right thing to do
<orbitz>
and adding a root module name space
<wmeyer>
it was excellent work with the extension_point branch
<wmeyer>
it was pragmatic, and discussed on the same level
<wmeyer>
orbitz: packs are sub optimal
<orbitz>
why
<adrien>
ah, that's what it's about :P
<wmeyer>
I think they are, they collect modules as a single module
<wmeyer>
and single compilation unit
<orbitz>
why sub optimal
<wmeyer>
so the biggest chalenge is how modules are represented
<wmeyer>
they are represented as data structure with fields
<wmeyer>
in memory
<wmeyer>
namespaces work purely on environment
<wmeyer>
if you open the namespace you don't bring the data structure to scope internaly
<wmeyer>
but you just bring to scope some environment
<wmeyer>
this is the major difference
<wmeyer>
and hence, there is a need for something better than pack
<orbitz>
why can't that be fixed in packs?
ttamttam has quit [Remote host closed the connection]
<wmeyer>
because packs are modules
sepp2k has quit [Remote host closed the connection]
<wmeyer>
not namespaces
<wmeyer>
how you merge modules
<wmeyer>
impossible, without creating a module
<orbitz>
Why can't the compiler befixed to handle packs in this way?
<wmeyer>
where with namespaces you just open environment
<orbitz>
i.e. it sounds like an implemetnaiton problem to me
<orbitz>
not a fundamental problem with packs
<ousado>
hello camlers!
<wmeyer>
it's semantic problem orbitz
<wmeyer>
fundamental difference
<wmeyer>
hello ousado :-)
<wmeyer>
orbitz: while I agree packs might be enough
<ousado>
installed wayland today, looks promising
<wmeyer>
in most cases
mcclurmc has joined #ocaml
<wmeyer>
the problem you have with Core is because of packs i think, does core pack the modules into Core?
<wmeyer>
cool
<orbitz>
yes it does
<wmeyer>
so now, you have to load the whole single pack
<wmeyer>
always
<wmeyer>
from file system and into memory
<orbitz>
i know, but that 's an implementation detail
<orbitz>
that doesn't mean the semantics of packs are wrong
<wmeyer>
nope
<wmeyer>
packs are namespaces if that was fixed
<orbitz>
I don't know hwo a pack is implemented now, but it coudl just be an archive of .cmo's andthe compiler pulls out each cmo as it needs it
<wmeyer>
orbitz: I am sorry, I have to admit I am pretty sure the modules can't be just packed
<orbitz>
but, for me, compilation time is not a problem, it's really that dead code isn't eliminated, and i have no way ot accessing a module by it's 'full name'
<wmeyer>
it will not be
<wmeyer>
because it's referenced by the dictionary
<wmeyer>
and the dictionary is a single structure
<orbitz>
I'm confused because this still sounds like implementation details, not ones that matter to me as a user
<wmeyer>
so I am not happy with packs myself
<flux>
I think the problem with packs being compiled in as full could be solved, but it's not a small modification
<wmeyer>
it matters, hence uCore orbitz
<flux>
of course, I know nothing of ocaml compiler internals :)
<orbitz>
wmeyer: I know, but we're talking about the future, not now
<flux>
that's a lot to read, and I'm going to bed now, good night :)
<wmeyer>
orbitz: while I like simple solutions and packs served me well, and i really like to pack modules they served me well, but I admit want avoid just packing modules
<wmeyer>
flux: good night :-)
<wmeyer>
orbitz: i really think we should implement namespaces :-)
_andre has quit [Quit: leaving]
<adrien>
well, I think that the need for -for-pack is quite telling of how much packs impact what you build
<mfp>
orbitz, flux: Daniel Bünzli used to defend vehemently that very position
<adrien>
but the namespaces proposals I've seen seemed to be even worse
<wmeyer>
I like four-pack of beer better than -for-pack
<mfp>
(that there's no need to introduce namespaces, that packs are fine and there's just an implementation issue)
<adrien>
:-)
<wmeyer>
adrien: they solve specific problems, and the spec is highly formal.
<orbitz>
mfp: What do yo uthink? I'm mostly talking out of my butt since I don't know the impl, but to me it sounds like if you could fix packs impl + add an immutable root module, you'd make a lot ofprogress
<orbitz>
err, you'd solve the issues people have
<wmeyer>
that was Leo how convince him as far as I remember