fantasticsid has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
Tobu has quit [Read error: Operation timed out]
cdidd has joined #ocaml
EmmanuelOga has joined #ocaml
Tobu has joined #ocaml
BiDOrD_ has joined #ocaml
BiDOrD has quit [Read error: Operation timed out]
sebz has joined #ocaml
ulfdoz has quit [Ping timeout: 255 seconds]
silver_ has joined #ocaml
lamawithonel has quit [Remote host closed the connection]
lamawithonel has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
Tobu has quit [Read error: Operation timed out]
Tobu has joined #ocaml
pilki has joined #ocaml
The_third_man has quit [Ping timeout: 252 seconds]
The_third_man has joined #ocaml
edwin has joined #ocaml
<adrien>
Ralith: a recent OCaml from svn should work with your cygwin setup
<Ralith>
adrien: I'm not using cygwin.
<Ralith>
I think that's the problem.
<adrien>
you can avoid using cygwin but the gcc used to accept -mno-cygwin even when not applicable
<adrien>
it didn't change anything but it accepted the switch
The_third_bug has joined #ocaml
The_third_man has quit [Disconnected by services]
The_third_bug has quit [Ping timeout: 252 seconds]
The_third_man has joined #ocaml
ftrvxmtrx_ has joined #ocaml
<Ralith>
adrien: well, it no longer does.
edwin has quit [Ping timeout: 240 seconds]
edwin has joined #ocaml
<adrien>
yup, but people have gotten used to it; but you should be able to "simply" remove it from the command-line arguments; you're using mingw+msys?
Cyanure has joined #ocaml
sgnb has quit [Remote host closed the connection]
pilki has quit [Quit: This computer has gone to sleep]
cago has joined #ocaml
milosn has joined #ocaml
sebz has joined #ocaml
raichoo has joined #ocaml
sebz has quit [Client Quit]
Snark has joined #ocaml
sebz has joined #ocaml
Tobu has quit [Read error: Operation timed out]
Obfuscate has quit [Ping timeout: 240 seconds]
EmmanuelOga has quit [Ping timeout: 244 seconds]
sgnb has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
ttamttam has joined #ocaml
rby has quit [Quit: Lost terminal]
Cyanure has quit [Remote host closed the connection]
thomasga has joined #ocaml
<Ralith>
adrien: yes.
Tobu has joined #ocaml
Tobu has quit [Changing host]
Tobu has joined #ocaml
ankit9 has joined #ocaml
Cyanure has joined #ocaml
ocp has joined #ocaml
emmanuelux has joined #ocaml
_andre has joined #ocaml
pcjoby has joined #ocaml
avsm has quit [Quit: Leaving.]
antegallya1 has joined #ocaml
antegallya has quit [Disconnected by services]
sebz has quit [Quit: Computer has gone to sleep.]
The_third_man has quit [Disconnected by services]
The_third_bug has joined #ocaml
The_third_bug has quit [Read error: Connection reset by peer]
The_third_man has joined #ocaml
The_third_bug has joined #ocaml
The_third_man has quit [Disconnected by services]
Tobu has quit [Ping timeout: 272 seconds]
Obfuscate has joined #ocaml
<testcocoon>
I have a question concerning all forks of OCaml (jocaml, metaocaml, ...): is there a plan to get the feature of this forks integrated into ocaml?
<adrien>
plans? I don't think so
<adrien>
wishes; on the long term
<testcocoon>
I'm just guessing if generally such fork get integrated or if it stays at fork
iago has joined #ocaml
Tobu has joined #ocaml
<Qrntzz>
I'd, for one, like for jocaml primitives to get integrated into ocaml as 1) they don't change the semantics too much, remaining source-compatible with ocaml if you don't use def/spawn/etc 2) they are quite useful for multi-threading applications 3) atm, you are required to build the whole ocaml compiler suite, and then all of jocaml even though they are mostly source-compatible; but I doubt this will happen any soon, yes
<adrien>
are you forced to rebuild everything?
<Qrntzz>
the most obvious problem with jocaml is, I'd say, its incompatibility with findlib and whether as a consequence or as a cause -- its low popularity
<adrien>
ocamlbuild has a flag to use jocaml and I thought that was showing it was possible to mix jocaml and non-jocaml
<adrien>
incompatibility with findlib?
<Qrntzz>
yes
<adrien>
how?
<Qrntzz>
I'm not sure if it still persists, it did 3 months ago
<adrien>
but what is the actual issue?
<Qrntzz>
findlib and jocaml disagree over some fundamental units
<Qrntzz>
e. g. `The files /usr/lib/ocaml/findlib/findlib_top.cma and /usr/local/lib/jocaml/toploop.cmi disagree over interface Parsetree'
<Qrntzz>
that's the toplevel error, but compilation attempts gave me one as well
<adrien>
ah, ok
<adrien>
that doesn't sound like unfixable however
<Qrntzz>
well, I'm certainly not competent enough yet to try messing with the internals of jocaml :-)
ikaros has joined #ocaml
<adrien>
I was thinking it could be changed in findlibc
<Qrntzz>
I have little idea of what actually is the conflict, so perhaps
<Qrntzz>
and yes, I rebuilt everything from scratch to get the jocaml suite
antegallya1 has quit [Quit: Leaving.]
antegallya has joined #ocaml
<testcocoon>
I must confess that I don't have any experience with jocaml, but after reading the doc, I found that the extension makes parallel programming easier to program and also easier to read.
<Qrntzz>
testcocoon: true. note though that using jocaml alone won't parallelise your code as I have thought first too
<Qrntzz>
but it makes fork-based parallelism much more convenient with distributive features it has
<testcocoon>
That's clear. but you know that most of the code for parallelism is glue code (setting semaphore, starting thread, waiting for data...) and jocaml syntax is a nice abstraction for this.
ftrvxmtrx has quit [Ping timeout: 260 seconds]
<Qrntzz>
testcocoon: that's what I mean by `convenience' :-)
<Qrntzz>
jocaml has also proven to be the first in terms of performance on the wide finder project, where parallel programming was used extensively, so the abstraction presumably doesn't hurt performance in significant amounts
<testcocoon>
I'm not sure, but due to the fact that some of the developers of jocaml are from the INRIA, I assume that jocaml could be integrated int ocaml.
cago has quit [Quit: Leaving.]
cago has joined #ocaml
<Qrntzz>
possibly, in the future.
<adrien>
I was wondering if I should make yypkg use JSON instead of S-expressions; I think I'll stay with sexplib since json is probably going to look ugly for what is actually a syntax tree
The_third_bug has quit [Read error: Connection reset by peer]
The_third_man has joined #ocaml
Ptival has quit [Read error: Connection reset by peer]
loic_ has joined #ocaml
rby has joined #ocaml
MaskRay_ has quit [Quit: leaving]
rby has quit [Client Quit]
beckerb has joined #ocaml
thomasga has quit [Quit: Leaving.]
ftrvxmtrx has joined #ocaml
oriba has joined #ocaml
MaskRay has joined #ocaml
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
<MaskRay>
Hi all, I'm a novice at OCaml, following Jason Hickey's intro and get stuck when reading Chapter 15. Given a class `a' inheriting class `b' and both of them have some side-effect actions, in what order will these actions happen?
Tobu has quit [Quit: No Ping reply in 180 seconds.]
Tobu has joined #ocaml
ocp has quit [Ping timeout: 272 seconds]
ulfdoz has quit [Quit: deprecated]
joewilliams has quit []
Tobu has quit [Ping timeout: 248 seconds]
joewilliams has joined #ocaml
Tobu has joined #ocaml
cago has quit [Quit: Leaving.]
silver_ has quit [Remote host closed the connection]
Tobu has quit [Remote host closed the connection]
Tobu has joined #ocaml
nb_ has joined #ocaml
nb_ is now known as Guest2858
Guest2858 has quit [Quit: Page closed]
ttamttam has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
fraggle_ has quit [Read error: Connection reset by peer]
thomasga has joined #ocaml
fraggle_ has joined #ocaml
Kakadu has joined #ocaml
beckerb has quit [Quit: Konversation terminated!]
ulfdoz has quit [Quit: debugging]
_andre has quit [Quit: leaving]
ulfdoz has joined #ocaml
jacktrip has joined #ocaml
idest0 has joined #ocaml
hcarty has joined #ocaml
<hcarty>
thelema: Are there known issues with Batteries 1.4.1's Set.Make-generated sets?
<hcarty>
thelema: It's difficult to follow the github bug tracker since the bugs are not generally associated with a particular version
<hcarty>
thelema: In short, I think I'm running into a bug in the ordering of Batteries' sets (the same code works as expected when Legacy.Set.Make is used) but I'm not sure the bug is worth tracking down and reporting if 1.x is considered dead.
<thelema>
hcarty: good question. Does the same code work under HEAD batteries?
<thelema>
I'm considering 1.x dead. I should do another beta release of 2.0, and maybe a real release sometime, despite all the tests infrastructure not being cleaned out.
<hcarty>
thelema: What is the status of BatteriesNC in 2.x?
<hcarty>
thelema: I haven't tried with master/head yet, as the changes required to test are fairly involved.
pangoafk is now known as pango
<thelema>
batteriesNC?
<thelema>
No Exception?
<hcarty>
thelema: Not Compatible. Labeled functions, (usuall) no exceptions
<hcarty>
.
<thelema>
ah, the nice, backwards incompatible batteries... Still needs a ton of work (and likely some discussion on mailing list)
<thelema>
unless someone steps up hard, most likely this won't make 2.0
<thelema>
2.0 will still have basic compatibility with stdlib
<thelema>
and will likely lack the extensive changes to build BatteriesNC.
<hcarty>
Ok, that's good to know for planning purposes. I've been holding off on testing any large projects against Batteries-git since I wasn't sure what the future plans were.
<thelema>
We'll probably add the submodules needed to build BatteriesNC during the 2.0 cycle, culminating in addition of BatteriesNC towards the middle of the 2.0 cycle
<hcarty>
thelema: Sounds like a good plan.
<thelema>
there's likely still a few more backwards incompatible changes to be added to batteries-git, but it's what I code my large projects against.
cdidd has quit [Ping timeout: 276 seconds]
<flux>
I wonder if debian (and other dpkg-based distributions) are going to make a batteries2-package for this
<flux>
I guess that's what's done usually with non-backwards-compatible packages?
<thelema>
Fair question, probably since no package depends on batteries1, they'll just keep the name batteries
<thelema>
maybe once someone depends on batteries, they'll have to add version numbers to the names
<flux>
but it's annoying to upgrade your distributino and notice that your programs don't compile anymore.
<hcarty>
thelema: Any thought to having Batteries 2.0 install as batteries2?
<thelema>
if the maintainers want to maintain 1.x, they're welcome to; they won't get much help from me.
<hcarty>
thelema: Allowing for simultaneous v1 and v2 installations
<thelema>
hcarty: I'm still leaning towards just the findlib package name 'batteries', unless someone can convince me that large numbers of people will want to keep using v1 even transitionally
<thelema>
The changes are mostly in the naming of the main module - 'batteries_uni' is gone, batteriesThread is now needed for threads
<thelema>
almost all the rest of the interface is the same.
<flux>
hmm, so does that mean that no program is going to work with b2 out-of-the-box?
<flux>
if both threaded and non-threaded need building modifications? or do some of them come automatically with findlib?
<thelema>
if your program compiled with threads but didn't use any of the batteries threads extension, it'll work out of the box.
<thelema>
findlib automatically links in the batteriesThreads module (actually, I should double check this for when it's not explicitly opened or referenced)
<thelema>
when compiling for threads
<thelema>
I don't know how common different usage patterns are: 'open Batteries' with threads, 'open Batteries_uni' without threads, 'open Batteries_uni' with threads (will compile but work unreliably in some cases)
<thelema>
If you're using the first (which is recommended), no changes are needed unless you were using BatMutex/BatRMutex
<thelema>
If the second, you need a s/Batteries_uni/Batteries/
<thelema>
and the third, the same.
<hcarty>
thelema: How will OCaml 3.13.x compatibility be handled?
<hcarty>
thelema: stdlib compatibility that is, due to a few API changes
<thelema>
The best solution so far is to copy implementations so that the 3.13.x API is available to programs running 3.12
<thelema>
The issue with Hashtbl, which isn't backwards compatible will likely require a Hashtbl313 module
<hcarty>
thelema: I think there is another module as well, but I don't remember which one
<hcarty>
Gc perhaps
<thelema>
then there may be a BatGc313 module
<hcarty>
thelema: Handled like Camomile was in 1.x?
thomasga1 has joined #ocaml
thomasga has quit [Read error: Connection reset by peer]
<thelema>
maybe; I'm tempted to just leave two interfaces, and have the 3.12 be the default for a while, and when batteries 3 rolls around, upgrade the default
<thelema>
the camomile strategy didn't affect our exposed interface
<thelema>
this would, and I'd rather not have programs require a particular version of batteries to work
<hcarty>
So Batteries.Gc and Batteries.Gc313 would exist
<thelema>
yes
<thelema>
maybe a Batteries313 module too
<hcarty>
That makes sense, although it gets very hairy very quickly.
<thelema>
yes, if the ocaml devs start pushing too many incompatible changes, we'll have to come up with a different plan
<thelema>
hopefully batteries will only have to support two minor (3.12 and 3.12) versions at a time, and backwards incompatible changes won't happen within a version
<hcarty>
It would be nice if a cleaner method were available, but nothing immediately comes to mind.
ocp has joined #ocaml
<thelema>
I think the cleaner method is to give up compatibility with stdlib.
cdidd has joined #ocaml
<hcarty>
More than giving up compatibility, it would require not basing any of Batteries on the OCaml stdlib used during compilation.
<hcarty>
Instead either avoiding stdlib entirely or including all of stdlib in Batteries.
Snark has quit [Quit: Quitte]
Kakadu has quit [Ping timeout: 245 seconds]
<thelema>
I've been tempted at times to do the second, but have been rightly told that it's not a good choice.
Kakadu has joined #ocaml
<hcarty>
Not unless (at least) two or three more thelemas join the Batteries party :-)
<thelema>
:) Vincent Hugot has been contributing quite a good deal to batteries.
<thelema>
(** midpoint function; [mid a b] returns the mean of [a] and [b]; an integer that lies between them and is as equidistant from both as possible. *)
<thelema>
does this make sense?
<hcarty>
thelema: It does
<thelema>
I'm trying to explain "(a+b)/2, but done correctly"
<thelema>
maybe I should just say that.
<hcarty>
This is somewhat disturbing. The Set.Make bug I'm seeing goes away entirely when going back to stdlib. Batteries-master does not seem to change batSet.ml at all, except to add a few new functions.
<thelema>
I assume the disturbing thing is that batteries-master doesn't have your bug?
<hcarty>
thelema: Perhaps s/them/[a] and [b]/
<hcarty>
thelema: The disturbing thing is that there is no reason to expect that it does not
<thelema>
meaning that noone else has found your bug...
<hcarty>
And I'm not doing anything fancy with sets
<hcarty>
thelema: Yes, and it is somewhat subtle
<thelema>
sets of what?, and what operation returns a bad result?
<hcarty>
Ordering becomes... wrong at some point
<hcarty>
mine
<hcarty>
min_elt that is
<thelema>
ok
<hcarty>
It doesn't not return the minimum element according to Ord.compare
<thelema>
can you say anythin about the values you're comparing?
<hcarty>
Given that it works in stdlib and doesn't have an obvious fix in Batteries-master, it is probably worth trying to reduce this to a simple test case.
<hcarty>
thelema: Yes, they are processing jobs
<hcarty>
thelema: The sorting is first done on the status of the job (Not_ready | Ready | In_progress | Done [`completed | `skipped])
<thelema>
I assume this doesn't change over time?
<hcarty>
All Ready jobs should be "less" than other jobs
<hcarty>
thelema: Not in a non-functional way
<thelema>
ok
<thelema>
You're using functorized sets in both cases, right?
<hcarty>
Yes
mcclurmc has quit [Excess Flood]
<hcarty>
At some point, Done _ jobs are returned by min_elt when Ready jobs still exist in the set.
* thelema
writes a quicktest to sort a list using a set
<thelema>
a list with lots of duplicates....
<thelema>
ah...
<thelema>
maybe there's an issue with set semantics
<thelema>
does your comparison function return equal for same status?
<thelema>
I imagine you'd only get one value of each status in the set if you did this, so probably not
<hcarty>
thelema: No. Other components of the set element are compared in a specific order (priority, submission time, etc.)
mcclurmc has joined #ocaml
<thelema>
ok, so using the set as a priority queue, got it
<hcarty>
thelema: Yes, effectively
<hcarty>
thelema: In pseudo-match-code: ready a && (not (ready b)) -> ~-1 | ready b && (not (ready a)) -> 1 | compare_priorities a b
<thelema>
quickcheck isn't finding any difference between pushing a list of (i mod 5, i) into the set and getting them back out in order and just sorting the set, so I'm suspecting it's not the tree itself
<thelema>
I inspected the implementation of min_elt, and it looks as solid as I can find.
* thelema
thinks about the compare function
<thelema>
that compare should be fine.
<thelema>
I assume you remove the element after min_elt, right?
<hcarty>
thelema: Yes
<hcarty>
thelema: Then re-add as In_progress
mdelaney has joined #ocaml
<thelema>
(Q.list Q.int) (fun l -> let xs = List.map (fun i -> i mod 5, i) l in let s = ref (of_list xs) in let m = ref (min_elt !s) in while fst !m = 0 do s := remove !m !s; s := add (2,snd !m) !s; m := min_elt !s; done; for_all (fun (x,_) -> x <> 0) !s ) failed for [-4066518072663085324; -3032729807600846827; -4551804256272313835; -1481084739772429570; -2288611458518333764]
<thelema>
you're right; there is a bug somewhere.
<thelema>
(sorry about that being impossible to read)
<hcarty>
thelema: It's ok, I'm just glad I'm not the only one seeing it.
<hcarty>
thelema: Thank you for testing and confirming
<thelema>
hmm, maybe my test is broken; it fails for []
<thelema>
drat, the error has disappeared again once I correct for []
<hcarty>
I'll try to come up with a test case here
<thelema>
hcarty: you know there's more Ready values because you're looking into the set and finding them there?
<thelema>
on a side note, Batteries can use a priority queue for this kind of use-case
<thelema>
s/can use/needs/
<hcarty>
thelema: Yes, I have tested for existing Ready values a few ways - by printing the full set; by filtering on a Ready status, resulting in a non-empty set (also printed for posterity).
<thelema>
well, I'll commit my test and maybe it'll die on someone else's run
ocp has quit [Quit: Leaving.]
ocp has joined #ocaml
<tomprince>
where is caml_exn_Sys_error defined?
<thelema>
tomprince: it's a builtin
<tomprince>
Well, I am trying to get a shared libasmrun.
<tomprince>
It is declared extern in asmrun/fail.c
<thelema>
asmrun/fail.c
<thelema>
it's not defined anywhere, then.
<tomprince>
I wonder how that is supposed to work, then.
<tomprince>
I am trying to get ocaml code (coq in particular), to be accesible as a python module.
avsm has joined #ocaml
<thelema>
coq raises Sys_error?
<tomprince>
I have it working if I generate an executable, and call into python.
<tomprince>
No, it seems that importing libasmrun_shared.so isn't working because of missing symbols.
<ocp>
caml_exn_Sys_error is generated by ocamlopt when you ask it to link an executable
<ocp>
ocamlopt -o toto -dstartup toto.ml
<ocp>
will generate a file toto.startup.s where you can find its definition
ulfdoz has quit [Ping timeout: 252 seconds]
<adrien>
is there a place these options have some kind of description? even very short ones
<ocp>
yes, ocaml-3.12.1/asmcomp/*.ml ;-)
<ocp>
all the -d____ options are debugging options for the code generator
<ocp>
they are not documented, as they are likely to be used by people reading the sources of the compiler
<tomprince>
Ah, but I need to refer to everything I wan't a definition for in toto.ml
<adrien>
ocp: I understand that but it's sometimes a bit frustrarting not to be able to find out awhat some options mean
<adrien>
;-)
<ocp>
tomprince: what do you mean ? In my example, toto.ml can be empty, caml_exn_Sys_error will still be in toto.startup.s
<ocp>
adrien: these options are the only ones not documented, I should probably write a blog entry one day on these options
<tomprince>
Apperntly I can't search. Or it changed from one run to the next.
<adrien>
ocp: that would be great; even a couple lines per option would be enough I think
BiDOrD_ has quit [Read error: Connection reset by peer]
BiDOrD has joined #ocaml
Submarine has quit [Remote host closed the connection]
sebz has joined #ocaml
mcclurmc has quit [Excess Flood]
<tomprince>
ocp: I don't get caml_exn_* when I add -shared ...
<ocp>
Of course, -shared specifies that you are building a library, the file is only generated when you create the final executable
mcclurmc has joined #ocaml
<tomprince>
Well, I wan't the final ocaml product to be a shared-lib, that links with non-ocaml code.
<ocp>
you are using -output-obj option ?
<ocp>
Have you tried to call ocamlopt with -output-obj (to generate an ocaml library embedded in a C library), -dstartup (to keep the assembly file) and -verbose (to show how the linker is called)