<dsheets>
jasiek: you're build a quite old version of core. how did you install ocaml? you are missing camlp4.
kushal has joined #ocaml
rgrinberg has quit [Ping timeout: 244 seconds]
<jasiek>
from macports: ocaml @4.02.2_1 (active)
<dsheets>
jasiek: need ocaml-camlp4, too
Reshi has joined #ocaml
kushal has quit [Excess Flood]
kushal has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Client Quit]
<jasiek>
ok, let's have a look
rgrinberg has joined #ocaml
mistermetaphor has joined #ocaml
mengu has quit [Remote host closed the connection]
yegods has joined #ocaml
rgrinberg has quit [Quit: WeeChat 1.5]
rgrinberg has joined #ocaml
Reshi has quit [Quit: WeeChat 1.4]
tane has quit [Ping timeout: 260 seconds]
struk|work has quit [Ping timeout: 250 seconds]
struk|work has joined #ocaml
kushal has quit [Ping timeout: 260 seconds]
<Algebr``>
Asking again, how much of a benefit is Lwt_pool?
tane has joined #ocaml
slash^ has joined #ocaml
<flux>
as in compared against what?
<Algebr``>
as to not using a thread pool and always using fresh Lwt threads, they are basically worker threads
<Algebr``>
not sure it will be a big improvement in performance since lwt threads are supposedly so cheap anyway
<flux>
I quite doubt there's a performance benefit to be had.. I think its point is to limit usage of some other resource than threads.
<flux>
for example, its documentation mentions "for example pools of connections to a database"
<Algebr``>
yea
<def`>
Algebr``: it's more expensive
<def`>
but that's really not the point of the pool as pointed by flux :)
<def`>
(You cannot reuse lwt threads, they are "pure")
Orion3k has quit [Read error: Connection reset by peer]
<Algebr``>
def`: what's more expensive?
<def`>
A pool is more expensive than an Lwt.t
<Algebr``>
but the pool is a onetime cost at startup
<def`>
Absolutely not.
<Algebr``>
okay go on
<jasiek>
what do you guys use ocaml for?
<Algebr``>
everything possible, its a general purpose language.
octachron has joined #ocaml
<def`>
Algebr``: the pool is a way to limit concurrency
<jasiek>
right, i know that
jwatzman|work has quit [Quit: jwatzman|work]
<Algebr``>
def`: here's a usecase say you make a Lwt based server and you know the max number of connections it will ever have to make, why do Lwt_pool.use p (fun _ -> ) in the callback for the Lwt server
<jasiek>
i know jane street uses it extensibely
<def`>
(in other languages, the fact that a pool is faster is an implementation detail, the purpose of pool is to ensure than no more tasks than a given maximum is executed)
<pecan>
I like writing one-off domain-specific compilers with it
<Algebr``>
jasiek: compiling to JS, systems software, mirageos
<reynir>
Is Lwt_pool new or have I just missed it when I needed it? :-)
Simn has quit [Quit: Leaving]
<def`>
Algebr``: there is no point, it can only make things slower
<Algebr``>
Okay, so the pool is really like a sempahore
<Algebr``>
semaphore
<aantron>
Lwt_pool i think is not very new
<def`>
Algebr``: wait no, knowing the "max number of connections
<companion_cube>
no, it's old
<companion_cube>
and pretty useful
<def`>
" doesn't matter
<def`>
it's the number of concurrent connections that matter
<Algebr``>
I have this Lwt based server and I know upfront the max number of connections it will ever be made to do
sh0t has quit [Ping timeout: 260 seconds]
<Algebr``>
I think benchmarking will answer this
<flux>
algebr``, is your goal to protect your service against DoS attacks? if not, then I think Lwt_pool is of no use..
<def`>
Algebr``: a pool can only be more expensive than plain threads since the pool is built over threads >_<
<mrvn>
def`: but you pay it forward and reuse them
<def`>
*PAN*
<Algebr``>
def`: yes but my line of thinking was that when the server handles a response it has to make a new Lwt.t rather than just use one from the pool
<def`>
Algebr``: Lwt.t are pure
<def`>
you cannot reuse them
<Algebr``>
No, goal is to increase throughput of services that use the server
<def`>
the garbage collector reuse them
<Algebr``>
But isn't that what the pool is?
<def`>
NO
<Algebr``>
and I'm trying to lessen as much friction as possible on the OCaml side
<Algebr``>
ah
<def`>
A pool is a way to limit concurrency, not reuse anything.
<flux>
in my mind using an Lwt_pool for reusing lwt threads is as much useful as having a cache for integers :)
<def`>
If in java a pool is reusing something, then again, that's an implementation detail.
<aantron>
hmm, the Lwt_pool docs may be misleadingly-written
kushal has joined #ocaml
<mrvn>
def`: normaly you take a resource out of a pool, use it and *put it back*
<Algebr``>
uh everyone else's usage of pool is like what mrvn is saying
<mrvn>
The point being that you safe on creating and destroying the resource over and over.
<Algebr``>
I mean outside of lwt, then Lwt docs should be clear about this
<def`>
s/pool/Lwt_pool/
<aantron>
Algebr``, if you find the docs are confusing, could you please open an issue on GH? PR is also welcome
<mrvn>
If Lwt_pool does something else it should be named something else.
<Algebr``>
I would do a PR of course, but I'm not sure if I'm correct, really going off of def`'s wisedom and saying
<aantron>
then an issue is fine. i am reading the docs and i dont get what Lwt_pool does exactly
<aantron>
going to improve the docs a bunch at some point
<def`>
Lwt threads are monotonic, they can be set only once, which make them pure from the point of view of the monad.
<def`>
In this context, what could it mean to reuse an Lwt.t ?
<def`>
Oups, I was wrong in one sense...
<def`>
Argh
<def`>
So Lwt_pool actually allows to reuse resources, but not threads.
tane has quit [Ping timeout: 276 seconds]
* def`
digging a hole
<Algebr``>
....
<def`>
Algebr: ok, fresh explanation... An 'a Lwt_pool.t allows to reuse ressources of type 'a.
<edwin>
I actually looked at using Lwt_throttle once, before I realized that Lwt_pool does what I wanted
<def`>
Not threads, but ressources, say connection to a database.
<Algebr``>
Right, okay, now that is clearer
<def`>
The number of ressources existing at a given time is limited by the pool size. They are created lazily.
sh0t has joined #ocaml
<def`>
When you thread finishes, ressource is put back to the pool.
<Algebr``>
resource being whatever the 'a was right
<def`>
When you grab a ressource, it is created if the pool is not full or if previous ressource didn't pass validation predicate.
<def`>
Yes.
<def`>
So again: there is no point in pooling "threads", they are pure things.
<Algebr``>
ah, damnit, so I don't have any useful 'a to give
<Algebr``>
right, much clearer, than you
<def`>
Pooling is useful as a cache but not, like you intended, to increase performance. They can only decrease performance, unless you want to arbiter access to some scarce external ressource.
rgrinberg has quit [Quit: WeeChat 1.5]
<edwin>
or if establishing the connection to the external resource is expensive
<edwin>
might be faster to send a query on an already established SSL connection than to perform a new SSL handshake
<def`>
Yes, scarce was a bit vague. Scarce or expensive to get :)
<Algebr``>
Okay, so now I'm wondering how much of a performance improvement I can get from using Lwt_preemtpive
<def`>
Ok it seems you have a performance problem :). Can you tell more about it?
hcarty has joined #ocaml
<Algebr``>
10 servers on 10 different ports providing a service to forward data from one tcp endpoint to another.
tane has joined #ocaml
<flux>
so your performance is lacking? not enough MB/s?
<hcarty>
Algebr``: Would it be better if the doc comment for 'a Lwt_pool.t read more like: "Type of a pool containing values of 'a"
<Algebr``>
yea, much better. flux yea, not enough MB/s. Probably because I'm using Lwt_io also instead of directly going for file descriptors
<Algebr``>
hassle to refactor that
<hcarty>
I'll submit a PR
<flux>
algebr``, so does it consume a lot of CPU?
<Algebr``>
also where's Lwt's monad join, unit Lwt.t Lwt.t -> unit Lwt.t
<edwin>
I used this in one case to improve throughput: Lwt_io.set_default_buffer_size (128*1024); Lwt_unix.set_pool_size 64;
<Algebr``>
flux: I Don't think it does
<edwin>
I think it maxed out the ethernet link in my case
<aantron>
hcarty: "Creating pools" is also a bit useless in the module brief. perhaps "resource pools" ?
<Algebr``>
edwin: okay, this is a new pool!
<flux>
algebr``, hmm, doesn't that suggest your problem is network-bound?
<companion_cube>
anyone knows how to output a blockquote with Cow?
<Algebr``>
flux not network, local sockets
<flux>
hmm
<edwin>
there's of course a tradeoff, larger buffer size means more memory usage
<flux>
algebr``, so what does perf top say? or other profiling tools?
<Algebr``>
don't care about the memory
kushal has quit [Read error: Connection reset by peer]
<Algebr``>
haven't put in serious perf checking, was putting out fires and now have look at stuff like this
<Algebr``>
can
<edwin>
how big are the replies that you send, and whats your current MB/s?
<flux>
I guess if the network isn't saturated and the CPU isn't either, doesn't that mean the program is blocking?
kushal has joined #ocaml
<Algebr``>
The total amount moved across a session could be as small as 10mb or as big as 3gb
<Algebr``>
It does get sluggish because when under high load I get a laggy response from other parts of the program
<Algebr``>
current MB/s is up to 30 at beast
<Algebr``>
best
<flux>
well, that's not very high indeed
<Algebr``>
not high at all
<Algebr``>
edwin: sure about Lwt_unix.set_pool_size 64?
<edwin>
the default is 1000, it used a bit too much memory for me, but if thats not your concern leave it at the default
<edwin>
increasing the Lwt_io buffer size helped a lot in my case, but YMMV
<hcarty>
aantron: Agreed. I'll make edits as I have time and submit PRs
<Algebr``>
edwin: I'm not seeing Lwt_unix.set_pool_size at all
<aantron>
hcarty: np, i would appreciate it if you amend the existing commit in the current PR, though. and let me know when you are done making edits to it, then i will merge :)
<aantron>
and thanks
Mercuria1Alchemi has quit [Ping timeout: 276 seconds]
<hcarty>
aantron: I'm happy to help where I can. Thanks for your recent Lwt curation :-)
<Algebr``>
ah, there is is
tennix has quit [Ping timeout: 244 seconds]
<edwin>
do you perform any processing on those tcp streams, or just send from one endpoint to another?
tane has quit [Ping timeout: 276 seconds]
<Algebr``>
no processing
yunxing has joined #ocaml
<edwin>
also how often do you flush the streams? if those streams are meant to be part of some request-reply sequence then it coudl be useful to flush when your source stops sending data. otherwise Lwt_io will only actually send the data when: its buffer is full, your application is otherwise idle (i.e. Lwt.pause resumes) and it auto-flushes
kushal has quit [Ping timeout: 240 seconds]
<edwin>
either buffer is full or application is idle*
<aantron>
perhaps this doesnt belong in the main lwt docs, but maybe there should be an article on how to do io with lwt efficiently, under various circumstances?
copy` has joined #ocaml
<edwin>
like a collection of tips? if you want lower latency do this, if you want higher throughput do that?
<flux>
algebr``, are you certain more data would be processed if only this piece of code performed better?
<Algebr``>
and of course no special build instructions mentioned for lwt.preemptive, added lwt.preemptive to builddepends but build breaks with ocamlfind: Error from package `threads': Missing -thread or -vmthread switch, guess I need to add something to _tags
butts_butts has quit [Ping timeout: 260 seconds]
<Algebr``>
edwin: no request-reply, just streaming binary data, think scp
yegods has quit [Remote host closed the connection]
<aantron>
edwin: yes, perhaps something like that
<Algebr``>
flux: its an intuition, I have squeezed other places already
<edwin>
ok, was gonna suggest tcp_nodelay, but for throughput that doesn't help, only for latency
<aantron>
Algebr``: issue/PR will be welcome again when you have resolved this :)
<edwin>
have you tried to optimize a single stream for max throughput? have a look with strace -f -ttt -T to see if you spot any obvious places where your application sleeps when it shouldn't
<Algebr``>
ahh, how does one turn on -thread via oasis, why doesn't lwt.premptive do it for me....
<hcarty>
aantron: "How to do IO with Lwt" would be a very nice article to have
<Algebr``>
hcarty: also a blog post I've been meaning to write
<Algebr``>
edwin: no, need to do a dedicated profiling day
<hcarty>
Algebr``: That's a common annoyance... and I don't know why ocamlfind doesn't/can't do the -thread stuff on its own
<aantron>
i thought it can.. checking
yegods has joined #ocaml
mengu has joined #ocaml
<Algebr``>
hcarty: so how to fix?
<hcarty>
Algebr``: I've been lucky so far - "just" using Lwt_io or zeromq has been fast enough
<aantron>
but it should also be added to docs if its a problem, since not everyone will necessarily be building with ocamlfind
tane has joined #ocaml
<hcarty>
Algebr``: tag(threads) -- or maybe tag(thread), I can't ever remember which
<hcarty>
aantron: agreed re: docs
Mercuria1Alchemi has joined #ocaml
<Algebr``>
hcarty: found it
<Algebr``>
just need to add threads to buildDepends
<hcarty>
aantron: ocamlfind may be able to, but I always see "threads" listed explicitly, when, say, code uses "core" which requires threads. I suspect it has to do with the vmthreads/system threads split, but I don't know if that's actually the case.
<aantron>
anyway at least ocamlfind allows to pass linker options, not sure if this is sufficient. will look into it later, issue will help to remember :)
<aantron>
ah, perhaps
<Algebr``>
so maybe lwt.premeptive shoudl just have it in its META file, or maybe threads is a fake buildDepends for oasis
dsheets has quit [Remote host closed the connection]
<Drup>
(I'm surprised that's not the first thing you tried, it's the most obvious one, and it works)
kolko has joined #ocaml
<aantron>
hcarty: thanks!
<hcarty>
Drup: Why is that necessary? Is it because it's possible to pick between threading implementations?
<Algebr``>
obvious is only obvious when its obvious to you
<Drup>
or because someone forgot to specify the dependency in the META file ?
<Algebr``>
I forgot if threads is a package, or a ocamlfind flag
rgrinberg has joined #ocaml
<hcarty>
Drup: Is that all it is? A forgotten META dependency?
<Drup>
I guess ?
<Algebr``>
it seems so
<edwin>
Algebr``: also up to how many bytes do you read from an Lwt_io at once? try to make that match the Lwt_io's underlying buffer size
<Algebr``>
I read whenever there is data, so basically all the time
<hcarty>
It seems to be a common thing - anything that requires threads seems to also require the user to pass the appropriate threads tag/package/etc
<Drup>
really ?
<edwin>
Algebr``: yes, but how much data do you ask from it at once when you call Lwt_io.read*?
rand__ has joined #ocaml
amnn has joined #ocaml
<edwin>
if you don't give it a count Lwt_io.read will try to read the whole stream
<hcarty>
Drup: I've seen it with Lwt_preemptive and when I've had to work with code using Core
<Drup>
I though it was ocamlfind magic but maybe it's oasis magic instead
relrod has quit [Ping timeout: 244 seconds]
kushal has joined #ocaml
<aantron>
hcarty: ignore the appveyor failure, thats still a work in progress
rand__ has quit [Ping timeout: 246 seconds]
rand__ has joined #ocaml
relrod_ has joined #ocaml
relrod_ has joined #ocaml
amnn has quit [Ping timeout: 276 seconds]
shinnya has joined #ocaml
amnn has joined #ocaml
<hcarty>
aantron: Thanks
mengu has quit []
<NingaLeaf>
can anyone recommend a current compiler tutorial implementing a DSL? I know others have asked this, but i can't find the suggestions looking back as the irclogs.
Mercuria1Alchemi has quit [Ping timeout: 276 seconds]
sh0t has quit [Ping timeout: 250 seconds]
lokien_ has joined #ocaml
<hcarty>
Is it ok to "eval $(opam config env --switch=MY_SWITCH)" to use MY_SWITCH just in the current terminal session?
<Drup>
yes
<Drup>
I do it all the time
<Drup>
(with several switches at the same time)
<Drup>
NingaLeaf: as a library or as a ppx ?
<NingaLeaf>
Drup: not sure - i'm looking to write a static analyzer for python
<Drup>
Ah.
<Drup>
Do you have a parser already ? :)
<NingaLeaf>
No, lol
<Drup>
then you might want to start by that ..
<Algebr``>
ah, the Lwt_pool.use gives you a 'a, but that's assuming each is equavillaly useable, but mine are unique
<Algebr``>
I guess I could add indirection of a hashtable?
<Drup>
Algebr``: what are you pooling ?
<Algebr``>
that's hacky
<Algebr``>
socket connections
<NingaLeaf>
Drup: I have one started but its only maybe 30% finished.
<Drup>
does it matter which connection you are using ?
<Algebr``>
but one cannot another replace another, they are unique
<Algebr``>
yes, matters
<Algebr``>
I just want to make them once.
<Drup>
then don't use a pool
<Algebr``>
I guess I can just skip the pool
<Algebr``>
yea
<Drup>
(or use a 1-pool)
<Algebr``>
plain hashtable should be fine
kushal has quit [Ping timeout: 260 seconds]
<hcarty>
Algebr``: That's what I was going to suggest :-) And if you end up needing duplicates of one or more the values in the table could be Lwt_pool.t
<hcarty>
Drup: Thanks - I've recent started having to switch between several switches regularly. Now I want a bash function to automatically do this when I change into a directory...
<hcarty>
On the todo list
<Drup>
hcarty: probably going to be there in next opam
<hcarty>
Drup: That would be quite nice
sh0t has joined #ocaml
<hcarty>
Avoid the frustration of a stale setup.data
sh0t has quit [Read error: Connection reset by peer]
sh0t has joined #ocaml
lokien_ has quit []
scarygelatin has joined #ocaml
unbalancedparen has joined #ocaml
yunxing has quit [Remote host closed the connection]
<Algebr``>
crappy setup.data blew an interview for me.
yunxing has joined #ocaml
<hcarty>
Algebr``: Ouch
<NingaLeaf>
Drup: do you any suggestions on current compiler tutorials?
<Drup>
1) not really 2) you are not building a compiler
<NingaLeaf>
ok thansk!
<Drup>
what kind of static anlysis do you wish to do ?
<NingaLeaf>
Its really a proof of concept looking for type issues applying dependent type [theory]
<NingaLeaf>
there alot more to it but thats the high level
<Drup>
I see
<Drup>
you never built anything like it ? (since you are asking for tutorials ...)
<Drup>
that's not really entry-level static analysis ^^'
<NingaLeaf>
i've done a lot of work in C and some to a little work in ocaml
<NingaLeaf>
I've found ocaml to work for me and wanted to branch out
<aantron>
hcarty: companion_cube: channel: you are invited to submit proposed Lwt_result modules (or other approaches to Lwt and result) to resolve https://github.com/ocsigen/lwt/issues/226. i will eventually focus on this. i still have things in the queue first, but it would be nice to give interested people some more time to discuss. thanks in advance for any PRs :)
<hcarty>
aantron: I can submit something now/soon
<aantron>
no rush, but would be appreciated :)
dsheets has quit [Remote host closed the connection]
<j0sh>
i'm trying to send a signal to some subprocesses with Lwt_process.process_none#kill, but they don't seem to take effect until after I've Ctrl-C'd my program?
NingaLeaf has quit [Quit: Leaving]
<j0sh>
Lwt_process.process_none#terminate works, but I'm not looking for sigkill
yunxing has quit [Remote host closed the connection]
dsheets has joined #ocaml
yunxing has joined #ocaml
<hcarty>
aantron, Drup: Do you have a preference on ('a, 'b) result vs ('ok, 'error) result when naming labeling type parameters?
dsheets has quit [Ping timeout: 276 seconds]
<hcarty>
And if ('ok, 'error) what name would you use for a transformed 'ok or 'error?
<j0sh>
scrub that, Lwt_process.process_none#kill does not seem to be having an effect at all
NingaLeaf has joined #ocaml
NingaLea_ has joined #ocaml
NingaLea_ has quit [Client Quit]
<Drup>
hcarty: doesn't matter, do as you feel
<Drup>
'ok/'error is good for the type declaration
<aantron>
hcarty: i prefer 'ok/'error at least in the declaration. long function signatures with multiple mentions of the type variables should probably use 'a/'e
<aantron>
but otherwise 'ok/'error wherever it doesnt harm legibility
<NingaLeaf>
Drup: i've never built a static analyzer that why i'm exploring using ocaml for my proof of concept
<aantron>
(i actually dont like 'ok :p but i do like 'error)
<Drup>
NingaLeaf: ocaml is a good choice, but it's going to diminish the baseline theoretical difficulties of the task :)
<Drup>
good luck ^^'
<Drup>
it's *NOT* going to ..
sh0t has quit [Ping timeout: 276 seconds]
<hcarty>
Drup: aantron: Thanks
<aantron>
mostly because 'ok somehow sounds like it carries unit to me, instead of a non-trivial value, but its not a big deal
<aantron>
(i.e. the corresponding variand would be Ok, not Ok of 'ok)
<aantron>
and if there is a bunch of discussion in IRC, it probably ought to be summarized in the PR so others can see later. for more bikeshedding, bickering, and nit-picking of course :)
<aantron>
a bunch of +useful* discussion :)
<companion_cube>
well feel free to discuss on the PR
<companion_cube>
and downvote with :-1: every single line :p
<companion_cube>
Drup: I've always known you were a subtle person, this url confirms it
<hcarty>
I think I'm ok with keeping the discussion in companion_cube's PR
<aantron>
yes, please object to #247 :p
<hcarty>
s/I think//
<hcarty>
As companion_cube said, there isn't much difference and 247 is more complete than what I would have proposed
<Drup>
companion_cube: I'm very subtle, especially in my music tastes
<companion_cube>
is there a @since policiy for lwt right now?
<companion_cube>
-i
<aantron>
no existing policy i know of, but add it
<aantron>
well
<aantron>
or don't.. since we don't know what version the next one will be
<Drup>
aantron: you make the policies now :D
<companion_cube>
heh
<aantron>
yes, i know. i guess my policy is i should take care of it? or, what would be reasonable?
<companion_cube>
@since NEXT_RELEASE
<Drup>
^
<companion_cube>
+ a simple sed script before release
<companion_cube>
works well for containers
<aantron>
fair enough
<companion_cube>
I added a few things
<hcarty>
companion_cube: If you want to add return_ok/return_error with (possibly?) less typing - http://vpaste.net/9lP7W
<companion_cube>
too late :)
sh0t has quit [Quit: Leaving]
<hcarty>
companion_cube: So fast!
<Drup>
companion_cube: you didn't changed Lwt.result ?
<companion_cube>
oh
<Drup>
I even talked about it in your thread ... =')
<companion_cube>
but how to deal with the 2 other cases?
<Drup>
You don't
<companion_cube>
meh
<Drup>
I mean
<Drup>
'a lwt = 'a | exn | actual_thread
<Drup>
(roughly)
<Drup>
if it's an actual_thread, you wait it out, if it's 'a, it's Ok 'a, if it's exn, It's Error exn
<Drup>
tada.
<companion_cube>
ah, ok, it works because result_of_state is actually useless
<Drup>
yes
<companion_cube>
wasn't obvious...
<Drup>
well, not useless, the identity
<Drup>
:D
<companion_cube>
well it's not translatable
<Drup>
nope
<companion_cube>
but it looks like it's not useful
<Drup>
doesn't matter
<Drup>
yes
<Drup>
I mean, not very useful
<Drup>
lwt already contains a result type, so it would be nice to have smooth interaction with that
<companion_cube>
done
relrod_ is now known as relrod
<Drup>
it's not exposed ?
butts_butts has quit [Ping timeout: 252 seconds]
<Drup>
also, you have 'a result -> 'a lwt, but you don't have 'a lwt -> ('a, exn) result Lwt.t
<Drup>
oh, you do
<companion_cube>
not in Lwt
<Drup>
nevermind
<Drup>
(it's "catch")
<companion_cube>
the only missing piece, I think, is `('a,exn) Lwt_result.t -> 'a Lwt.t`
<Drup>
(it's probably more efficient with Lwt.state, but that's details)
kakadu has quit [Quit: Page closed]
<Drup>
you probably want to deprecate make_value/_error
<companion_cube>
propose it on the PR and hl the maintainer ;)
<companion_cube>
(this should be discussed)
<Drup>
effort :(
<Drup>
aantron: I'm HLing the maintaner x)
<companion_cube>
'k
<hcarty>
How were make_value and make_error used previously? What would their replacement if they're deprecated?
<hcarty>
I ask because I've never used either
d0nn1e has quit [Ping timeout: 244 seconds]
<Drup>
Result.ok
d0nn1e has joined #ocaml
<companion_cube>
I suppose they are not used a lot
<Drup>
yeah
<hcarty>
Drup: I guess it would be Lwt.return_ok ok/Lwt.return_error exn
<hcarty>
companion_cube: aantron: I back companion_cube's PR, I'm not making a separate one. And I look forward to dropping my internal version of this :-)
<Drup>
hcarty: no, it's really Result.ok
<hcarty>
Drup: Oh right, those functions don't return threads
<Drup>
yeah
<companion_cube>
doesn't cost much to keep them though
slash^ has quit [Read error: Connection reset by peer]
octachron has quit [Quit: Page closed]
Denommus has joined #ocaml
yunxing has quit [Remote host closed the connection]
yunxing has joined #ocaml
Icefoz has joined #ocaml
<Icefoz>
So I have a weird issue, where compiling something with ocamlc is not finding a necessary .so when I run the resulting program, but compiling with ocamlopt has no problems.
<hannes>
is there something (maybe in ocamlfind) which returns for a given package/subpackage the list of packages in the requires line (of the META file)?
<Icefoz>
I'm using a fresh 4.03 toolchain installed from opkg...
<Icefoz>
Any ideas on where to start?
<copy`>
Is it possible to install multiple opam switches with the same ocaml version?
<Icefoz>
Hm, setting LD_LIBRARY_PATH to point to the dir containing the .so works, but I'd think ocaml should know where to find it already...
<copy`>
hannes: The first one did it
shinnya has quit [Ping timeout: 276 seconds]
<Drup>
hannes: one of the option of ocamlfind query, I guess
<hannes>
Drup: ah, -r does something in that direction...
amnn_ has joined #ocaml
amnn_ has quit [Read error: Connection reset by peer]
amnn_ has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 246 seconds]
amnn has quit [Ping timeout: 250 seconds]
pierpa has joined #ocaml
chris2 has quit [Ping timeout: 260 seconds]
<aantron>
Drup: hcarty: companion_cube: thanks!
Icefoz has left #ocaml ["bah"]
amnn_ has quit [Read error: Connection reset by peer]
amnn has joined #ocaml
<aantron>
once i drain the queue enough and look at this properly, i will likely have some minor comments, but it basically looks good. you are welcome to keep messing with it as you come up with ideas