<companion_cube>
but I thought ocaml had no subtyping?
<flux>
it does, in objects and polymorphic variants
<companion_cube>
oh, ok
<companion_cube>
so it only makes sense when 'a is an object or a variant
<companion_cube>
thanks
tane has joined #ocaml
milosn has joined #ocaml
Cyanure has quit [Remote host closed the connection]
BiDOrD_ has joined #ocaml
milosn_ has quit [Ping timeout: 252 seconds]
BiDOrD has quit [Ping timeout: 256 seconds]
Yoric has quit [Ping timeout: 252 seconds]
emmanuelux has quit [Read error: No route to host]
avsm has joined #ocaml
paolooo has joined #ocaml
emmanuelux has joined #ocaml
<hcarty>
diml: Are you aware of any potential pitfalls when mixing Lwt and Bigarrays mapped to files?
<diml>
hcarty: access to a mapped bigarray will be blocking
<diml>
hcarty: you can use Lwt_bytes.wait_mincore to wait for data to be fetched to the cache
ftrvxmtrx has quit [Quit: Leaving]
tane has quit [Quit: Verlassend]
<hcarty>
diml: Thank you, I'll take a look
<diml>
also note that using preemptive threads won't help, Bigarray.*.get functions do not release the masterlock so a blocking bigarray will always block all ocaml threads
smondet has joined #ocaml
<hcarty>
diml: I thought that might be the case. Could I use separate processes and pass around file descriptors between them?
<hcarty>
That isn't ideal, but it may be my only option.
<hcarty>
The goal is to be able to have a large number of files mapped and ready for random access.
<hcarty>
I need to do some tests to find out how long each step takes (creating the file descriptor; mapping the file as a bigarray; reading a value from the bigarray)
<fasta_>
hcarty: having a number of different processes with some parallel concurrent tree for the mapping should work fine.
<fasta_>
hcarty: e.g. you could steal the PostgreSQL tree implementation.
<fasta_>
It's BSD.
ccasin has joined #ocaml
<gnuvince>
mfp: is your site, eigenclass.org, still up?
Yoric has joined #ocaml
emmanuelux has quit [Ping timeout: 260 seconds]
<fasta_>
hcarty: for ocamlbrew, can you add some logic which tests whether a partial build has already been done?
<fasta_>
hcarty: because if that is the case, OCaml builds will always fail.
<fasta_>
hcarty: one can also argue that this is an OCaml upstream problem.
avsm has quit [Quit: Leaving.]
iratsu has quit [Ping timeout: 244 seconds]
metadave has joined #ocaml
eni has joined #ocaml
eikke has quit [Ping timeout: 240 seconds]
Yoric has quit [Ping timeout: 248 seconds]
Yoric has joined #ocaml
avsm has joined #ocaml
emmanuelux has joined #ocaml
tane has joined #ocaml
<fasta_>
hcarty: ocamlbrew dies with Exception: Failure "_oasis file not found in package, cannot bootstrap." for 3.12, btw.
<fasta_>
hcarty: I think it happens during Installing camomile.
iratsu has joined #ocaml
avsm has quit [Quit: Leaving.]
mika1 has quit [Quit: Leaving.]
emmanuelux has quit [Ping timeout: 268 seconds]
cago has quit [Ping timeout: 272 seconds]
Yoric has quit [Ping timeout: 240 seconds]
Yoric has joined #ocaml
paolooo has quit [Quit: Page closed]
paolooo has joined #ocaml
avsm has joined #ocaml
<thelema>
fasta_: that's an odb error; what's the build error before that?
<thelema>
the problem seems like it's not passing --prefix to the configure script
<thelema>
ocamlfind remove camomile
<fasta_>
thelema: if I use --force, then I got the previous message.
<fasta_>
thelema: odb clears the screen all the time.
<fasta_>
thelema: instead of just outputting everything in an append way.
<thelema>
clears the screen? afaik, I have no screen clearing code in odb
<thelema>
I don't see any screen clearing on my side
<thelema>
it may scroll quickly
<fasta_>
thelema: gnome-terminal does this.
<fasta_>
thelema: I don't have this with any other software.
<thelema>
I use gnome terminal as well.
<fasta_>
thelema: what terminal should work?
<thelema>
I'm using gnome terminal 3.4.1.1
<fasta_>
Me too.
<thelema>
without problem
<fasta_>
thelema: I see the difference.
<fasta_>
thelema: ocaml odb.ml != ./odb.ml
<thelema>
maybe something is wierd about my system; it's not a clean install of ubuntu 12.04, but the result of repeated upgrades since... 2009
<thelema>
ah, really?
<fasta_>
thelema: Ok, I got it now.
<fasta_>
thelema: it was an alias for rlwrap./
<thelema>
oops.
<thelema>
I've made a symlink ~/bin/odb to my odb.ml, so I just run odb as a command
<thelema>
maybe I should rename it from odb.ml...
<fasta_>
thelema: I had one too.
<fasta_>
thelema: but now it uninstalls and installs OK.
<fasta_>
thelema: would you say this also means that it works from ocamlbrew?
<hcarty>
fasta_: If you do have trouble with ocamlbrew please let me know. I don't have a lot of time to spend on it but I try to fix bugs when they come up.
<thelema>
excellent. Did we ever figure out the root cause of your problems?
<fasta_>
thelema: no
<thelema>
fasta_: :( well, if we can't reproduce them anymore, there's not much I can do.
<fasta_>
thelema: I haven't verified that it works now. I expect it still doesn't work.
<thelema>
fasta_: ok, I can work on this a bit more.
<fasta_>
thelema: do I need to run ocamlbrew -s version/*3.12 in a particular environment?
<thelema>
hcarty: maybe ocamlbrew should unalias 'ocaml' before running 'ocaml odb.ml'
<fasta_>
thelema: like all computing, it's just a matter of asserting conditions.
<thelema>
fasta_: it wouldn't hurt to unalias 'ocaml'
<thelema>
fasta_: there shouldn't be a particular environment that it fails in, although we did just find one thing that causes very odd behavior (rlwrap)
<hcarty>
thelema: Do you know if that unaliasing will carry over outside of ocamlbrew's execution?
<thelema>
hcarty: reading...
<fasta_>
type ocaml now points to => ocaml-4.0.0
<fasta_>
So, trying it again.
<thelema>
hcarty: n/m; Aliases are not expanded when the shell is not interactive, unless the
<thelema>
expand_aliases shell option is set
<fasta_>
hcarty: it's also a problem that it cannot continue a build.
<hcarty>
fasta_: I agree
<fasta_>
I have to do rm -rf <everything> to make it work.
<hcarty>
fasta_: Patches are welcome :-) Or a bug report.
<fasta_>
hcarty: why doesn't this count as a bug report?
<fasta_>
hcarty: it's clear what the problem is, no?
<hcarty>
fasta_: Because I will forget
<hcarty>
fasta_: I don't memorize my conversations with you
<fasta_>
hcarty: so, copy paste the above in a file called BUGS.
<fasta_>
hcarty: forgive me, but I get associations of French government workers.
<hcarty>
fasta_: ???
<hcarty>
fasta_: I don't know what that means.
<fasta_>
hcarty: bureaucracy
<fasta_>
It's not like the problem isn't clear.
<fasta_>
As such, it's just bureaucracy.
<hcarty>
fasta_: If I were spending my workday maintaining ocamlbrew, perhaps.
<hcarty>
fasta_: When it's something I do in my spare time, not as much.
pangoafk is now known as pango
<thelema>
fasta_, hcarty: if either of you were less lazy, that person would spend 30 seconds typing "continue an incomplete build" into the issues for ocamlbrew on github
<thelema>
as is, you're both just trying to get the other to do this trivial amount of work
<fasta_>
thelema: I don't even have an account.
<hcarty>
thelema: Indeed. I could spend my time here or there.
<thelema>
fasta_: you should get one so you can report issues properly
<thelema>
hcarty: I admit I'm less inclined to go out of my way for pushy, self-righteous people like fasta, but fwiw, he seems to have calmed down today.
<hcarty>
thelema: A fair point. And I shouldn't feed the trolls. Bug reporting now...
<fasta_>
thelema: there are still 3 open issues.
<fasta_>
thelema: also one of them has been open for 6 months, which seems to suggest nobody maintains this.
<thelema>
fasta_: your self-righteous meter is starting to spike
<hcarty>
fasta_: All of the open bugs are more in the feature request category. They are perhaps nice to have but do not affect (my?) use of ocamlbrew.
Yoric has quit [Ping timeout: 265 seconds]
<fasta_>
thelema: the previous problem is still there.
<thelema>
fasta_: the makefile:38 one?
<fasta_>
thelema: yes
<fasta_>
thelema: it seems to use the wrong odb.
<thelema>
do you have multiple odb somehow?
<fasta_>
thelema: it downloads everything to the ocaml-4.00.0 version.
<fasta_>
thelema: that's pretty much the point of ocamlbrew, no?
<thelema>
fasta_: not really; multiple odb isn't the point, multiple ocaml and findlib is
<fasta_>
thelema: so, basically ocamlbrew -a for two different versions is not supported?
<hcarty>
fasta_: I'm trying it here
<thelema>
it should be; I've done it twice now.
<thelema>
on two different ubuntu machines
<fasta_>
I think all of the 'checking for <whatever> tool .... whatever could also be improved.
<fasta_>
It should point to absolute paths.
<fasta_>
This is ambiguous.
<fasta_>
You get rid of failures and debugging problems when there is no room for error.
<thelema>
fasta_: if it's important to you, you should make it sufficiently easy so that `(benefit_of_patch - added_complexity) > work_to_apply` for hcarty
<hcarty>
Or for gildor since it sounds like fasta_ is talking about oasis's output.
<thelema>
hcarty: ah, true.
<thelema>
I'll admit I didn't use -a on my ocamlbrew installs, just answered 'y' to everything
<hcarty>
FWIW, "./ocamlbrew -a" is working properly for me while under an brew'd 4.00.0 environment.
<fasta_>
hcarty: for version/3.12?
<hcarty>
thelema: They should be the same...
<hcarty>
fasta_: Yes
emmanuelux has joined #ocaml
<hcarty>
fasta_: It's currently going through utop's build and installation... and just failed.
<thelema>
hcarty: that's what I would expect too.
<hcarty>
Same error. Interesting.
<thelema>
hcarty: makefile:38 for you too?
<hcarty>
thelema: Yes
<thelema>
!!
<fasta_>
!!!!
<thelema>
maybe add --debug to ocamlbrew's invocation of odb?
<fasta_>
Where can I even find the Makefile?
<hcarty>
Starting over with --debug. Man, it would be nice if ocamlbrew supported picking an installation back up part way through :-)
<fasta_>
hcarty: so, AFAIK, the issue is that it uses the wrong version.
<hcarty>
But it looks like the build directory isn't set correctly
<hcarty>
The prefix is set properly but the build directory is not
<hcarty>
Ah
<hcarty>
: ${ODB_BUILD_DIR="$BUILD_DIR"/odb}
<fasta_>
/3.12/lib/ocaml
<fasta_>
That is line 38 now
<fasta_>
The one below 4.00
<hcarty>
So if ODB_BUILD_DIR is set it won't set it to something else.
<fasta_>
Which indeed is completely wrong.
<hcarty>
("it" being ocamlbrew in this case)
<hcarty>
I'm not sure how to address that without significant additions to ocamlbrew. Additions that I would like to make, but haven't yet.
<hcarty>
Until those changes are made I should put something in the README and runtime notice/documentation saying that you should not try to do a fresh ocamlbrew from within an existing ocamlbrew environment.
<fasta_>
hcarty: what does work then?
<fasta_>
hcarty: using the system ocaml?
<hcarty>
fasta_: ocamlbrew doesn't need an existing OCaml installation
<thelema>
fasta_: not loading the other ocamlbrew environment
<fasta_>
thelema: I don't think that's enough.
<hcarty>
fasta_: Clearing the environment of ocamlbrew and odb environment variables is the way to go here.
<fasta_>
hcarty: the right way to solve this would be to have ocamlbrew refuse to do any work, until its environment is properly defined.
<hcarty>
fasta_: I'm testing "./ocamlbrew -a -s version/3.12" now in a clean environment.
<hcarty>
fasta_: It is properly defined.
<hcarty>
fasta_: As far as I know at this point at least. It's perfectly acceptable to point ODB_BUILD_DIR to another location.
<fasta_>
hcarty: I am not even using ODB_BUILD_DIR myself.
<hcarty>
fasta_: It's set by ocamlbrew's bashrc file.
<thelema>
yes, it should be fine to have ODB_BUILD_DIR set to wherever you want.
<fasta_>
Leaky abstractions
<hcarty>
So the issue could be another environment variable that is causing a conflict or some change in version/3.12 that is causing trouble. Or something else.
<fasta_>
unset ODB_BUILD_DIR
<fasta_>
Why don't you just add that line?
<hcarty>
fasta_: Because someone may want to change that location.
<fasta_>
hcarty: unlikely, because you already have a top-level directory for that.
<hcarty>
But it looks like that was a red herring.
<fasta_>
hcarty: the *BASE* directory.
<hcarty>
The same issue comes up with a clean build in a clean environment.
<fasta_>
hcarty: otherwise just go to the user specified dir and check whether it is empty.
<fasta_>
hcarty: if not scream very loudly.
<hcarty>
fasta_: One may wish to separate the build directory from the base directory. Particularly odb's build base since it would generally be used after the ocamlbrew process.
<fasta_>
hcarty: if it is, scream loudly how to get rid of it, but continue.
<fasta_>
hcarty: in all cases, this is not rocket science.
<fasta_>
hcarty: I am not sure to who I am talking here, but this is really, really basic stuff.
<hcarty>
Well, ocamlbrew DOES have rocketry in its core. That was intended to be a secret.
<fasta_>
It's somewhat fair to say 'patches welcome'.
<fasta_>
But saying 'I don't know how to solve this' seems rather weird.
<hcarty>
fasta_: I have. But to repeat myself: "patches are welcome"
<hcarty>
fasta_: I was stating that I don't know how to address the ODB_BUILD_DIR issue.
<fasta_>
hcarty: I think I already told you a solution for that.
<hcarty>
fasta_: I don't see a perfect answer, or even a better answer than the one that exists.
tww has joined #ocaml
<fasta_>
hcarty: do you want people reusing such directories?
<hcarty>
fasta_: That's up to them. It shouldn't cause an issue.