<goncalo>
I'm running into a compiler error "Error: uuid.cmi is not a compiled interface" that I have no clue what to do about, breakage log here: http://pastebin.com/ErBTcvAn any ideas?
<thelema>
delete it and re-create?
<Anarchos>
goncalo it happens if you change your version of compiler and still use old cmi files
<thelema>
I get that error when I dropbox sync between home and work and have different compiler versions
<Anarchos>
goncalo as a cmi is a generated file, you can delete it without problem, of course if you have the source available
<goncalo>
sadly, deleting it doesn't appear to be enough
<goncalo>
the same error strikes back
<goncalo>
I have these files in the directory -- could it be any more of those "old files in a new compiler" causing it to err? >>> Makefile META.in uuid.annot uuid.cma uuid.cmi uuid.cmo uuid.ml uuid.mli
<thelema>
goncalo: *.c* can be removed, as well as *.annot
<thelema>
I dunno - what's happening looks correct.
<thelema>
maybe -c isn't right for generating uuid.cmi
<thelema>
try deleting that line from the makefile.
<thelema>
the .cmi file should automatically be generated when the .ml file is compiled
Smerdyakov has quit [Quit: Leaving]
<NaCl>
woo more dep resolving
<NaCl>
seems that my attempts to placate the openSUSE people has fallen on deaf ears
<goncalo>
eh.. Error: Could not find the .cmi file for interface uuid.mli.
<goncalo>
:)
<thelema>
? you can't placate openSUSE about ocaml deps?
<NaCl>
thelema: no, trying to get a dev project for ocaml has been slow.
<thelema>
goncalo: very odd. I almost want to suggest ocamlbuild, but I forget how to trigger .cma and cmxa creation - is it .module files?
<NaCl>
thelema: and dep resolving = diml's new toplevel
<thelema>
goncalo: the last question wasn't for you, for everyone
<thelema>
NaCl: many deps are in oasis-db, if that helps.
<NaCl>
they were all released today
<NaCl>
thelema: more like he pushed out three packages that depend on each other
<goncalo>
thelema: I actually have very minimal experience with ocaml and most of my experience is in reading the code, but not actually using the toolchain or writing code... this is me trying to build a set of libs from the xen-api-libs on ubuntu 11.04 :)
<thelema>
goncalo: no worries - once I find the code, I'll give it a crack on my machine
* NaCl
goes back to wondering whether he should continue making spec files
<goncalo>
the prob is, I have 3.11.0 in /usr/local/bin and and .2 in /usr/bin
<goncalo>
hopefully changing the path should fix it
<thelema>
yup, do get rid of one of those.
<goncalo>
yuo
<goncalo>
yup
<goncalo>
fixed
<goncalo>
thanks for your help! :)
<thelema>
you're welcome
<goncalo>
ah!
<goncalo>
Camlp4: Uncaught exception: DynLoader.Error ("pa_rpc.cma", "file not found in path")
<goncalo>
what about this? hah ;-)
<Anarchos>
goncalo this one is rather explicit you should fix it easily :)
<thelema>
do you have a pa_rpc file anywhere?
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<thelema>
Anarchos: fwiw, I get the same error - it seemd to be part of the ocaml package type-conv, try installing that library
<goncalo>
I have no idea -- let me see :)
<thelema>
I don't know the ubuntu name, sorry
<thelema>
oops, anarchos doesn't need to install that library
<goncalo>
well, the main issue was overcome -- compiling xen-unstable succeeds
<goncalo>
so I'll leave the failure on xen-api-libs for another day :)
<goncalo>
thanks thelema..
<thelema>
n/p
<goncalo>
note to self: pay attention to the output of the configure script
<thelema>
quite.
mfp has quit [Ping timeout: 250 seconds]
mfp has joined #ocaml
alfa_y_omega has quit [Ping timeout: 260 seconds]
alfa_y_omega has joined #ocaml
StepanKuzmin has quit [Remote host closed the connection]
dnolen has joined #ocaml
dnolen has quit [Client Quit]
dnolen has joined #ocaml
junsuijin has quit [Quit: Leaving.]
Julien_T has quit [Ping timeout: 276 seconds]
Julien_Tz has joined #ocaml
Julien_Tz is now known as Julien_T
iratsu has quit [Ping timeout: 255 seconds]
ulfdoz has joined #ocaml
dnolen has quit [Quit: dnolen]
ankit9 has joined #ocaml
ulfdoz has quit [Ping timeout: 252 seconds]
bacam has quit [Ping timeout: 264 seconds]
dcolish has quit [Ping timeout: 260 seconds]
dcolish has joined #ocaml
bobry has joined #ocaml
bacam has joined #ocaml
chrissbx has quit [Ping timeout: 240 seconds]
chrissbx has joined #ocaml
Ptival has quit [Quit: Quat]
ankit9 has quit [Quit: Leaving]
bobry has quit [Ping timeout: 250 seconds]
bobry has joined #ocaml
bobry has quit [Client Quit]
bobry has joined #ocaml
Ptival has joined #ocaml
nostrand has quit [Remote host closed the connection]
avsm has joined #ocaml
iratsu has joined #ocaml
eikke has joined #ocaml
StepanKuzmin has joined #ocaml
ankit9 has joined #ocaml
ftrvxmtrx has quit [Quit: This computer has gone to sleep]
dsheets has joined #ocaml
<dsheets>
When defining recursive closed polymorphic variants, i get : "Error: the type constructor foo is not yet completely defined" I also found: http://caml.inria.fr/mantis/view.php?id=4494 . So is there a way to do this or is this too far for the ocaml type system right now?
<eikke>
hija
avsm has quit [Quit: Leaving.]
larhat has joined #ocaml
<eikke>
for some benchmark, I need a whole lot of strings pre-allocated (about 50_000_000 of them, all fixed-size of 16 bytes)
<eikke>
I tried using an Array, but creating that array takes... quite some time
<eikke>
is there any better way?
<f[x]>
with 50M strings your benchmark will measure gc scanning these strings :)
<eikke>
that's a problem indeed (and one we're trying to 'solve')
<eikke>
creating the strings inside the benchmark loop (one for each call) has rather significant impact
<eikke>
so I figured pre-allocating them could help
<eikke>
I can't create one string and blit into it for every call, since the strings are stored in a Hashtbl instance as well, and as such shouldnt be mutated
dsheets has quit [Ping timeout: 252 seconds]
avsm has joined #ocaml
edwin has joined #ocaml
<f[x]>
I don't know what are you trying to do but I would've created one big string and use substrings of it (to save memory and gc overhead)
<f[x]>
esp as all your strings are fixed length
iratsu has quit [Ping timeout: 252 seconds]
ftrvxmtrx has joined #ocaml
<eikke>
won't substring (inside the loop) alloc new strings and copy content, as such creating 50M strings on the go, and introduce quite some GC work?
ranma42 has left #ocaml []
<f[x]>
not String.sub, but (string * int * int) as string slice
<f[x]>
and rewrite all string operations to operate on such slices
munga has joined #ocaml
ankit9 has quit [Ping timeout: 276 seconds]
<eikke>
f[x]: kinda hard, the external interface of the thing we're testing takes string arguments (and should continue doing so)
<eikke>
we're trying to figure out upper-bounds
<f[x]>
you can try a hack and allocate ocaml string in C heap (using correct caml value layout). gc won't follow such pointers and you can even set tag on array so that it won't scan array at all too
<f[x]>
but that's all hacks - in normal usage scenario if you really have 50M live strings you will pay for gc
<eikke>
in normal usage scenarios we wont :)
ankit9 has joined #ocaml
iratsu has joined #ocaml
thomasga has joined #ocaml
Amorphous has quit [Ping timeout: 264 seconds]
<thomasga>
any idea how to use camlp4lib without dynlink ?
<avsm>
thomasga: good question… as i'd like to statically link camlp4o+extensions into one native code binary to speed up compilation
<thomasga>
and I'll like to have export a library which uses camlp4 and do not have to link with dynlink every time :-)
Amorphous has joined #ocaml
<gildor>
eikke: I have played with this kind of setup
<gildor>
(lot of small strings)
<gildor>
eikke: if you generate 50M object, you should expect an heavy load on GC (because scanning 50M GC object is anyway heavy)
<gildor>
eikke: even if you don't need to go follow the pointer
<gildor>
eikke: my advice is to create a big string, and an array of integer
<gildor>
eikke: the array of integer as a whole should be a single GC object (if it is identified correctly as an int array)
<gildor>
eikke: and the big string is also a single GC object
lopex has joined #ocaml
<gildor>
eikke: furhter optimization, should include having a single 16B string to extract data from the big string and blit data
iratsu has quit [Ping timeout: 246 seconds]
<f[x]>
gc will scan array of integers :)
<f[x]>
(PR#5010)
StepanKuzmin has quit [Read error: Connection reset by peer]
<_habnabit>
I'll just drop the annotation for now, then. thanks.
<thelema>
at least nothing with special syntax - is it the same if you reverse the order of L5 and L6 in your paste?
<_habnabit>
oh, let me try.
lopexx has quit []
<_habnabit>
ah, no. if I just reverse it, it says 'unbound type key', and if I add 'type key', it complains about duplicate type names.
<thelema>
yup, you can't have duplicate type names... if you really wanted the annotation, you could paste the contents of Map.S and fix 'filter'
<_habnabit>
yeah, for now I think I'll just omit the annotation.
<_habnabit>
but long-term I'll end up dropping duplicate functionality like this.
<thelema>
wait, I thought that Map.filter was added in 3.12, or did you have your own Map.filter?
<_habnabit>
this is 3.11 still.
<thelema>
yes, that's what I thought. and there's stdlib Map.filter? hmmm...
<_habnabit>
no, there isn't. that was the point of BetterMap.
<thelema>
ah, you made your own bettermap.
<_habnabit>
hah, ocaml is complaining now about the inferred signature of the type.
<thelema>
got it.
<_habnabit>
probably because of the `include OM` bit.
<thelema>
hmm, I realize you're passing in the result of Map.Make - why not evaluate the functor yourself?
<_habnabit>
... or not? hmm.
<thelema>
module BetterMap (C: Comparable) = struct include Map.Make(C) let filter ... end
<_habnabit>
ah.
<thelema>
module IntMap = BetterMap(Int)
<thelema>
just a thought.
<_habnabit>
no reason that I can think of. there might've been when I wrote it originally.
<_habnabit>
huh, jeez. even clobbering the conflicting values like this, a bunch of my unit tests fail as soon as I make BetterMap include BatMap.Make instead of Map.Make.
<thelema>
really? I'm surprised - do your unit tests use equality improperly?
<_habnabit>
no, it's not equality on the maps themselves. it's the result of doing a lot of calculations involving maps and sets.
<thelema>
something big and complex and hard to track down the root cause, I'm guessing
<_habnabit>
pretty much.
<thelema>
just batMap and not batSet?
<_habnabit>
well, no, both batMap and batSet.
<thelema>
can you try either one with stdlib for the other?
junsuijin has joined #ocaml
<_habnabit>
yeah, I'm working on that now.
<_habnabit>
there shouldn't be any difference in total ordering of sets, right? one of the maps has a set as the key.
<thelema>
hmm, I'll look into that - I don't think we changed Set.compare
<_habnabit>
well, I'm digging through my code now. I'll tell you if I can narrow it down at all.
<thelema>
wait - there's no Set.compare - what function are you using for that?
<thelema>
methinks there should be Set.comapre
<_habnabit>
there isn't? hm, one second.
<thelema>
at least there's no batset.compare
<thelema>
ah, there is for functorized sets, not for polymorphic sets
<thelema>
n/m
<_habnabit>
haha, phew. I was pretty sure I hadn't implemented it myself.
<thelema>
It's possible that ordering has changed, as the internal structure of the sets may differ
<_habnabit>
oh, there's an assertion failing too. this might be enlightening.
<thelema>
hmm, it turns out that we borrow the internal structure and implementation of stdlib sets still
<thelema>
so batteries doesn't have a Set.compare function implementation
<_habnabit>
okay.
<thelema>
otoh, it does reimplement Set.add and remove (for polymorphic sets), so maybe there's a difference there
<flux>
hcarty, hmm, apparently the plplot bindings aren't in debian unstable?-(
bobry has joined #ocaml
avsm has quit [Quit: Leaving.]
<hcarty>
flux: No, sadly not. No one has made a package for them.
<hcarty>
And Debian packaging looks like deep, dark magic to my untrained eyes.
<hcarty>
One of the other PLplot developers has offered to package the OCaml bindings, but they have not had time
<flux>
if I have plplot installed on my system, can I use the source tree for the same files to build only the ocaml bindings?
<hcarty>
flux: Not in its current state. The whole thing (core library plus all language bindings) builds at once.
<flux>
I guess I'll just build it and the pick the ocaml bindings from that
<flux>
highly non-optimal :/
<flux>
hope the guy does step up to do the packaging
<hcarty>
flux: I emailed him to ask. There are no other OCaml folks among the PLplot developers, so I'm not sure how much will get done.
<hcarty>
flux: And contributions are welcome, of course :-)
<flux>
I don't -think- it should be a big task.. but nevertheles I'm sure it's a smaller task for him than for me :)
<flux>
I'm just trying to globally optimize the amount of work :)
<hcarty>
I've been contemplating creating a ocaml-plplot-minimal stand alone distribution. It would make the build process simpler, but it is also potentially a lot of work.
srcerer has quit [Remote host closed the connection]
avsm has joined #ocaml
srcerer has joined #ocaml
<_habnabit>
aha! narrowed it down considerably. if I do nothing but change `StringSet = BetterSet(Set.Make(OrderedString))` to `BetterSet(BatSet.Make(OrderedString))`, I get the failures.
<_habnabit>
so there's something different there.
<thelema>
_habnabit: ok, a problem with BatSet...
ftrvxmtrx has joined #ocaml
srcerer has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.17/20110420140830]]
ftrvxmtrx has quit [Client Quit]
<_habnabit>
well, a cursory comparison of behavior doesn't seem to yield any differences.
<_habnabit>
you said the only difference in the functorial interface is in add?
<thelema>
no
<thelema>
the functorial interface re-implements a bunch of functions locally.
<_habnabit>
ah.
<thelema>
I'm interested in what the root cause is, but if you need to get on with other work, just don't use batSet
<_habnabit>
well, let's see what functions I use on StringSet.
<thelema>
I'll bet the problem is in one of the last three
<_habnabit>
hmm, okay.
<thelema>
but just in case, I'll go over the others quickly
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<flux>
hcarty, bah, not even the debian source package dpkg-buildpackage's for me
<hcarty>
flux: That sucks - do you have all of the (very very large number of) build dependencies?
<hcarty>
A minimal PLplot build doesn't require a ton of external items, but the dependency list grows quickly once bindings and other optional pieces come into play.
<hcarty>
And I think most of those are enabled for the Debian build
<flux>
hcarty, apt-get build-dep should take care of that
<hcarty>
thelema: I wrote up a quick _oasis file for React. I won't be able to test it until later this evening at the earliest, but in theory that will open up the possibility of an installable utop from odb.
<hcarty>
flux: Hopefully so
<thelema>
hcarty: great
<hcarty>
flux: It looks like Sid has an older PLplot version as well. I don't remember what has changed since then.
<_habnabit>
aha! found something. hang on a sec...
<flux>
hcarty, heh, found out the reason why the build failed: /tmp is full :-)
<flux>
surprisingly it didn't quite pop up to me..
<flux>
I mean I didn't see it in the build logs
<hcarty>
flux: Ah, I suppose that could be a problem :-)
<hcarty>
That's odd
<hcarty>
_habnabit: What version of Batteries are you using?
<flux>
mount /tmp -o remount,size=90%, new try :)
<hcarty>
That's a rather unfortunate bug
<_habnabit>
hcarty, how can I find out?
<hcarty>
_habnabit: ocamlfind list |grep batteries
<hcarty>
_habnabit: That's probably the simplest way
<_habnabit>
says 1.4.0.
<flux>
hcarty, btw, do you happen to have an idea space does how much plplot take to build?
<flux>
oops, words totally in wrong order, strange mistake :)
<hcarty>
flux: I'm not sure - if a full test suite is run then multiple gigabytes. If not... it could be as much as 100 megabytes or a few hundred possibly.
<hcarty>
flux: I haven't done a full, all bindings + all output devices build in a while.
<flux>
well, it was around 2 gigabytes when it failed. it now has a few gigabytes more, should do it..
<hcarty>
I should soon though, as there is a development release planned for this weekend.
<thelema>
_habnabit: you're right - there's a problem with set.inter
<hcarty>
_habnabit: I think the Set and Map modules were largely rewritten for 1.4.0
<thelema>
# S.inter s s |> S.cardinal;;
<thelema>
- : int = 0
<thelema>
# S.cardinal s;;
<thelema>
- : int = 4
srcerer has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723]]
<_habnabit>
I get the same result with a set of any length; it's just that length four came up first in my test suite.
<thelema>
_habnabit: the same problem doesn't exist in the polymorphic sets, which is interesting...
<thelema>
at least for integers - maybe there's a difference between integers and strings. Testing polymorphic + strings and then functorized + integers
<thelema>
functorized sets fail on integers too
<thelema>
and succeed on strings
srcerer has joined #ocaml
rgee has quit [Read error: Connection reset by peer]
rgee has joined #ocaml
<thelema>
doh! see if you can spot the error:
<thelema>
let inter s1 s2 = t_of_impl (Concrete.diff Ord.compare (impl_of_t s1) (impl_of_t s2))
<thelema>
_habnabit: the functorized inter doesn't do inter, it does diff. Thanks for helping us find this bug.
<_habnabit>
oh, derp
<thelema>
a stupid copy and paste error.
<_habnabit>
haha, I was thinking "it must be something I'm unaware of in impl".
<thelema>
now I just have to figure out how to make 1.4.1 release - it looks like 1.4.0 was made oddly
<thelema>
(by me)
lopexx has joined #ocaml
drake01__ has joined #ocaml
drake01__ has quit [Read error: Connection reset by peer]
lopex has quit []
lopexx has quit [Client Quit]
drake01 has joined #ocaml
lopex has joined #ocaml
* thelema
makes a new release 1.4.0
<thelema>
err, 1.4.1
<_habnabit>
also, is there a function in batteries or camomile to go from a unicode code point to the utf-8 encoded string that represents it?
<thelema>
yes, one sec for me to find it
<thelema>
BatUTF8.of_char : UChar.t -> t
<_habnabit>
I was hunting through all the modules that seemed to make sense to me, but I couldn't find anything.
thomasga has quit [Quit: Leaving.]
<_habnabit>
oh, hah.
<thelema>
it was hiding between "empty" and "make"
<flux>
hcarty, it would be nice if plplot for ocaml installed the .mli file as well, not just the binaries
<flux>
but I finally managed to install them
<flux>
turns out the -real- reason for my trouble was the lack of camlidl.. obviously build-dep didn't get that, because the debian package didn't provide ocaml bindings :)
<_habnabit>
thelema, so, since I installed 1.4.0 with that odb.ml, how should I upgrade this?
<_habnabit>
(just run the same command again?)
<thelema>
that should work.
<thelema>
let me know if there's a problem, I'll be happy to fix it
<_habnabit>
ah, it says 'already installed; use --force to reinstall
<_habnabit>
'
<thelema>
ok, try that.
<thelema>
It should detect versions and reinstall if the available version is newer
<_habnabit>
hmm, it fetched 1.4.0 again.
<thelema>
ah, my fault, I need to put the testing repo to use 1.4.1
<thelema>
try again
<_habnabit>
ah, that did it. it's compiling now.
<thelema>
yay
<_habnabit>
okay, so let's see if this fixes my unit tests.
<_habnabit>
it does! awesome.
<thelema>
thank you for your patience.
<_habnabit>
yeah, no problem. that was still some incredibly quick response time compared to some projects.
<thelema>
I get in trouble from time to time for being so loose with releases, but I think it works out in the end.
<_habnabit>
but yeah, thank /you/ for being so quick with this.
<_habnabit>
great; my greater batteries-ifying patch succeeds now as well.
avsm has quit [Quit: Leaving.]
ikaros has joined #ocaml
<hcarty>
flux: I thought it did install the .mli - could you send me an email or post a bug about that?
<flux>
hcarty, what's your email?
<hcarty>
flux: hez 0ok org
delamarche has joined #ocaml
<flux>
hcarty, you've got it!
drake01 has quit [Quit: Ex-Chat]
drake01 has joined #ocaml
<hcarty>
flux: Thanks! I'll look into that and make the change.
<hcarty>
thelema: 1.4.1 fixes the Set bug and the 3.12.1 incompatibility?
<hcarty>
flux: Feedback on the bindings are more than welcome. They were primarily developed somewhat on an as-needed basis - I tried to be consistent, but it may not be overall.
<thelema>
hcarty: not 3.12.1 yet, I still need to work on that.
<thelema>
I need to install 3.12.1 on my computer first..
<thelema>
hcarty: that would have been a good thing to get in 1.4.1
<malouin>
huh, it seems like caml.inria.fr is having some issues.
<thelema>
malouin: yes, odd to get active-dvi as the home page
<flux>
rather worrisome that there are so few copies aroudn..
<thelema>
maybe I should try 3.13.0+dev6 (2011-07-29)
<thelema>
flux: thanks for the link
<gildor>
thelema: I have made mirror quite a long time ago and never find time to automate the httrack doing it
<thelema>
gildor: there seems little point in having it if it's not up to date.
<gildor>
thelema: that was a test and my time is limited
<thelema>
agreed, there's better things for you to do.
<gildor>
thelema: the test was about, is it possible to make it
<thelema>
hcarty: what's the problem with 3.12.1 again? I thought it was this hashtbl problem, but that looks like it'll be in 3.13, not 3.12.1
drake01 has quit [Ping timeout: 240 seconds]
<thelema>
hcarty: or was the -link thing on ocamlbuild the fix for the 3.12.1 problem?
<thelema>
hcarty: if so, it is included in 1.4.1
_andre has quit [Quit: leaving]
<flux>
meh, Camlp4MacroParser would be nice with PGO'Caml, but it doesn't do string concatenation
<flux>
also I cannot make it work but it's useless as well, so not worth the trouble :)
Snark has quit [Ping timeout: 255 seconds]
<jonafan>
asdf
StepanKuzmin has quit [Remote host closed the connection]
Reaganomicon has joined #ocaml
<jonafan>
hah, nice nick
avsm has joined #ocaml
<hcarty>
thelema: I think it was an ocamlbuild issue
<thelema>
hcarty: it seems fixed - I upgraded to 3.12.1 with no batteries build problems with batteries 1.4.1
<hcarty>
thelema: Something about .cm? files causing ocamlbuild to fail
<hcarty>
thelema: Cool, I'll give it a try here
<thelema>
Thanks for working with GODI on this.
<hcarty>
I think that's someone else. Michael Ekstrand maybe.
<hcarty>
I'm just testing :-)
<thelema>
oops, I got you mixed up. thanks for testing too.
<_habnabit>
is there an easy way with batteries to either 1) reverse-sort a list or 2) invert the result of compare? previously I was doing (compose (compose (~-)) compare)
<_habnabit>
compare |- (-|) (~-) looks a little funny.
<thelema>
(fun x y -> ~- (compare x y))
<_habnabit>
well I guess so.
<thelema>
for compare, (flip compare) works to invert the comparison
<_habnabit>
oh, haha. that makes sense too.
<hcarty>
thelema: In the future - GODI has a number of mirrors which have source packages available for OCaml and the libraries in GODI.
<thelema>
hcarty: I tried to find the source package for ocaml in godi and failed to discover it among the gazillion packages
<thelema>
maybe I should have searched for 3.12.1
Anarchos has joined #ocaml
elehack has joined #ocaml
edwin has quit [Remote host closed the connection]
delamarche has quit [Quit: delamarche]
<hcarty>
thelema: React is available via odb now if you get a chance to test and confirm
<hcarty>
thelema: I'll try uploading utop and its dependencies
* thelema
tests
<dsheets1>
is it possible to define recursive polymorphic variants?
<dsheets1>
I get "the type constructor 'foo' is not yet completely defined"
<thelema>
dsheets1: as in type foo = [`A of foo]?
<dsheets1>
type foo = [ `a of bar ] and bar = [ `b of foo ]
<thelema>
hcarty: react installed trivially via odb - I hope utop goes as easily
<hcarty>
thelema: Step 1 was trivial (zed). Now on to the others...
<hcarty>
thelema: Don't test until utop goes up of course :-)
<hcarty>
To ensure everything cascades along properly
<dsheets1>
thelema: or type foo = [ `foo of baz ] and bar = [ `bar of baz ] and baz = [ foo | bar ]
<thelema>
hcarty: no reason to suspect it won't cascade, but ok.
<thelema>
dsheets1: why are you defining polymorphic variant types - just use them
<hcarty>
thelema: Fair point... if it works with Batteries and oasis there is no reason it wouldn't here...
<hcarty>
thelema: In that case, test early, test often!