<adrien_oww>
(even though I have absolutely no idea how I'll be going forward)
Guest77519 has quit [Ping timeout: 268 seconds]
zpe has joined #ocaml
ollehar has joined #ocaml
Yoric has joined #ocaml
ocp has joined #ocaml
cago has joined #ocaml
Yoric has quit [Ping timeout: 248 seconds]
<ggole>
Hmm, it'd be nice if pattern matching worked on subsequences of arrays
<ggole>
Probably not common enough to be worth it though.
kaustuv has joined #ocaml
chrisdotcode_ has quit [Ping timeout: 276 seconds]
Neros has joined #ocaml
Kakadu has joined #ocaml
eikke has quit [Ping timeout: 276 seconds]
UncleVasya has quit [Remote host closed the connection]
eikke has joined #ocaml
hyperboreean has quit [Read error: Operation timed out]
gautamc has quit [Read error: Connection reset by peer]
UncleVasya has joined #ocaml
gautamc has joined #ocaml
ousado has joined #ocaml
ygrek has joined #ocaml
hyperboreean has joined #ocaml
csakatok_ has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 268 seconds]
cago has quit [Read error: Connection reset by peer]
ollehar has joined #ocaml
csakatoku has joined #ocaml
Neros has quit [Ping timeout: 246 seconds]
Neros has joined #ocaml
<gasche>
avsm: that doesn't directly answer your question about markdown parsers in OCaml, but both "mlorg" and "lambdoc" projects are still alive and provide parsers for markdown-like languages
<gasche>
mlorg is based on a rather modular parsing strategies (layers of parsing automatons); it is specialized to org-mode syntax but should be very easy to retarget to markdown
<avsm>
gasche: could you reply to the mail by any chance? i dont have time to look into this, but others do
<gasche>
and pandoc uses a more classic parsing approach (lexer with ulex, some context-dependent magic, parsing with menhir)
<gasche>
ok
mort___ has joined #ocaml
<avsm>
thanks!
<gasche>
I wasn't sure it was in-topic for wg-platform
<avsm>
infrastructure@
<gasche>
yeah
cago has joined #ocaml
<avsm>
now that several of the basic pieces are coming together, it's time to kick wg-platform up again, but not quite yet
* avsm
drowns in RWO comment
introom has quit [Remote host closed the connection]
zpe has quit [Remote host closed the connection]
<kaustuv>
gasche: thanks for the pointer to ecaml, but by the time I saw your message I had already re-implemented most of it...
<gasche>
:]
<gasche>
camlmix may be relevant as well
<kaustuv>
I basically just want a general purpose quote/antiquote mechanism in OCaml -- well one that doesn't use Camlp4
<gasche>
do you have a specific reason not to use Camlp4, as the Cow people do?
q66 has joined #ocaml
mika1 has quit [Quit: Leaving.]
<MarcWeber>
kaustuv: -ppx by 4.00.1 ?
<MarcWeber>
AFAIK its built into the compiler
toolslive has joined #ocaml
<gasche>
MarcWeber: kaustuv wants to have a document that has a lot of "text" (free-form stuff), plus a bit of OCaml inside
UncleVasya has quit [Remote host closed the connection]
mika1 has joined #ocaml
csakatoku has quit [Ping timeout: 256 seconds]
<MarcWeber>
I guess he has to write his own parser then.
<MarcWeber>
Like .lhs or such
Yoric has joined #ocaml
<MarcWeber>
lhs is literate haskell.
<gasche>
ppx is more about rewriting small parts of an OCaml program
<MarcWeber>
documentation is the default, haskell code must be quoted
<gasche>
those are rather different purposes
<gasche>
(and it's not clear how well -ppx can support antiquotations)
<gasche>
quotations+antiquotations is one part of Camlp4 that I actually like
<toolslive>
there are libraries for literate programming ocaml inside latex documents
<MarcWeber>
"A small tool to install annotation files to the library destination directory." from camlspotters README.
<MarcWeber>
Any idea how this works?
diml has quit [Ping timeout: 246 seconds]
UncleVasya has joined #ocaml
<toolslive>
voila. added ling to ocamlweb
<toolslive>
I wanted to ask: "is Lwt dead?"
<toolslive>
there are some indications it is: I've looked at the "real world OCaml" book and it's all Core based.
<companion_cube>
it's quite annoying, indeed
<companion_cube>
but I don't think Lwt is dead :)
<toolslive>
meanwhile, I sent a bug example to the mailing list (a really annoying one) and no reply whatsoever.
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
speredenn has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
ocp has quit [Quit: Leaving.]
zpe has quit [Read error: Connection reset by peer]
zpe_ has joined #ocaml
zpe_ has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
zpe has joined #ocaml
mcclurmc has quit [Quit: Leaving]
UncleVasya has quit [Remote host closed the connection]
<hcarty>
toolslive: I asked about Lwt's future after its main developer went to Jane Street and started working on Async. I was assured that Lwt is not going away.
<toolslive>
it would have been really nice if the Async and Lwt api's would be aligned a bit more, so functorizing over it would be trivial.
UncleVasya has joined #ocaml
thomasga has quit [Quit: Leaving.]
thomasga has joined #ocaml
<hcarty>
def-lkb: Is it possible to use merlin + vim + syntastic to jump to error locations? :lnext tells me that there is no location list.
mika1 has quit [Ping timeout: 240 seconds]
UncleVasya has quit [Read error: Connection reset by peer]
UncleVasya has joined #ocaml
Qrntz has joined #ocaml
<avsm>
Lwt isn't dead. It's "stable"
<avsm>
We picked Async for RWO because it's built very naturally on top of Core
<avsm>
I did try to squeeze in Lwt, but it's simply too difficult to talk about multiple frameworks in one book
<eikke>
is there a reason to keep both async & lwt around? does one offer things the other doesnt?
<avsm>
for a start, they're both built by different people, so it's not like anyone decides which lives and which dies.
<avsm>
and they're quite different in style: most obviously, Async requires Core, whereas Lwt slots into existing code well
<avsm>
Async has much more conservative and explicit context switching
<avsm>
whereas Lwt.wakeup is fast but "dangerous"
osa1_ has joined #ocaml
<toolslive>
we ran into problems with Lwt_unix.sleep ....
<hcarty>
toolslive: What problems?
<toolslive>
basically you don't know when you'll be awake again.
<toolslive>
we have example code where you go to sleep for 0.1s and wake up 7s later.
<hcarty>
Ah, that's unfortunate. Is the example available somewhere to look at?
<gasche>
eikke: another interesting question is "is there a reason to keep both Core and Batteries around?"
<toolslive>
I sent such an example to the ocsigen mailing list on Sunday, but no response yet.
<gasche>
toolslive: you should ping Jérémie if you suspect your problem went through unnoticed
<eikke>
gasche: same thing indeed :) (although we currently use neither, but when using async one needs to use some core as well I guess)
<gasche>
I think that Core is technically a good library, but I'm nervous at the idea of resting an entire community open source production on a company-directed standard library project
<hcarty>
gasche: I've wondered that too. I think there is, but I'm not sure if the cost is worth it.
<hcarty>
gasche: That's my concern as well, from a user perspective.
<hcarty>
The development/review/etc. process is closed. The library itself seems nice, but the development seems more like regular code dumps of someone's internal tool than a community project.
<adrien_oww>
(and you may argue the development process isn't very open too)
<gasche>
adrien_oww: true, but I don't think there is any ill will on the JS side to accept reasonable patches from anyone
<eikke>
accepting patches is just a small part of dev process :)
<adrien_oww>
I'm far from contributing to either Core or Batteries; I haven't tried
<hcarty>
toolslive: waste_cycles will block anything else from running.
<hcarty>
toolslive: If I'm reading the code correctly.
<adrien_oww>
and I'm going to be biaised because Batteries people are on IRC
<toolslive>
hcarty: yes it does. but only for a small amount of time.
<adrien_oww>
but it seems Core is further away from the community
<toolslive>
there is nothing there that blocks longer than 0.7s.
<gasche>
I'm a bit stressed at the idea of having two would-be standard library developped in parallel
<avsm>
there's one thing that drives a dev process more than anything else. only one thing.
<gasche>
and avsm's RWO is only going to make matter worse on this front
<avsm>
users that care...
<toolslive>
I've seen the Lwt.pick there last for as much as 7s
<gasche>
on the other hand, some other language communities have managed several having "basic block" libraries just fine
<avsm>
Core has more actual industrial users than any other replace stdlib
<avsm>
(Citrix is moving to it too, slowly)
<avsm>
but it takes forever to switch a large, critical codebase
<avsm>
so look at the trend, not the now
<avsm>
I think JSC's doing a great job of opening it up carefully
<avsm>
last year, we didnt have: OPAM, weekly drops of Core, Github mirrors, and all the new libs: Textutils, Jenga, Patdiff, etc
<avsm>
and next year, it's going to be better.
<gasche>
hm
<hcarty>
toolslive: Is that too surprising? Each of the waste_cycles loops could end up running sequentially.
<avsm>
(i say this as one of the first external users of Core. it was painful in the beginning)
<kaustuv>
I tried to use Core a number of times, but the ridiculously large number of dependencies is a bit offputting. Some of the people I expect to use my software are not competent enough to use opam.
<avsm>
but most importantly, the base platform tools are agnostic to the standard library
<kaustuv>
So I would prefer if Batteries hung around as a lightweight alternative to Core
<avsm>
kaustuv: i'm afraid we can't really help you there. first, people complain when it was one big blob. then they complain when it isn't. answer: ignore them
pootler has joined #ocaml
<gasche>
it doesn't take a lot of work to maintain Batteries, so I expect it to still be around in the future as long as users depend on it
<avsm>
(Yaron and I ran a comical CUFP 2010 tutorial where 1 hour was spent installing manual dependencies by all in there)
<gasche>
(and it can evolve too)
<flux>
there should be a way to take a list of OPAM packages and bundle them conveniently with your source :)
<kaustuv>
The sad fact is that some of these people can't be ignored, eg. if they are paying your salary. (Fortunately I am out of that phase of life now.)
<toolslive>
hcarty I've added output of a sample run to the gist.
<flux>
how amazing would it be to just give your project.tar.gz to some non-ocamler, and they can just make && ./execute
<flux>
possibly ./configure, they know how to do that
<avsm>
anyway kaustuv, it would be easy to serialize opam deps into a tarball
<kaustuv>
+1 for an OCaml Platform release.
<gasche>
avsm: however, I'm not sure looking at what the industrial users are help to pick a standard free software library for a language community
<hcarty>
toolslive: I tried running it and got times ranging from >10s to <1s. But again I'm not terribly surprised. If each thread's waste_cycles call ends up running sequentially then it could easily take 7+ seconds.
<toolslive>
should the sleep have a bit more priority?
<eikke>
flux: "go get ..." (minus the romantic view about stability & api consistency those people seem to have)
<gasche>
industrial use brings technical quality
<avsm>
(it's an interesting sidenote gasche, that Core is Apache2, whereas the OCaml stdlib is less free)
<gasche>
but I also like having a very open governance model, and not being afraid to break things once in a while
<avsm>
Core breaks its APIs all the time. the latter doesn't follow the former
<hcarty>
toolslive: I think the waste_cycles loop would need to be made cooperative.
<gasche>
indeed, those are independent
<avsm>
and honestly, I think open governance is a dumb idea for a nascent project
<kaustuv>
Inria should just swallow their pride and re-lices OCaml under BSD or the CeCILL equivalent.
<gasche>
and I also think API changes could be mostly solved by better tooling
<toolslive>
hcarty: that thing is cooperative. there are plenty of binds there....
<toolslive>
it's interleaved with reading from /dev/zero
<hcarty>
toolslive: Not in waste_cycles itself
<toolslive>
so?
<toolslive>
".wasting_cycles took: 0.618455"
<hcarty>
So you can end up with 12 of those running sequentially
<toolslive>
so timeouts don't work....
<hcarty>
They only work for cooperative code
<toolslive>
but IT is cooperative code.
<hcarty>
Again, waste_cycles is not cooperative
<toolslive>
wel, there are always going to be small pieces that are not cooperative.
<toolslive>
well, there are always going to be small pieces that are not cooperative.
<toolslive>
as long as you have plenty of binds in between the other 'threads' should not starve.
_andre has joined #ocaml
<toolslive>
it seems to me the scheduler gives preference to the make_loop() threads and starves the sleep in the pick.
<flux>
soo, any news on ocaml multicore?
<hcarty>
My understanding is that those pieces need to be modified to be cooperative or spun off into Lwt_preemptive threads.
<gasche>
flux: I don't think OCamlLabs have had a public progress update since april
<toolslive>
so starting from how many cycles should I do that?
<gasche>
but there was one from OCamlPro recently
<hcarty>
flux: There was something in the most recent ocamlpro update
<adrien_oww>
ping avsm :P
csakatoku has quit [Remote host closed the connection]
<toolslive>
let y = 1+1 in ... also isn't that cooperative....
<gasche>
adrien_oww: I already did but I think avsm is busy with enough things to be write the activity report
<hcarty>
toolslive: That's a good question that I don't know the answer to. I expect it's <0.1 seconds though, possibly by a few orders of magnitude.
<gasche>
I'm quite fond of these reports personally, so I think people should insist on writing them monthly
<avsm>
ours is up
<gasche>
ah, good
<avsm>
nothing much on multicore, it's waiting on the ocamlpro preemptive patchset to come in
<gasche>
avsm: is the "preemptive patchset" what Luca is working on (runtime re-entrancy), or yet something else?
<flux>
a mix of real threads, lwt-threads and a thing like apple's grand central dispatch could be interesting.
<hcarty>
toolslive: I agree that the result is surprising, but it seems to be consistent with how I understand Lwt's scheduling.
<avsm>
yes
* avsm
tunes out of irc for a while to do some work
<kaustuv>
OCamlProLabs should hire someone just to hang around on IRC
<eikke>
flux: basically you want a threadpool which runs lwt threads using local & work-stealing queues
ygrek has quit [Ping timeout: 264 seconds]
<gasche>
kaustuv: I don't think IRC is the right place to put information
<gasche>
it is unstructured, hard to archive, etc.
<gasche>
monthly blog posts are much better
<flux>
eikke, yes, please :)
<Kakadu>
flux: hi!
<gasche>
avsm: I thought you were going your own thread-local route; good to know that you're working together
<flux>
kakadu, hello :)
<flux>
kakadu, sorry, no news!
<Kakadu>
=)
<gasche>
avsm: how come your monthly reports are not on the OCaml Planet?
UncleVasya has quit [Remote host closed the connection]
<toolslive>
hcarty: spinning waste_cycles off in an Lwt_preemptive detach helps 'a bit' the sleep of 0.1s awakes only 3s later.
mcclurmc has joined #ocaml
<toolslive>
I have no problems with a bit of variance, or a minimum granularity for the sleep.... but currently it is not very useful.
cago has quit [Quit: Leaving.]
cago1 has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
mika1 has joined #ocaml
<gasche>
will RWO remain freely available online after publication?
UncleVasya has joined #ocaml
ollehar has joined #ocaml
breakds has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
ollehar has joined #ocaml
ocp has joined #ocaml
<gasche>
avsm: on the development ocamlot website, what does 4.01 and 4.02 correspond to? is 4.01 version/4.01 and 4.02 trunk?
<gasche>
ocp: I have a small question about the last OCamlPro activity report, the exception analysis part
<ocp>
gasche: yes ?
<gasche>
how is defunctionalization going to help for exception analysis
<gasche>
?
dsheets has joined #ocaml
<gasche>
if you defunctionalize, the code of each closure gets moved to a branch of a big match..with case in one "apply" function
<gasche>
so either your exception analysis starts thinking that this apply function may raise basically any exception
<hcarty>
toolslive: Can you update the gist? That does seem much too long.
<ocp>
there are several ways to defunctionalize
<gasche>
or your analysis is fine-grained enough to depend on the tag
<gasche>
which looks just as hard as a higher-order analysis
<gasche>
dsheets: on the development ocamlot website, what does 4.01 and 4.02 correspond to? is 4.01 version/4.01 and 4.02 trunk?
<ocp>
gasche: I won't spoil it, wait for next episodes
<gasche>
hm ok
<dsheets>
gasche, 4.01 is 4.01 branch and 4.02 is trunk with frame pointers, iirc
<dsheets>
gasche, you can see the specific version at the bottom of a task page
<gasche>
maybe a more precise labelling for 4.02 would be helpful (and also it could be stable when version/4.02 is branched... someday)
<gasche>
ok, thanks
<dsheets>
yes, we also need a nice way to surface configure params
ocp has quit [Quit: Leaving.]
<toolslive>
hcarty: I've put up my new version (with Lwt_preemptive.detach)
<gasche>
dsheets: I was also wondering whether/how you envision monitoring trunk versions of various packages
<dsheets>
something like gcc -v which isn't presently available afaik?
<dsheets>
gasche, we want to test opam revs and compiler revs for now
<dsheets>
no metadata exists atm for upstream repos but i think it is planned
<gasche>
because you don't have enough CPU power to do more?
<gasche>
ah
<dsheets>
my current thinking is that all testing happens at acceptance/opam distribution time
<dsheets>
but our test loop latency is still far too high and not automated enough for this
<gasche>
dsheets: but we could have a "opam-next" (by analogy with linux-next) repository where people would daily upload developmentish version of their packages to get CI feedback?
UncleVasya has quit [Remote host closed the connection]
<gasche>
the problem with testing at acceptance time is that the feedback loop for people monitoring failures is a bit high: if I notice my package fails on OpenBSD, I have to make a new release to fix it?
<dsheets>
sure that's a possibility. another option is to provide a network endpoint to ping with a repo ref
<adrien_oww>
I'd say roughly the same with OCaml's CI :D
<hcarty>
toolslive: Thanks. I'll take a look later. I don't know that I'll be able to offer a solution but I'd like to know what the underlying cause is.
<gasche>
adrien_oww: there is a difference between "a new SVN commit" and "a new release on the official OPAM repository", isn't it?
cago1 has quit [Ping timeout: 256 seconds]
<adrien_oww>
gasche: the point is similar: you have to inflict your testing to others
<gasche>
that is the very principle of centralized CI, yes
<adrien_oww>
you cannot just commit, trigger the tests, go to bed and leave for a week
<dsheets>
gasche, depends on what you judge to be a release... right now JSC cuts 109.3x.00-rcX until acceptance when they release 109.3x.00
cago has joined #ocaml
<dsheets>
not ideal, of course, but better than nothing
<dsheets>
the next step is to reduce the loop latency and increase the test granularity
<gasche>
dsheets: requesting a CI build with a repo reference would be ideal
<gasche>
adrien_oww: you should be able to do that now
demonimin_ has joined #ocaml
<adrien_oww>
oh? that's be awesome
<adrien_oww>
I'll have to check it but I believe I don't have everything on the CI yet (far from it)
<gasche>
dsheets: my question came from wondering how upstream projects should react in case of being noticed of a CI failure
<dsheets>
yes, this also begins to put pressure on policy, logging, monitoring. opam releases are rather more expensive than http requests right now so this lets us focus on the crucial workflow
<dsheets>
of course, you're right and in several months we should be offering this
<gasche>
indeed, I don't want to push too far :] the development version already looks promising
demonimin has quit [Read error: Operation timed out]
<dsheets>
gasche, i wonder the same thing :-P right now it happens in the github pull request with an @ mention if the maintainer has an acct
<dsheets>
gasche, no worries at all, i encourage you to bring me any and all feature ideas and issues you have
<gasche>
at IRILL there is an intern working on displaying static analysis results done on the source versions of all packages in the Debian central apt repository
<gasche>
I had the same question there: what's the workflow for upstream devs when they get a failure report?
<gasche>
I don't think they really have a plan yet
<dsheets>
i could envision an email with the report to a maintainer containing a link to the report page with the capability to retest
<dsheets>
do you know if ocaml has anything similar to gcc's "Target" and "Configured with" when doing $ gcc -v ?
<dsheets>
right now i use ocamlc -version and uname which isn't the best
<gasche>
dsheets: try "ocamlc -config"
<dsheets>
brilliant, thanks... shoulda found that myself
<gasche>
if something is missing from there, you should file a feature request on the bugtracker
<adrien_oww>
if it's used somewhere in ocaml's configuration, it's there
<adrien_oww>
and adding something to that is actually fun
<dsheets>
it would appear that the entirety of this output would be helpful when remote debugging, then?
<adrien_oww>
or configure's output or config/Makefile
<adrien_oww>
(when building ocaml)
<dsheets>
if you have -config, do you gain more from the build outputs? every test compiler is specifically built but nothing from the build is retained
<adrien_oww>
I have 4.00.1 and I know that trunk has many more entries there but it really seems there are less things than in configure
<adrien_oww>
it's limited by a .mli
<adrien_oww>
but it really depends on the kind of issues you're facing
mcclurmc has quit [Ping timeout: 246 seconds]
osa1_ has quit [Quit: Konversation terminated!]
osa1 has joined #ocaml
<gasche>
adrien_oww: I think it depends on the whose end of the pipe you're trying to fix
<gasche>
if the test failure was introduced by a new bleeding-edge version of the compiler that changes some behavior or miscompiles some stuff, then you'll want to be precise in the configuration part
<gasche>
if it is the new release of the tested OPAM package that broke stuff, you probably won't start looking at the OCaml version
<gasche>
(right now I'm not sure if ocamlot made a conscious choice of which side to prefer, or if it is supposed to care for both)
<adrien_oww>
yep, agreed =)
<dsheets>
it is supposed to care about both but perhaps in different contexts
<dsheets>
the cost of collection is so small that we should probably collect it in the off chance it is important but usually hide it behind some uri
<dsheets>
s/uri/ui/
UncleVasya has joined #ocaml
<gasche>
indeed
<gasche>
the "which end are we looking at" aspect will be more important for, e.g., monitoring decisions
<dsheets>
gasche, could you elaborate on "monitoring decisions"?
<gasche>
I'm not sure Frama-C developers want to be notified each time a change in the OCaml trunk upstream breaks compilation of Frama-C
<gasche>
on the contrary, OCaml developers probably want to know that
<gasche>
but actually, if they decide that this is not an upstream bug, but a "feature" of the next release, they may want to in turn notify the Frama-C devs so they can make their code next-release-ready
<gasche>
(I'm talking from memory of a very real such scenario between 3.12 and 4.00)
<gasche>
so I'd say that, by default, (only) package developers (and other people having subscribed) should be notified when a package breaks on a stable release
<gasche>
and only branch-maintainers should be notified when an unstable-branch breaks a package
<gasche>
with an option to pass the notification to package-developers
<gasche>
(package-maintainers may not be OCaml upstream, but eg. Fabrice for the -with-frame-pointer branch, etc.)
<dsheets>
gasche, yes, the policy around notification and triage is rather subtle to target the right audience
<gasche>
(I guess a summary of that would be: if you want to help both package devs and language devs, you should have metadata to tag in each test environment which part is "stable" and which part is "probably the faulty one")
<dsheets>
right now, there is no notification except humans noticing and commenting in pull requests
<gasche>
I want my notifications :]
<dsheets>
gasche, yes, this is planned in the form of experimental builds
<dsheets>
and yes, there will be proper non-proprietary notifications ;-)
ousado has quit [Ping timeout: 264 seconds]
<gasche>
(indeed I impliticly meant "email notifications")
<gasche>
(though a syndication feed would probably be enough if it's too much work to set-up a mailing service for that)
<dsheets>
i think both are appropriate and within reach
<dsheets>
a feed probably sooner
Drup has joined #ocaml
demonimin_ is now known as demonimin
ousado has joined #ocaml
ousado has quit [Ping timeout: 246 seconds]
cago1 has joined #ocaml
ousado has joined #ocaml
cago has quit [Ping timeout: 246 seconds]
mcclurmc has joined #ocaml
ygrek has joined #ocaml
Simn is now known as Simn|gone
mort___ has quit [Remote host closed the connection]
<hcarty>
toolslive: That version finishes each test in (slightly more than) 0.1 seconds
<hcarty>
It's more of less fully cooperative-ized. I'm not sure why the detach approach didn't work though.
<toolslive>
this I cannot do in our code.
<gasche>
ollehar: just answered your SO question, with possibly more information than you wanted
<ollehar>
gasche: nice, thanks!
<hcarty>
toolslive: Then something around detach or working with separate processes may be necessary.
<toolslive>
remember: it's a rather artificial example drawn from a rather large codebase. the waste_cycles there is actually a call to a 3rd party compression library.
<gasche>
hcarty: I would ten to agree with toolslive's viewpoint that if sub-0.1 monolithic computations result in order-of-magnitude overseelping time, it's probably a defect in Lwt's scheduling technique
<gasche>
*tend
<gasche>
hm
<gasche>
or were the initial times for waste_cycles sub-second only?
<gasche>
in any case, toolslive, you should ping Jérémie about this if you want to speed up the process of getting an answer
<toolslive>
the whole waste_cycles block (in my original example) takes about 0.6s on my machine.
BlankVerse has joined #ocaml
<toolslive>
what's the preferred way of 'pinging Jeremie'
ygrek has quit [Remote host closed the connection]
ygrek has joined #ocaml
<toolslive>
Like I said before, I can live with the other threads living for a while longer, I can also live with some variance or coarse granularity....
<toolslive>
btw, Lwt has changed its scheduling policy in the past. it used to be "straight ahead".
hkBst has quit [Quit: Konversation terminated!]
<hcarty>
gasche, toolslive: I agree at this point. >0.1s seconds makes sense in the detach case but not 7s.
<toolslive>
I'll send a mail to Jeremie, see what his opinion is on this.
<thizanne>
toolslive: what do you mean by « in the past » ?
<gasche>
to satisfy user requests, I presume
<toolslive>
Lwt < 2.3
<thizanne>
I tried Lwt two months ago iirc and it seemed to be « straight ahead »
<toolslive>
a >>= b
<gasche>
BlankVerse: it's "fun" not "fn"
<toolslive>
if a finished then it would prefer to go into the b path
<toolslive>
and not switch to somewhere else.
<gasche>
but this is a good example of shitty error message
introom has quit [Remote host closed the connection]
BlankVerse has quit [Quit: leaving]
introom has joined #ocaml
zpe has quit [Remote host closed the connection]
<gasche>
hcarty: do you have a script to automatically monitor all mantis issues?
<gasche>
I ask because right know I receive an email for each new bug, and have to make a conscious decision to monitor or not; I'd rather have them all monitored by default
<gasche>
(which some higher levels of privilege can do, I think Jonathan is in monitor-all, but let's not get into the details of the ergonomy of any bugtracker software)
<hcarty>
gasche: Not all of them, just the interesting ones :-)
<hcarty>
The interesting ones I see anyway. It's a nice way to track what's going on in the language without being in the inner circle.
<hcarty>
gasche: Speaking of development - is -ppx going to be in 4.01.x in some form or is it being held until later?
<gasche>
to my personal regret, it's going to be in 4.01
<gasche>
I think it would be better to have extension-points under some form, or nothing at all
<gasche>
(because right now the only way to use -ppx is to subvert existing valid OCaml syntax, a practice I loathe)
<hcarty>
gasche: Ah, I thought the two were tied.
<gasche>
-ppx went in trunk, but the more ambitious extension_points is a separate branch
<gasche>
(i'd also have liked to have the nice cleanups of the asttree by Alain merged in trunk instead of the branch, but well)
<hcarty>
It's significantly less interesting without extension-points. I was hoping for fun things like a let-finally syntax and camlp4-free lwt support.
<gasche>
so not yet
<gasche>
or under forms I would take care to shot down, from fear they would actually get users
<gasche>
(eg. wmeyer's monadic syntax hack)
<gasche>
(note that none of what I'm saying right now require membership in those cloudy "inner circles", I got that much information from just following the SVN commits)
<toolslive>
ah. Jeremie's on vacation.....
<hcarty>
gasche: I've been tempted to track SVN commits automatically (RSS or otherwise) but I haven't taken the time to set that up yet.
<hcarty>
But I do go browse around now and then for fun :-)
<ygrek>
down to the ground - why the following is not accepted : class z = let module A = String in object end;; ?
<ygrek>
please :)
raichoo has quit [Quit: leaving]
<hcarty>
gasche: The spell checking is a nice addition in 4.01 - thank you for that
zpe has joined #ocaml
<hcarty>
ygrek: That seems like it's worth asking about on the mailing list
<hcarty>
ygrek: Maybe not so useful, but this does work: class z = let a = (module String : String_sig) in object method length s = let module S = (val a) in S.length s end;;
<ygrek>
oh, the idea is to shorten the code, not the other way round :))
<ygrek>
ok, let the list handle it :)
mort___ has quit [Remote host closed the connection]
mort___ has joined #ocaml
zpe has quit [Ping timeout: 256 seconds]
Neros has quit [Ping timeout: 240 seconds]
<gasche>
adrien_oww, wmeyer: Gagallium just published a blog post in your honor
UncleVasya has quit [Ping timeout: 256 seconds]
ygrek has quit [Ping timeout: 268 seconds]
Yoric has joined #ocaml
chrisdotcode has joined #ocaml
<pippijn>
# (::);;
<pippijn>
Error: Syntax error
<pippijn>
is :: not a regular operator?
<Drup>
I think it's a reserved keyword
<pippijn>
so is lsr, isn't it?
tane has joined #ocaml
bkpt has quit [Ping timeout: 248 seconds]
<rgrinberg>
that's strange, is it because (::) can be pattern matched on?
<Drup>
pippijn: yes
<pippijn>
oh
<pippijn>
rgrinberg: maybe..
<pippijn>
BatList has a cons function
<thizanne>
pippijn: lsr is an operator but not a reerved keyword
<pippijn>
ok
<thizanne>
but :: is a constructor, not an operator
<pippijn>
ah
<pippijn>
I see
<pippijn>
makes sense
<pippijn>
too bad ocaml constructors can't be curried
<rgrinberg>
pippijn: fields/variants lib
<thizanne>
neither curried nor used as functions
ontologiae_ has quit [Read error: Operation timed out]
<Drup>
thizanne: it's also a reserved keyword
UncleVasya has joined #ocaml
zpe has joined #ocaml
Yoric has quit [Ping timeout: 256 seconds]
mort___ has quit [Ping timeout: 276 seconds]
bkpt has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
thomasga has quit [Quit: Leaving.]
<toolslive>
yes, removing the difference between constructors and functions would be an improvement.
<ggole>
It'd be nice to be able to specify an actual function, too
<ggole>
Rather than have "smart constructors"
UncleVasya has quit [Remote host closed the connection]
speredenn has quit [Quit: Leaving]
olafurw has quit [Ping timeout: 264 seconds]
diml has joined #ocaml
introom has quit [Remote host closed the connection]
mort___ has joined #ocaml
cago has quit [Ping timeout: 252 seconds]
Simn|gone is now known as Simn
raichoo has joined #ocaml
UncleVasya has joined #ocaml
ontologiae_ has joined #ocaml
darkf has quit [Quit: lmao]
osnr has quit [Quit: Leaving.]
UncleVasya has quit [Remote host closed the connection]
UncleVasya has joined #ocaml
zpe has joined #ocaml
ontologiae_ has quit [Ping timeout: 240 seconds]
zpe has quit [Ping timeout: 252 seconds]
mort___ has quit [Quit: Leaving.]
Neros has joined #ocaml
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
cago has joined #ocaml
emmanuelux has joined #ocaml
cago has quit [Ping timeout: 256 seconds]
ttamttam has quit [Quit: ttamttam]
mcclurmc has quit [Ping timeout: 240 seconds]
mika1 has quit [Quit: Leaving.]
zpe has joined #ocaml
beckerb has quit [Ping timeout: 245 seconds]
q66 has quit [Quit: Leaving]
<wmeyer>
gasche: :-) thanks. I think we should also include MSVC mk flavor
zpe has quit [Ping timeout: 256 seconds]
orbitz has quit [Ping timeout: 260 seconds]
orbitz has joined #ocaml
Drup has quit [Ping timeout: 256 seconds]
Kakadu has quit []
UncleVasya has quit [Ping timeout: 256 seconds]
osnr has quit [Quit: Leaving.]
tane has quit [Quit: Verlassend]
UncleVasya has joined #ocaml
<wmeyer>
adrien: ping
ollehar1 has joined #ocaml
zpe has joined #ocaml
q66 has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
ollehar1 has quit [Ping timeout: 256 seconds]
zpe has quit [Ping timeout: 256 seconds]
UncleVasya has quit [Remote host closed the connection]
zpe has joined #ocaml
ggole has quit []
zpe has quit [Ping timeout: 246 seconds]
mehdid_ is now known as mehdid
<wmeyer>
you could do it with fan or camlp4 easily, except you have to use them consistently
ttamttam has joined #ocaml
osnr has joined #ocaml
osnr has quit [Changing host]
osnr has joined #ocaml
malo has joined #ocaml
dezzy has quit [Quit: leaving]
dezzy has joined #ocaml
dezzy has quit [Client Quit]
dezzy has joined #ocaml
tane has joined #ocaml
toolslive has quit [Quit: Leaving]
Kakadu has joined #ocaml
mlh has quit [Read error: Connection reset by peer]
mlh has joined #ocaml
pootler has quit [Quit: leaving]
osa1 has quit [Ping timeout: 264 seconds]
nlucaroni has joined #ocaml
beckerb has joined #ocaml
ttamttam has quit [Quit: ttamttam]
beckerb has quit [Ping timeout: 245 seconds]
ttamttam has joined #ocaml
thomasga1 has joined #ocaml
ollehar has joined #ocaml
UncleVasya has joined #ocaml
<wmeyer>
adrien: hi
<companion_cube>
hi wmeyer
<companion_cube>
they must be at the OUPS meeting
breakds has joined #ocaml
<adrien>
hi wmeyer
<adrien>
just got back
<adrien>
mostly because I need to go to bed early ;-)
<wmeyer>
oh OUPS great, I'd like to be there, thanks companion_cube
<wmeyer>
adrien: no problem, the good news you can grab along with your pillow is that tests pass ;-) congratulations
<adrien>
:-)
<wmeyer>
so see you tomorrow, sleep well :-)
<adrien>
that will sure help me sleep :P
<adrien>
thanks
<adrien>
about ocamlbuild: it installs a file named "config.sh"
<wmeyer>
no worry, waiting for the rest of patches
<wmeyer>
it does many things ...
<adrien>
do you know what it is used for? is it required?
<adrien>
ah
<adrien>
I'd maybe make its installation conditional but...
<wmeyer>
we want to remove this cruft from the repo, and perhaps use makefile even for ocamlbuild and possibly camlp4, at least no bootstrap of ocamlbuild
<adrien>
that's the behaviour I was relying on
<adrien>
but since it's not there yet, everything broke :P
<wmeyer>
good, at least you are the first person using this :-)
<adrien>
it's still a lot of work?
<adrien>
well, using it but with ocamlbuild's build disabled
<wmeyer>
I can try to spend some time today actually
<adrien>
I won't have much free time until the end of the week
<adrien>
tomorrow: eat and drink
<adrien>
saturday: eat, drink, watch bad movies
<adrien>
another day: eat and drink
<adrien>
see, a very busy schedule :D
<wmeyer>
Ok, let's just do it when you will be available
<dsheets>
i'm eating and drinking right now
<wmeyer>
then I will go to have arest today
<wmeyer>
enjoy your time
<wmeyer>
(food and drinks)
<dsheets>
wmeyer, where is this jenkins bot?
<wmeyer>
dsheets: it's on INRIA server
<adrien>
if you do something, ping me and I'll test it but don't hurry too much
<dsheets>
not public?
<adrien>
ah, crap
<wmeyer>
dsheets: AFAIK not
_andre has quit [Quit: leaving]
<adrien>
I wanted to take my laptop with me at oups and ask gasche how much was missing from my interface of the CI
<wmeyer>
adrien: ok, granted!
<dsheets>
wmeyer, what does it test?
<wmeyer>
dsheets: almost every configuration we support, {linux, cygwin, mingw, msvc, open}{32,64}
<wmeyer>
dsheets: it builds and runs the testsuite
<dsheets>
cooool. for the compiler + distribution?
pkrnj has joined #ocaml
<wmeyer>
all the tests in the testsuite/
<wmeyer>
I think ocamlbuild tests has to be added :-)
<wmeyer>
s/has/have/
<adrien>
wmeyer: and btw, is ocamlbuild_noboot a "target" for the next release?
<wmeyer>
will be, as it appears useful :-)
<adrien>
I could also add a small kludge, knowing it's going to go away very soon
<wmeyer>
likewise cross compilation patches if we have enough time testing them, I will merge them
<adrien>
the kludge would be as simple as: cp foo/config.sh $somewhere || true (add the '|| true')
<adrien>
or something similar
<wmeyer>
dsheets: are you coming to makespace this weekend? I might be there, I will try to stay away from Coq :-)
<dsheets>
perhaps... still recovering from head cold i came down with friday night
<wmeyer>
I see, no good, it's always bad thing to get a cold, I suffered from that last week, that prevented me in general of doing anything useful
<wmeyer>
adrien: your choice; but remember, that we don't want to overcomplicate things
nlucaroni has quit [Quit: leaving]
<wmeyer>
I am on it anyway, the noboot flag
<adrien>
wmeyer: I'm wondering how likely it is that this config.sh doesn't get created and the whole build process finishes
<adrien>
well, I could start by adding a configure flag -ocamlbuild-noboot
<wmeyer>
adrien: no idea, it's magic, I will try to build ocamlbuild with simple makefile
<adrien>
which would be implied by -no-ocamlbuild
<adrien>
wmeyer: hahaha :P
<adrien>
that was my feeling too
<adrien>
ok, I think I see how I'll do things (fast, simple, slightly dirty but still reliable)
<wmeyer>
adrien: if you like to trip over on it feel free, but I have some time to do it
<adrien>
for the configure flags, I've been adding 4 of them so I can add a fifth :-)
<wmeyer>
so it looks like perfect time to do it for me
<wmeyer>
remember in the end we want to simplify build, but extending available flags is not too bad in principle
<adrien>
I see these flags as a first step before removal of the corresponding components
<adrien>
we'll see the details later I guess
<wmeyer>
if we want to remove; certainly I don't think I want to remove the ocamlbuild from the distributoin
raichoo has quit [Quit: leaving]
<adrien>
all I want is that "make world.opt" doesn't build ocamlbuild
<adrien>
ocamlbuild could be in a separate download, in the same with the different make rule, or anything, everything's fine to me
<wmeyer>
yes, that would be good. But my perception is that we want it to be built always
<adrien>
the only thing is that I don't want to try to build binaries that make little sense for cross-compilers
<wmeyer>
Ok, I think about people at the moment, disablbing ocamlbuild completely
<wmeyer>
but maybe that's my fear (which is not too strong at the moment BTW) :-)
<adrien>
it's needed by so many things today, it can't be skipped
<pippijn>
my god, omake is a pain
<adrien>
and while I'm very unhappy with the current ocamlbuild, the recent changes and the planned ones make me much happier
<wmeyer>
adrien: I fully agree!
<pippijn>
dynamic scoping.. ugh
<adrien>
pippijn: my feeling was that it's too complicated
<pippijn>
adrien: it's like coq
<pippijn>
it's really cool, but it's really hard to get things done in
<pippijn>
when you do it right, you have something beautiful
<wmeyer>
we should say: "Write in Caml" ! no?
<adrien>
my sound output on the laptop burnt away ='(
<adrien>
so I'm going to play it loud enough in the living room for the neighbours to here it :P
<whitequark>
adrien: that sounds like a nontrivial accomplishment
<whitequark>
sure it's not just mechanical?
<pippijn>
adrien: what recent and planned changes?
<wmeyer>
whitequark: chromebooks can burn speakers during installation of ubuntu for instance, have fun!
<whitequark>
wmeyer: I'm aware of that and it doesn't apply to common x86 notebooks
<whitequark>
that's ARM policy issues.
<wmeyer>
whitequark: well, I don't know much about our policies, but yes, it can be painful to protect hard the IP
<whitequark>
(x86 drivers/hw commonly assume that user can tweak stuff and is a complete moron; arm ones don't (yet).)
<adrien>
wmeyer: woah...
<adrien>
whitequark: before
<adrien>
sound works
<adrien>
whitequark: after
<adrien>
sound doesn't work
<adrien>
whitequark: between
<adrien>
smells like burnt HW
<whitequark>
fair enough
<whitequark>
still a nontrivial accomplishment :D
* wmeyer
logged through ssh to adrien's computer and enabled alsa
<whitequark>
by standard, it has to detect overload conditions
<whitequark>
oh wait
<whitequark>
wmeyer: so does he have a chromebook?
<wmeyer>
series 3 which burns speakers: ARM
* whitequark
nods
<adrien>
pippijn: first, making the build in the ocaml sources saner
<adrien>
and I shouldn't have said "planned" but "possible"
<adrien>
there were ideas like making it a library, or integrating it better with an "ocamlfind ocamlbuild" command
<adrien>
and if we get plugin*s*...
<wmeyer>
adrien: to be clear, I like this beautiful song, but please stay with OCaml :-)
<adrien>
whitequark: I guess I had a bug (a real one) get in my laptop or something like that
<adrien>
wmeyer: heheh
<pippijn>
adrien: sounds good
<adrien>
I do enough C during the day
<pippijn>
when it's a library, I might actually use it again
<adrien>
click on a button for a media which isn't present? segfault!
<adrien>
strdup(NULL)? segfault!
<wmeyer>
adrien: :-)
<adrien>
use the program for hours? mysterious slowdown which is likely memory fragmentation
<whitequark>
adrien: more like metal junk
<adrien>
whitequark: could be anythin but I guess there was a debris that short-circuited the hw
<whitequark>
the voltage's really not enough to burn a bug there, much less kill the circuit itself
<whitequark>
well
<whitequark>
insects are known for not being conductive
<adrien>
just a guess but I expect there was something that got in
* whitequark
nods
<wmeyer>
adrien: I had my old laptop, still have it, it's close to bed, and have limited usage
<wmeyer>
but I loved it, when it was working
Kakadu has quit []
<pippijn>
simple things are hard with omake
<pippijn>
like putting sources into subdirs
<wmeyer>
pippijn: but maybe hard things are simple
<wmeyer>
that's the deal
<pippijn>
yeah
<pippijn>
also, it's very robust
<pippijn>
it's hard to cheat
<wmeyer>
yes it seems like omake controls the user
<pippijn>
in make, you can hack and cheat around everything
<wmeyer>
how true is that with other builds systems, but cmake accelerated many projects
<pippijn>
in the end, you get something that works but is unmaintainable
<pippijn>
I like omake
<pippijn>
but it's a pain :)
<wmeyer>
or think about other people that need to maintain
<adrien>
wmeyer: I now expect my laptops to last only a few years; after all they're traveling a lot
<adrien>
good night
<pippijn>
and there are no resources about it I can find besides the manual
<pippijn>
and nobody can answer my questions
<wmeyer>
i can say; i don;t want traditional build systems anymore; but makefile is fine and scales well up to complicated projects; where ocamlbuild not
<wmeyer>
adrien: night!
<pippijn>
good night adrien
gautamc has quit [Read error: Connection reset by peer]
<wmeyer>
pippijn: true
<pippijn>
I think a normal user can copy/paste stuff from my rules files and make their own rules
<pippijn>
but constructing it from scratch is not easy
<pippijn>
but I guess I have quite high demands, too
<pippijn>
for example, I want to guess the language for a target
<wmeyer>
pippijn: there is a lot going on in omake
<pippijn>
I don't want the user to say "this is an ocaml program"
<pippijn>
that should be implicit (and overridable)
<pippijn>
if there are ocaml sources, then it is an ocaml target
<pippijn>
if there are C++ ones, we need the C++ linker
<wmeyer>
you don't have high demand, you have regural requirments towards sane build system
gautamc has joined #ocaml
<wmeyer>
I don't know how it will look like in few years time, so far cmake seems to be a good choice for C++/C
<pippijn>
I do have OCaml-Requires and C-Requires
<pippijn>
because..
<pippijn>
an ocaml target may want both
<pippijn>
I could have a Requires, though
<pippijn>
and it's turned into OCaml-Requires if the main language is ocaml
<wmeyer>
you know what, I'd write my own build system, and I feel it can be as good as git for VCS, but i simply don't have time; if that convinces you
<wmeyer>
it should not be too hard, given how many tries we had
<pippijn>
wmeyer: what ideas do you have?
<wmeyer>
and how much knowledge we have what not to do
<wmeyer>
not yet! but there are building up!
<pippijn>
because I'm making a build system now
<pippijn>
with omake
<pippijn>
omake is really basic, in a way
<pippijn>
it provides a functional language with dynamically scoped variables
<pippijn>
and an expert system
<pippijn>
and some functions to insert knowledge and query it
<wmeyer>
the only thing which worries my scaling up with large projects
<wmeyer>
pippijn: yes, that's omake
<pippijn>
large is how large?
<wmeyer>
there are two means of scaling
<pippijn>
more than 10000 files?
<wmeyer>
how complex your build rules will be for complex project
<wmeyer>
how unefficient the build system will be with large project
<wmeyer>
that two factors to remember
<pippijn>
complex project?
<pippijn>
what is a complex project?
<wmeyer>
so one needs to think about simple use patterns, but maybe with slight overhead
<wmeyer>
with lot of stages
<wmeyer>
and maybe boostrapping
bastian has quit [Remote host closed the connection]
<wmeyer>
like compilers
<wmeyer>
custom tools
<wmeyer>
meta programming
<wmeyer>
that's complex project
<pippijn>
is our C++ parser complex?
<wmeyer>
bit project is simple; a tree of interdependent modules saturated with interdependent files
<wmeyer>
i think it's moderately simple
<wmeyer>
OCaml is quite complicated
<wmeyer>
it didn't grow too much remember
breakds has quit [Quit: Konversation terminated!]
<pippijn>
I think omake scales well both in complex and large projects
<wmeyer>
another thing to remember, how easy is to process shell commands
<pippijn>
but what I'm building on top of it will scale only for large projects
<pippijn>
not for complex
<wmeyer>
and as you see Makefile fit the bill in most cases
<wmeyer>
yet another thing is, configuration management
<wmeyer>
and variable bindings
<wmeyer>
but also paraler builds and efficiency
<pippijn>
there is something about omake I find extremely annoying
<wmeyer>
it seems like, build systems are inherently difficult
<pippijn>
it is possible to modify the global environment from a function
<pippijn>
unless the function is called in an expression
<pippijn>
that might turn out to be a deal-breaker for complex projects
<wmeyer>
oh yes, indeed
<wmeyer>
it's never a good thing
<wmeyer>
and it's hard to avoid mutation, but in this case it should be avoided (dynamic scoping)
<pippijn>
it's impossible to avoid
<wmeyer>
i hate dynamic scoping because of this implicit behavior
<wmeyer>
it's really bad from what i can tell by experience i had with Elisp some time ago
<pippijn>
because rules are scoped
<pippijn>
pattern-rules are scoped
<wmeyer>
yes
<pippijn>
so if I want to create a pattern rule inside a function, I need to export it to the parent env
ttamttam has quit [Quit: ttamttam]
<pippijn>
but now the function can't return anything
<pippijn>
because if it returns something, I need to use it in an expression to get its value
<pippijn>
and then the rule is not exported
<pippijn>
I think I'm going to write to the authors one of these days
<pippijn>
wmeyer: generating omakefiles from another source would be best
<pippijn>
then you could work around these things without making the user code ugly
<pippijn>
my primary goal is to make concise build descriptions
<wmeyer>
but then Makefiles wouldn't be better, and remember: compilation ~ interpretation
<wmeyer>
so I'd ask why do you need
<wmeyer>
maybe then extensible macro language would be best
<wmeyer>
for definition of the build system you need
<wmeyer>
and lowlevel backend similar to Makefiles
<pippijn>
yes
<wmeyer>
Oasis :-)
<pippijn>
but omake as backend would be good
<wmeyer>
it's very robust
<pippijn>
that
<wmeyer>
and fast
<pippijn>
and it has file system monitoring
<wmeyer>
-P
<wmeyer>
yes
<pippijn>
so you get instant rebuilds on change
<wmeyer>
I agree but not everyboyd would like this approach
<pippijn>
it doesn't need to rebuild the DAG
<pippijn>
what approach?
<wmeyer>
of generating files; having a backend language; and custom extensible language for defining build systems
<wmeyer>
but in principle i agree
<pippijn>
I'm building it in omake now
<wmeyer>
I like it, please update me!
<wmeyer>
so far it looks promising
<pippijn>
and omake is an extensible macro language
<pippijn>
it's just a little hard to use
<pippijn>
so maybe I can put something on top of it
<pippijn>
but not soon
<wmeyer>
BTW: I was reading about K framework
<wmeyer>
looks nifty
<wmeyer>
and i have some idea :-)
eikke has quit [Ping timeout: 246 seconds]
<pippijn>
their tutorials are videos?
eikke has joined #ocaml
<wmeyer>
yeah
<pippijn>
they wrote it in java
<pippijn>
I don't understand that choice
<wmeyer>
in maude as well and haskell too
<wmeyer>
i don't understand it too
<wmeyer>
i think it's a chalenge, how hard is to do it in Java, so let's do it in java rather in Coq
<pippijn>
K is also in maude?
<pippijn>
can maude produce programs, yet?
<wmeyer>
yes it can
<wmeyer>
i think the compiler is in maude
<pippijn>
I never got their FullCompiler to work
tane has quit [Quit: Verlassend]
<wmeyer>
it will be a hurde on ARM
osnr has quit [Quit: Leaving.]
<wmeyer>
i dislike java for quite long time, although it drives the industry (sorry to say that pippijn I really like you as coder, but Java is sooo boring)
<pippijn>
why are you sorry?
<wmeyer>
that you have to write java :-)
<pippijn>
yes
<pippijn>
for now
<wmeyer>
i appreciate you do a lot of ocaml though
<wmeyer>
btw, we still need to have a beer
<wmeyer>
if you fancy trip to cambridge, you are welcome
malo has quit [Quit: Leaving]
* wmeyer
is going to bed, good night!
<pippijn>
good night
<pippijn>
can Lwt.async be replaced by ignore if async_callback is not used?