<ssbr_>
I take it B&D means "bondage and discipline"?
<thelema>
yes
<thelema>
I put up with having to convert from float to int in ocaml because I don't have to specify a million other things
<thelema>
but try mixing fixed-length and variable-length strings in Ada... very painful.
<d3z>
To_Unbounded_String (Text) ...
cyphase has quit [Ping timeout: 272 seconds]
cyphase has joined #ocaml
<ssbr_>
It weirds me out that for a type, say, A (x,y) | B , I can match against A _, but not A x
ulfdoz_ has joined #ocaml
ulfdoz has quit [Ping timeout: 272 seconds]
ulfdoz_ is now known as ulfdoz
lamawithonel has quit []
cdh473 has quit [Ping timeout: 248 seconds]
cdidd has joined #ocaml
gnuvince has joined #ocaml
tmaedaZ has quit [Ping timeout: 245 seconds]
tmaedaZ has joined #ocaml
cdidd has quit [Remote host closed the connection]
ulfdoz has quit [Ping timeout: 244 seconds]
ulfdoz has joined #ocaml
cdidd has joined #ocaml
ulfdoz has quit [Ping timeout: 260 seconds]
ulfdoz has joined #ocaml
milosn_ has joined #ocaml
oriba has quit [Quit: oriba]
milosn has quit [Ping timeout: 244 seconds]
ulfdoz has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
tomprince has quit [Quit: WeeChat 0.3.6]
tomprince has joined #ocaml
cyphase has quit [Ping timeout: 244 seconds]
ulfdoz has quit [Ping timeout: 255 seconds]
cyphase has joined #ocaml
emmanuelux has quit [Ping timeout: 264 seconds]
<thelema>
ssbr_: there's a difference between `type x = A of int*int` and `type y = A of (int*int)`
<thelema>
ssbr_: only the second can be pattern matched by `A x`, because the first has the tuple inlined, whereas the second has an actual tuple to point to.
struktured has joined #ocaml
struktured has quit [Ping timeout: 255 seconds]
struktured has joined #ocaml
ankit9 has joined #ocaml
ankit9 has quit [Quit: Leaving]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
noj has quit [Ping timeout: 245 seconds]
pango is now known as pangoafk
snearch has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
milosn_ has quit [Read error: Operation timed out]
gnuvince has quit [Ping timeout: 250 seconds]
thomasga has joined #ocaml
Snark has joined #ocaml
ulfdoz has joined #ocaml
ulfdoz has quit [Ping timeout: 244 seconds]
Tobu_ has joined #ocaml
Tobu has quit [Ping timeout: 248 seconds]
milosn has joined #ocaml
ulfdoz has joined #ocaml
ulfdoz has quit [Ping timeout: 265 seconds]
noj has joined #ocaml
Tobu_ has quit [Ping timeout: 248 seconds]
ulfdoz has joined #ocaml
avsm has joined #ocaml
Yoric has joined #ocaml
ftrvxmtrx has joined #ocaml
Sanders_NL has joined #ocaml
snearch has quit [Quit: Verlassend]
<rixed>
Seams like lists.forge.ocamlcore.org is broken for me. Just got: <batteries@smtp.ocamlcore.org> (expanded from <batteries@lists.forge.ocamlcore.org>): unknown user: "batteries"
GPHemsley has quit [Read error: Operation timed out]
<rixed>
was working allright some hours ago.
GPHemsley has joined #ocaml
GPHemsley has quit [Changing host]
GPHemsley has joined #ocaml
thomasga has quit [Quit: Leaving.]
Cyanure has joined #ocaml
clog has quit [Ping timeout: 256 seconds]
clog has joined #ocaml
Hussaind has joined #ocaml
Hussaind has left #ocaml []
ankit9 has joined #ocaml
Kakadu has joined #ocaml
zzz_` has quit [Ping timeout: 265 seconds]
zzz_ has joined #ocaml
thomasga has joined #ocaml
lorilan has joined #ocaml
Cyanure has quit [Ping timeout: 244 seconds]
Cyanure has joined #ocaml
Yoric has quit [Ping timeout: 260 seconds]
emmanuelux has joined #ocaml
eni has joined #ocaml
_andre has joined #ocaml
ankit9 has quit [Ping timeout: 252 seconds]
emmanuelux has quit [Read error: Connection reset by peer]
mal`` has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
emmanuelux has joined #ocaml
mal`` has joined #ocaml
ankit9 has joined #ocaml
ankit9 has quit [Ping timeout: 250 seconds]
eni has quit [Ping timeout: 245 seconds]
ankit9 has joined #ocaml
snearch has joined #ocaml
Yoric has joined #ocaml
BiDOrD_ has joined #ocaml
BiDOrD has quit [Ping timeout: 245 seconds]
eni has joined #ocaml
mal`` has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
mal`` has joined #ocaml
<hcarty>
gildor_: Is it possible to remove/completely disable a package in the upcoming version of oasis-db?
<hcarty>
gildor_: For example, there are multiple zip and uint packages on oasis-db right now.
munga has quit [Ping timeout: 252 seconds]
ankit9 has quit [Ping timeout: 245 seconds]
r126f has quit [Remote host closed the connection]
lorilan has quit [Remote host closed the connection]
ftrvxmtrx has quit [Quit: Leaving]
<thelema>
hcarty: gildor can do it manually; this makes a good feature request
struktured has quit [Remote host closed the connection]
cdh473 has joined #ocaml
<hcarty>
thelema: Submitted
<hcarty>
thelema: Something broke oasis-2.1~alpha1's build in oasis-db
gnuvince has joined #ocaml
<thelema>
yes, I noticed that post... is it broken for you too?
<hcarty>
thelema: I just tried a fresh ocamlbrew install and I got the same error
<thelema>
ok then, I guess we're upgrading to 3.x
<thelema>
IIRC, oasis-db now supports 3.x
<thelema>
err, 0.3.x
<hcarty>
thelema: If it does then I'm all for upgrading
ankit9 has joined #ocaml
<thelema>
[OASIS-devel] oasis-db: Upgrade to sqlexpr 0.4.1 and oasis 0.3.0~rc5
<thelema>
may 3rd
<hcarty>
thelema: Has that been pushed to the live site?
<thelema>
hmm, not sure.
<thelema>
I guess one way to test would be to upload something with a 0.3 setup
<hcarty>
The latest oasis rc is a good candidate
<thelema>
wait, doesn't the new oasis have a setup created by it?
<hcarty>
I can give it a try
<thelema>
yes, that's what I was thinking...
<thelema>
please do
<hcarty>
Error in completion 'oasis' on 'oasis-0.3.0~rc5.tar.gz': OASIS format version '0.3' is not supported.
<hcarty>
Drat.
<thelema>
bleh.
<thelema>
ok, I'll look at the error again and see if I can guess what accidentally got upgraded to stable
<hcarty>
I can pastebin the error if that would help
<thelema>
no, easy enough to get from my email client
<thelema>
not particularly useful at identifying the problem library
<hcarty>
I tried flipping some package versions around but the permutations I tried didn't help.
Reventlov has joined #ocaml
<thelema>
hmm...
ankit9 has quit [Ping timeout: 260 seconds]
<Reventlov>
hm.
mathieui has joined #ocaml
<thelema>
tar (child): ounit-1.1.1.tar.gz: Cannot open: No such file or directory
<thelema>
odd...
<hcarty>
thelema: Very
<thelema>
huh, working now.
<thelema>
well, at least the download worked... the install... tried to go into /usr/local/lib
<thelema>
hmm, then how is ocamlfind using the right dir for you...
<hcarty>
Except that it's /home/hcarty/ocamlbrew/ocaml-3.12.1/bin/ocamlfind
<hcarty>
Ah
<thelema>
ah, which has its own findlib.conf wit the right dir
<hcarty>
Maybe that's only by accident
<hcarty>
Yep
<thelema>
a bug in oasis?
<hcarty>
It was working before though, wasn't it?
<thelema>
maybe the last time I checked it was before I put in the OCAML_BASE change
<hcarty>
I see the same issue here. If I unset OCAML_BASE then oUnit still installs to site-lib
<thelema>
that's what I expected.
<thelema>
well, I'll just set the environment variable.
<thelema>
well, setting OCAMLFIND_DESTDIR fixes the oasis destination, although I'll have to bother gildor about this seeming flaw sometime.
<thelema>
ok, oasis now trying to install, finally back on track to fix original bug
<thelema>
error from list reproduced
oriba has joined #ocaml
munga has quit [*.net *.split]
cdh473 has quit [*.net *.split]
GPHemsley has quit [*.net *.split]
bacam has quit [*.net *.split]
fooc has quit [*.net *.split]
bobry has quit [*.net *.split]
munga has joined #ocaml
cdh473 has joined #ocaml
GPHemsley has joined #ocaml
bacam has joined #ocaml
fooc has joined #ocaml
bobry has joined #ocaml
notk0 has joined #ocaml
<notk0>
hello, I have 2 types that have the same field foo, how can I access the field because the compiler can't make the difference and tells me it expects another type
<flux>
basically, you cannot, because it shadows it. in other words, don't do it :)
<notk0>
hm
<notk0>
so I am screwed?
<thelema>
flux: ?
<flux>
well, you can modfiy code
<flux>
notk0, what kind of screwedness are you talking about?
<flux>
code is there to be changed ;)
<flux>
notk0, you can put the records into their own submodules if you really want to use the same field name
<flux>
module Foo = struct type t = {foo : int} module Bar = struct type t = {foo:float} end
<flux>
then you can refer to x.Foo.foo, or Foo.(x.foo), or let open Foo in x.foo
<flux>
thelema, ?
<thelema>
flux: I must have missed notk's qtestion
<flux>
thelema, to much qtest-hacking?-)
ankit9 has joined #ocaml
<thelema>
flux: heh. actually, odb hacking today.
<thelema>
and giving up on oasis 2.1
<flux>
if I have many records in a module I might name the record fields so that they have a certain prefix, such as c_foo, conn_foo, dpy_foo etc
<flux>
thelema, what's the main obstacle in oasis 2.1?
<thelema>
err, 0.2.1. Somehow it has decided to stop compiling properly under odb.
<flux>
scary, has mind of its own
<notk0>
flux, the problem is one type contains the other
<notk0>
I have
<notk0>
x.id and x.from.id
<thelema>
The best guess of what changed is that some dep was updated, but since there's no log of the changes, and random tweaking hasn't helped, I'm going to give up and let 0.3 beta be the stable version
<thelema>
and prod gildor to make oackages created with 0.3 work in oasis-db
<thelema>
*packages
<flux>
notk0, tyep t = { id : int } type t2 = { id : int; sub : t } <- this cannot work in practice
<flux>
it is impossible to refer to (x : t).id
<notk0>
flux, one type references to another
<notk0>
the definition of a type contains another type from another module
<notk0>
in it's definition
<flux>
notk0, ah, another module
<notk0>
and in a file I open both modules else it doesn't know the type
<flux>
notk0, then you use the syntax: foo.ModuleName.bar
<notk0>
hm
<notk0>
I don't have to open a module to access the fields of a type?
<flux>
correct
<flux>
or if you have opened, that syntax still works
<notk0>
so if type t is in module M
<notk0>
t.M.field ?
<flux>
correct
<notk0>
strange notation
<notk0>
ok I will try that, thank you flux
<flux>
it is a bit strange, perhaps, but it's what we have ;)
<notk0>
and by t I mean a variable
<flux>
good luck
<notk0>
?
<flux>
yes
<notk0>
very strange notation indeed
<notk0>
thank you flux let me try that
<flux>
notk0, if you find that you need to refer to those variables a lot, you could make a module alias: let module LN = LongName
<flux>
oops, without 'let'
<flux>
long chains of such things can become quite annoying in ocaml: foo.Foo.t.Bar.t.Baz.t .. but I have seen that only perhaps once in practice.
<flux>
but the upside is that at least you'll always know where to find the code and type definitions from :)
<notk0>
flux, that seemed to work, even tho it seems strange, thank you
<notk0>
I have x.Module1.field.Module2.field
<mrvn>
Foo.(Bar.(Baz.(foo.t.t.t)))) can be usefull
<thelema>
mrvn: I don't think that first wrapping works.
<mrvn>
thelema: not with t.t.t
Kakadu has joined #ocaml
<flux>
mrvn, hmm, I don't think that works? a field name is missing
<notk0>
mrvn the Module2 is independent tho
<mrvn>
flux: Module.(...) is a local open Module
<notk0>
oh
<mrvn>
notk0: ah, then Module2 alone will work.
<flux>
mrvn, I meant your "x.Module1.field.Module1.Module2.field"
<thelema>
flux: module2 could be a submodule of module1
<notk0>
mrvn, I understand now if it's a local open Module
<mrvn>
notk0: with submodules it can be realy anoying because for each component you get a longer and longer module path.
<flux>
thelema, ah, I didn't consider that
<mrvn>
x.M.t.M.Sub.t.M.Sub.Subsub.t
<mrvn>
quite anyoing that ocaml doesn't infer the submodules from the x.M.t
<thelema>
mrvn: how could it?
<mrvn>
thelema: x.M.t pins down the type for x.M.t, there is no wriggle room what the sub records could be.
<thelema>
mrvn: type 'a r = {r : 'a}
<thelema>
but I agree that when the type is knowable from just the record definition, it would be nice to be able to omit module names
<mrvn>
thelema: then x.M.r is 'a and you are screwed. I'm thinking of type x = { t : Sub.t }
milosn has quit [Ping timeout: 256 seconds]
smerz has joined #ocaml
<thelema>
this tries to generalize to a rule that when the type is known, module-paths for fieldnames aren't needed
<thelema>
I have a feeling there's a problem with this, in that types are only known at the end of type inference
<mrvn>
thelema: you mean that x.y.z needs to know the type of z first?
<thelema>
the type of z may have to merge with the type of x
<thelema>
"merge" isn't the right word
<thelema>
unify
<mrvn>
since we are talking about records why do i have to specify the type of labels anyway? Why not type t = { x; y; } and let it infere that they are int?
<thelema>
then you have labeled tuples
<thelema>
there's some evil polymorphism tricks that can only be done with records
<thelema>
but maybe we can lose those.
<mrvn>
no, but maybe extend them to general types
<mrvn>
or replace them with GADTs
<thelema>
if we don't have global information about what type t.x is, then we may infer different types in different parts of the program, and we no longer have a single type t
<mrvn>
thelema: so? that would give a type error
<thelema>
what you're asking for is like: type t = ( , )
<mrvn>
thelema: and you would have to specify the type in the .mli file. The problem can't escape the module.
<mrvn>
thelema: like let foo = ([], []) and it figures out they are int lists.
<thelema>
that's a value, though.
<mrvn>
well, let r = { x = 1; y = 1; } without first declaring the type seems risky.
<thelema>
I don't see any benefit in type t={x;y} -- all you've given is an order to field names
<thelema>
I'd rather have type t = X | Y, and then be able to have an array indexed by T.
<mrvn>
which is enough to compile if t.x = 1 ... and the like.
<thelema>
or maybe a tuple indexed by a variant type
<thelema>
this would give you what you want
<thelema>
although array seems more useful - int array't
<mrvn>
elements might not all have the same type.
<thelema>
mrvn: yes, but what would the type look like? I guess it could look like a record with (): (X:int, y:char)
<thelema>
err, s/,/*/
<thelema>
(X:int * Y:char)
ankit9 has quit [Quit: Leaving]
<thelema>
although maybe (int * char)@t would be better
<thelema>
int array@t
<thelema>
indicating the indexing type
<mrvn>
thelema: use record syntax
<mrvn>
tupels with index have to specify labels.
<mrvn>
type t = A { x: int; y: int; } | B of string ...
<pippijn>
that works?
<mrvn>
no, just a suggestion
<thelema>
pippijn: no, just talking wishes
<pippijn>
right..
<pippijn>
I tried this before
<pippijn>
in SML it works, I think
<mrvn>
which would be different from type r = { x: int; y: int; } type t = A of r. No extra indirection in the first case.
<hcarty>
There is a feature being proposed on mantis which supports type t = A { x: int; y: int }
<mrvn>
I hope that gets solved soon
avsm has joined #ocaml
<pippijn>
where solved = accepted
<mrvn>
= merged into 4.0 :)
<thelema>
= implemented, tested, etc
notk0 has quit [Quit: bye bye]
avsm has quit [Quit: Leaving.]
<thelema>
wow, core does take quite a while to compile
eni has quit [Quit: Leaving]
cyphase has quit [Ping timeout: 244 seconds]
milosn has joined #ocaml
cyphase has joined #ocaml
Yoric has quit [Ping timeout: 265 seconds]
pangoafk is now known as pango
munga has quit [Ping timeout: 240 seconds]
wmeyer has joined #ocaml
<wmeyer>
hi
cdidd has quit [Remote host closed the connection]
fraggle_ has quit [Ping timeout: 250 seconds]
fraggle_ has joined #ocaml
fraggle_ has quit [Max SendQ exceeded]
fraggle_ has joined #ocaml
thomasga has quit [Quit: Leaving.]
<hcarty>
thelema: Checking out the competition?
<hcarty>
wmeyer: Hello
<wmeyer>
hcarty: Hey
Anonyme44893 has joined #ocaml
Anonyme44893 has quit [Client Quit]
Xizor has joined #ocaml
<thelema>
hcarty: no, helping them be odb-installable
<thelema>
they're favoring one-off install scripts for the whole shabang of packages
sivoais has quit [Ping timeout: 272 seconds]
<hcarty>
thelema: Are you wrapping the script to be odb-installable or breaking up the pieces so each one can be installed separately?
<thelema>
hcarty: breaking up the pieces
<thelema>
sadly, their _oasis files are complex enough that I can't just dumb-parse them to get the inter-package deps
<wmeyer>
thelema: Maybe you could use oasis for that
cdh473 has quit [Quit: Leaving]
munga has joined #ocaml
oriba has quit [Read error: Operation timed out]
oriba_ has joined #ocaml
oriba_ is now known as oriba
err404 has joined #ocaml
sivoais has joined #ocaml
<wmeyer>
thelema: in general odb could depend on oasis itself to provide a nice infrastructure to analyze _oasis files.
<thelema>
wmeyer: except odb is supposed to be able to install oasis onto a system that doesn't have it.
<thelema>
but yes, it could install oasis for the purpose of analyzing _oasis files for other projects
Yoric has joined #ocaml
Tobu has joined #ocaml
Yoric has quit [Ping timeout: 264 seconds]
Submarine has quit [Quit: Leaving]
Tobu has quit [Remote host closed the connection]
smerz_ has joined #ocaml
Tobu has joined #ocaml
_andre has quit [Quit: leaving]
err404 has quit [Remote host closed the connection]
Tobu_ has joined #ocaml
Tobu has quit [Ping timeout: 272 seconds]
Yoric has joined #ocaml
<wmeyer>
thelema: It would be a classical bootstrapping scheme. Perhaps, having oasis installed as a pre-requisite would be beneficial anyway.
<orbitz>
Anyone using Core on Mac here?
<wmeyer>
thelema: Of course I meant through odb not by the user - oasis has binary packages which could possibly be helpful
Snark has quit [Quit: Quitte]
<thelema>
could be useful, although it just saves a little work in the case that you have already expanded folders with source repos
<wmeyer>
thelema: I agree.
<thelema>
that and doing installs from VCS repos that don't have setup.ml checked in
<wmeyer>
thelema: but they have _oasis
<wmeyer>
thelema: In general, _oasis contains a lot of useful information for package managers like odb to reuse
<thelema>
odb needs the setup.ml to actually do the configure, build, install
<wmeyer>
thelema: possibly _oasis could have a custom command to re-generate from _oassis itself - then odb could try to spawn this command
<wmeyer>
thelema: in the simpliest case, it should be simple as "oasis setup"
gnuvince has quit [Ping timeout: 272 seconds]
<thelema>
yes, yes. At the moment this isn't automated.
<thelema>
(in odb)
<wmeyer>
thelema: I might take look at it then
<wmeyer>
I don't know about what is the exposure of oasis internals
<wmeyer>
but I think one of the design principles was to feed enough informations to package managers
<wmeyer>
thelema: and I agree that there is certain issue with developpers not sure if to commit setup.ml or not
Sanders_NL has quit [Remote host closed the connection]
<thelema>
parsing the _oasis file is nontrivial. I've been tempted to take the parser and put it in odb, as it doesn't really need a full oasis for just dependency discovery
<wmeyer>
thelema: some of the packages do it or not inclined to do it, both solutions have some advantages
<wmeyer>
yes. Oasis meant to be simple to just use regex in simplies case, but they have certain amount of complexity as of today
<thelema>
gildor did add a bunch of alternatives to the 0.2 setup creation in 0.3
<thelema>
minimal setup.ml files and something else
eni has joined #ocaml
<wmeyer>
thelema: I notice it too, it's getting more flexible which is very good
<wmeyer>
thelema: Just forked odb :)
<wmeyer>
thelema: I might flip something out - tomorrow I'm leaving my room to get some coffee in the town
<thelema>
improvements welcome.
<thelema>
just try not to increase the LoC too much and no external deps
<wmeyer>
thelema: Thanks. I know what's your goal. I'm also not inclined to turn odb to a mail client :)
<thelema>
:) great.
snearch has quit [Quit: Verlassend]
tomprince has quit [Quit: WeeChat 0.3.6]
eni has quit [Ping timeout: 252 seconds]
Kakadu has quit [Quit: Konversation terminated!]
tomprince has joined #ocaml
gnuvince has joined #ocaml
ftrvxmtrx has joined #ocaml
tomprince has quit [Client Quit]
nimred has quit [Ping timeout: 260 seconds]
Yoric has quit [Ping timeout: 245 seconds]
tomprince has joined #ocaml
munga has quit [Ping timeout: 244 seconds]
tautologico has joined #ocaml
Xizor has quit []
Cyanure has quit [Remote host closed the connection]
smondet has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]