Guest78816 has quit [Killed (weber.freenode.net (Nickname regained by services))]
sam__ has quit [Ping timeout: 276 seconds]
sam__ has joined #ocaml
barcabuona has quit [Ping timeout: 255 seconds]
barcabuona has joined #ocaml
jlam has joined #ocaml
jlam has quit [Read error: Connection reset by peer]
jlam has joined #ocaml
silver has quit [Read error: Connection reset by peer]
jlam1 has quit [Ping timeout: 240 seconds]
sh0t has joined #ocaml
sh0t has quit [Remote host closed the connection]
sgronblo has joined #ocaml
sgronblo has quit [Ping timeout: 240 seconds]
sam__ has quit [Ping timeout: 240 seconds]
zwild has joined #ocaml
mfp__ has quit [Ping timeout: 246 seconds]
cranmax has joined #ocaml
sz0 has quit [Quit: Connection closed for inactivity]
TarVanim_ has joined #ocaml
sgronblo has joined #ocaml
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 248 seconds]
mengu has quit [Remote host closed the connection]
nomicflux has joined #ocaml
sh0t has joined #ocaml
TarVanim_ has quit [Quit: TarVanim_]
kamog has quit [Remote host closed the connection]
ziyourenxiang has joined #ocaml
ryanartecona has joined #ocaml
sam__ has joined #ocaml
sam__ has quit [Ping timeout: 240 seconds]
ryanartecona has quit [Quit: ryanartecona]
sh0t has quit [Remote host closed the connection]
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
ygrek has joined #ocaml
samrat has joined #ocaml
nomicflux has quit [Quit: nomicflux]
spew has quit [Quit: foobar]
samrat has quit [Ping timeout: 260 seconds]
ziyourenxiang has quit [Ping timeout: 240 seconds]
enterprisey has quit [Remote host closed the connection]
sz0 has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
jimmyrcom has quit [Ping timeout: 240 seconds]
copy_ has quit [Quit: Connection closed for inactivity]
samrat has joined #ocaml
Merv__ has quit [Remote host closed the connection]
_whitelogger has joined #ocaml
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 240 seconds]
freusque has joined #ocaml
jlam has joined #ocaml
jlam_ has quit [Ping timeout: 258 seconds]
ryanartecona has joined #ocaml
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 260 seconds]
cranmax has quit [Quit: Connection closed for inactivity]
sam__ has joined #ocaml
sam__ has quit [Ping timeout: 260 seconds]
ziyourenxiang has joined #ocaml
enterprisey has joined #ocaml
moei has quit [Quit: Leaving...]
ryanartecona has quit [Quit: ryanartecona]
cranmax has joined #ocaml
enterprisey has quit [Quit: Leaving]
moei has joined #ocaml
vtomole has quit [Ping timeout: 260 seconds]
barcabuona has quit [Ping timeout: 240 seconds]
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
barcabuona has joined #ocaml
dhil has joined #ocaml
moei has quit [Quit: Leaving...]
Merv_ has joined #ocaml
hackwaly has joined #ocaml
hackwaly has quit [Client Quit]
pacak has joined #ocaml
dhil has quit [Ping timeout: 248 seconds]
sz0 has quit [Quit: Connection closed for inactivity]
Merv_ has quit []
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
zwild has quit [Remote host closed the connection]
andreas_ has joined #ocaml
zwild has joined #ocaml
Merv_ has joined #ocaml
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
sam__ has joined #ocaml
zwild has quit [Remote host closed the connection]
zwild has joined #ocaml
moei has joined #ocaml
sam__ has quit [Ping timeout: 255 seconds]
nightmared has joined #ocaml
TarVanim_ has joined #ocaml
mengu has joined #ocaml
mengu has quit [Remote host closed the connection]
cranmax has quit [Quit: Connection closed for inactivity]
TarVanim_ has quit [Quit: TarVanim_]
sz0 has joined #ocaml
argent_smith has joined #ocaml
mfp__ has joined #ocaml
kyod has quit [Quit: WeeChat 1.6]
kyod has joined #ocaml
barcabuona has quit [Ping timeout: 240 seconds]
kakadu has joined #ocaml
sam__ has joined #ocaml
sam__ has quit [Ping timeout: 255 seconds]
ziyourenxiang has quit [Ping timeout: 268 seconds]
dhil has joined #ocaml
zpe has joined #ocaml
zwild has quit [Quit: ERC (IRC client for Emacs 25.2.1)]
samrat has quit [Ping timeout: 246 seconds]
sgronblo has quit [Ping timeout: 240 seconds]
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Ping timeout: 268 seconds]
letoh has quit [Ping timeout: 240 seconds]
cranmax has joined #ocaml
sepp2k has joined #ocaml
sam__ has joined #ocaml
<sam__>
So... if merlin relies on .cmi files what is the best workflow I can set up for getting instant error checking in my editor (vscode)?
jlam has joined #ocaml
jlam_ has quit [Ping timeout: 240 seconds]
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 268 seconds]
<rwmjones>
do we know when 4.05.0 is going to be released?
sam__ has quit [Ping timeout: 255 seconds]
<octachron>
rwmjones, soon, there is some last minutes discussion on what is the best way to deal with the Intel hyperthreading issue
_andre has joined #ocaml
<octachron>
sam__, you could use a watcher to compile cmi file when the corresponding .mli are updated, otherwise simply recompiling after changing the external interface of a compilation units works
sam__ has joined #ocaml
mengu has joined #ocaml
snowcrshd has joined #ocaml
Simn has joined #ocaml
mengu has quit [Remote host closed the connection]
nomicflux has joined #ocaml
jlam has joined #ocaml
dhil has quit [Ping timeout: 246 seconds]
jlam_ has quit [Ping timeout: 255 seconds]
Sim_n has joined #ocaml
Simn has quit [Ping timeout: 240 seconds]
samrat has joined #ocaml
nomicflux has quit [Quit: nomicflux]
barcabuona has joined #ocaml
shinnya has joined #ocaml
mengu has joined #ocaml
dhil has joined #ocaml
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 260 seconds]
FreeBirdLjj has joined #ocaml
sh0t has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
jlam has joined #ocaml
jlam_ has quit [Ping timeout: 240 seconds]
sam__ has quit [Ping timeout: 246 seconds]
sam__ has joined #ocaml
jlam has quit [Ping timeout: 240 seconds]
jlam has joined #ocaml
sagotch has joined #ocaml
mengu has quit [Ping timeout: 268 seconds]
nicoo has quit [Ping timeout: 248 seconds]
sam__ has quit [Ping timeout: 240 seconds]
letoh has joined #ocaml
nicoo has joined #ocaml
<sagotch>
hi
<sagotch>
I have trouble with bytecode optimization, does someone have an explanation about why the first case does not produce the same bytecode as the second ? https://pastebin.com/WEny6SXT
cranmax has quit [Quit: Connection closed for inactivity]
<Drup>
At a glance, because f is a global symbol and bytecode compilation barely does any inlining
shinnya has quit [Ping timeout: 246 seconds]
<sagotch>
by global you mean toplevel ?
<Drup>
yes
<sagotch>
wrapping everything in a g function does not change anything (well, it does but f is still not inlined). Is there a reason not to inline bytecode?
<flux>
maybe the reason that it's pointless when there's native output, you know, priorization?-)
<flux>
(I imagine there's also value keeping bytecode compiler simple(r), and thus more maintainable.)
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 260 seconds]
mengu has joined #ocaml
samrat has quit [Ping timeout: 255 seconds]
<sagotch>
Ok, maybe. js_of_ocaml is based on bytecode, so I am a little bit concerned by this lack of optimization :(
<Drup>
js_of_ocaml does that kind of optimisation on its own
<sagotch>
oh, thx jsoo devs!
mengu has quit [Remote host closed the connection]
mengu has joined #ocaml
mengu has quit [Remote host closed the connection]
jlam has joined #ocaml
mengu has joined #ocaml
mengu has quit [Client Quit]
jlam_ has quit [Ping timeout: 240 seconds]
jlam_ has joined #ocaml
samrat has joined #ocaml
jlam has quit [Ping timeout: 260 seconds]
<infinity0>
anyone else tried 4.05 yet?
freusque has quit [Quit: WeeChat 1.7.1]
sagotch has quit [Quit: Page closed]
jlam has joined #ocaml
jlam_ has quit [Ping timeout: 248 seconds]
jlam_ has joined #ocaml
jlam has quit [Ping timeout: 248 seconds]
samrat has quit [Ping timeout: 260 seconds]
FreeBirdLjj has joined #ocaml
aciniglio has joined #ocaml
<octachron>
infinity0, yes.
<infinity0>
what have you tried, any fixes you could share? i opened an issue to ppx_deriving whose 4.05 version in git breaks a bunch of ppx_*_conv stuff
samrat has joined #ocaml
aciniglio has quit [Remote host closed the connection]
dhil has quit [Ping timeout: 255 seconds]
enterprisey has joined #ocaml
<orbifx[m]>
is it concluded that jbuilder is the future? :P
<rgrinberg>
Yes. To be convinced of that all one has to do is read jbuilder's source and compare to its alternatives
<orbifx[m]>
rgrinberg: want to offer some snippets?
govg has quit [Ping timeout: 260 seconds]
kevinqiu has joined #ocaml
<rgrinberg>
I'd start with reading jbuild.ml and understanding the build arrow that underlies the whole system. It's a very clean model that is partially responsible for how jbuilder handles some very complex rules with ease, stays fast, and extensible
demonimin has quit [Ping timeout: 260 seconds]
<rgrinberg>
Ocamlbuild's internals are a pile of mud in comparison
<rgrinberg>
And the rest aren't any better. (OMake, makefile based systems, etc)
enterprisey has quit [Ping timeout: 240 seconds]
<flux>
rgrinberg, does it have any "hacks" to handle ocaml, say, peculiarities?
<orbifx[m]>
I see
<orbifx[m]>
That's a good point
demonimin has joined #ocaml
demonimin has joined #ocaml
<flux>
how easy is it to start using it? I have a project that uses ocamlbuild, and I need to do ocamlbuild -clean way too often.. :)
<flux>
also does jbuilder do parallelization better?
slash^ has joined #ocaml
sam__ has joined #ocaml
<orbifx[m]>
flux, i'm looking at it just now, it seems no more difficult than ocamlbuild
jlam has joined #ocaml
jlam_ has quit [Ping timeout: 240 seconds]
<orbifx[m]>
I'm considering moving Logarion over to that soon
aciniglio has joined #ocaml
sam__ has quit [Ping timeout: 268 seconds]
<flux>
congrats on the very googlable name.. if google wouldn't say "searching for "location" instead" :)
jlam_ has joined #ocaml
<flux>
have you considered making it mirage-compatible?
jlam1 has joined #ocaml
<Drup>
I don't understand the complain about googlable library names when "opam show" exists
<Drup>
(remark valid for any language with a package manager)
<orbifx[m]>
I think mirage is already using it extensively flux
<flux>
orbifx[m], oh, doubly cool that it doesn't look too mirage-ish at all with different top-level Makefile rules etc ;-)
<rgrinberg>
flux: yes its much faster and easily supports the vast majority of ocaml projects without much hassle
<flux>
drup, well, can you make my web browser run opam show?-)
<flux>
(probably yes, is there a search form for opam?)
jlam has quit [Ping timeout: 268 seconds]
<Drup>
That one is actually slightly broken, but whatever: opam show gives you direct link ...
<orbifx[m]>
does it support pseudo-submodules rgrinberg ?
<Drup>
flux: I meant for jbuilder. I've heard complains about the googlability
<flux>
oh, I wasn't complaining about that :)
<flux>
jbuilder seems very googlable for me
<flux>
probably it gets more and more googlable during time :)
enterprisey has joined #ocaml
<flux>
I might be complaining if someone made a build system called "it" or "do" or "result", though ;)
kevinqiu has quit [Remote host closed the connection]
kevinqiu has joined #ocaml
kevinqiu has quit [Remote host closed the connection]
<rgrinberg>
orbifx[m]: not sure what are pseudo-submodules, but if ocamlbuild/oasis support it then so does jbuilder
kevinqiu has joined #ocaml
<Drup>
rgrinberg: I know you are entusiastic, but please don't oversell, that's just plain wrong. ;)
<Drup>
oversell just make early users bitter and stop them from trying again
jlam has joined #ocaml
<rgrinberg>
Drup: my statement meant to "pseudo-submodules" not all features
<Drup>
That's not how it reads, and this was more of a global comment anyway
<rgrinberg>
I'm not sure what those are, but I'm guessing that jbuilder will not have any problems supporting any project structure you might have had with modules
jlam1 has quit [Ping timeout: 268 seconds]
<orbifx[m]>
it's where the builder puts a "fake" super module FakeParent.RealModuleA
<rgrinberg>
I'm trying to do it honestly. I would not say that jbuilder's more extensible for example.
<octachron>
rgrinberg, what about nested module hierarchy ? nested package modules?
<rgrinberg>
orbifx[m]: yes it can. and this in fact it does better than oasis/ocamlbuild because it will use module aliases rather than packs.One of the reasons why it's so much faster
ivanacostarubio has quit [Ping timeout: 276 seconds]
<rgrinberg>
octachron: i know what you're alluding to, no jbuilder doesn't support it. but i haven't yet seen a use of namespaces in the wild
<rgrinberg>
so i kind of doubt it's a deal breaker
<rgrinberg>
FYI even anton doesn't recommend it anymore (he said this on discord)
kevinqiu has quit [Remote host closed the connection]
<octachron>
rgrinberg, well nobody does those because they is no good build system support for those
<octachron>
does anton doesn't this anymore in general, or it is more a question of doing it the proper way?
kevinqiu has joined #ocaml
<rgrinberg>
I can only guess here, but Anton seems pretty satisfied with jbuilder himself and has more interesting stuff to work on?
<rgrinberg>
or he might want to revisit this after the namespace proposal?
<rgrinberg>
you'd have to ask him
igitoor has quit [Ping timeout: 246 seconds]
igitoor has joined #ocaml
<octachron>
Note that I am just reacting to the "any module structure" claim, not criticising jbuilder by-se.
<rgrinberg>
on the point of overselling Drup, there's also the converse: new users giving up on OCaml after wrestling with crappy build tools.
igitoor has quit [Changing host]
igitoor has joined #ocaml
<Drup>
That's a completely different subject though
<rgrinberg>
octachron: understood
kevinqiu has quit [Remote host closed the connection]
<Drup>
As long as hidden interfaces and ctypes don't work yet, you're still missing some important use cases
<orbifx[m]>
Drup: rgrinberg it's not a matter of politeness anymore. One doesn't do injustice to another system by promoting one. If Jbuid can do >90% of the cases as good or better than other systems and it's written on good principles, I think we got a winner. Make it the defacto one for people to start somewhere.
<Drup>
I never said anything about politeness wrt other build systems.
<rgrinberg>
I acknowledge that for sure. but ocamlbuild doesn't support many features that jbuilder supports. IMO the correct way to frame this discussion is that if you're using ocamlbuild you should have a really good reason for doing so
dhil has joined #ocaml
<rgrinberg>
while jbuilder is the default answer
kevinqiu has joined #ocaml
<orbifx[m]>
;)
<Drup>
I'm not sure why you feel the need to be defensive. I said you should not *over*sell. Not that you should not sell
<rgrinberg>
Drup: i don't notice myself being defensive.
<orbifx[m]>
ok i think that branch has staled now :P
<orbifx[m]>
Thanks rgrinberg , I'm looking into changing one or two projects to jbuilder to figure out the details myself.
<rgrinberg>
orbifx[m]: give it a try, the docs should be all that you need to figure it out. but feel free to ask questions here
<companion_cube>
orbifx[m]: start with a small project
<companion_cube>
jbuilder's doc is a bit confusing at first imho :p
copy_ has joined #ocaml
<orbifx[m]>
one of the projects has a C interface, which will be interesting to convert
<orbifx[m]>
I'm reading the docs now, but you can spoil the surprise for me rgrinberg: does it support running arbitrary commands at specific compilation stages?
<Drup>
orbifx[m]: don't try to convert C bindings yet
<rgrinberg>
jbuilder lets you define user rules. it's a fairly primitive mechanism but it's simple and portable.
<Drup>
it's only going to give you pain
<Drup>
wait a few month, that we'll be squared away
<Drup>
will*
<orbifx[m]>
what's the issue?
<rgrinberg>
it's kind of manual now. I've studied how async_ssl does it and it just seems a little heavy on the boilerplate
<orbifx[m]>
rgrinberg: I want to run system commands, can it do that?
<rgrinberg>
orbifx[m]: the closest thing you have to commands are "aliases" which are like phony targets in makefiles.
<rgrinberg>
Otherwise, I'd need an example to understand what feature you're talking about
kevinqiu has quit [Remote host closed the connection]
<orbifx[m]>
one of the projects, labqml, needs to run arbitrary commands to build `.moc` files. I need to run that before the link phase for example.
<orbifx[m]>
also what do you mean by "manual"?
kevinqiu has joined #ocaml
<Drup>
There are no wildcard rules
<orbifx[m]>
not building too many files just now, so if that is all... shouldn't be much of an issue
<rgrinberg>
orbifx[m]: so if you have lots of .moc files it will be annoying
<rgrinberg>
ok, cool
<orbifx[m]>
rgrinberg: ow, found the (rule ..) part where it runs ocamllex
<rgrinberg>
exactly, you need to use rule stanzas
<orbifx[m]>
when are wildcard rules due?
<rgrinberg>
if enough people express interest, i bet the due dute will move closer
<rgrinberg>
but there's nothing set now
<orbifx[m]>
ok
<orbifx[m]>
not sure if this is a dealbreaker. I'd like to reimplement that build system and it would suck to have to redo the work
tane has joined #ocaml
<rgrinberg>
it depends on the project. most of the projects that i've ported, really only had a few targets in their wildcard
<rgrinberg>
so it wasn't a big deal
<rgrinberg>
but this should definitely be decided on a case by case basis
<Drup>
rgrinberg: Would be interested if you could give tyxml's jbuilderification a shot :p
Sim_n has quit [Quit: Leaving]
<rgrinberg>
Drup: my laptop is camlp4 free territory and will stay that way ;)
<Drup>
And ?
<orbifx[m]>
lol
<Drup>
camlp4 has been a depopts for several years
<rgrinberg>
So I'm not willing to port tyxml.syntax
<Drup>
That's really not the difficult part, though
<rgrinberg>
what's the difficult part then?
<Drup>
The ppx
<Drup>
(the internal one, which we use for introspection)
<rgrinberg>
can you brief me on how it works/what it does?
<Drup>
We have an internal tool that introspect the html and svg signature, extract some information from the ppx annotations and generates some code
<rgrinberg>
so, create a preprocessor and use it to generate some modules? Is there a static set of inputs/outputs? E.g. no wildcards
<Drup>
yes, the set of i/o is known
tane has quit [Quit: Leaving]
dakk has quit [Ping timeout: 248 seconds]
dakk has joined #ocaml
jlam__ has joined #ocaml
jlam has quit [Ping timeout: 246 seconds]
samrat has quit [Ping timeout: 240 seconds]
kevinqiu has quit [Remote host closed the connection]
kevinqiu has joined #ocaml
jimmyrcom has joined #ocaml
<kakadu>
Folks, how we should debug cases when ocamlmerlin eats 7 Gb of RAM?
<Drup>
Is "staring at def`" a debug method ?
andreas_ has quit [Quit: Connection closed for inactivity]
<Drup>
I wouldn't yell at you for being too bold in your migrating/removal process x)
<aantron_>
objection*
<aantron_>
:p
<Drup>
aantron_: I would be really interested if you could take a shot at implementing the method I suggested
<Drup>
I tried a little bit, but didn't got time to dig enough, and you are now much much better at lwt wizardery than I am
<Drup>
If only to produce a POC that someone can pick up
<aantron_>
yep, i was thinking that if i experiment, i'd probably leave it in a gist for now, and still prefer to merge the "naive" code in the PR. again, the gist to be picked up on demand
FreeBirdLjj has quit [Remote host closed the connection]
Merv_ has quit [Remote host closed the connection]
Merv_ has joined #ocaml
<Drup>
If could figure out a nice code-pattern to make "lwt trampolines", we could also turn while%lwt tailrec, which could be useful ... :p)
Merv_ has quit [Ping timeout: 260 seconds]
cranmax has joined #ocaml
<aantron_>
wow, didnt even know while%lwt is not tail-recursive..
<Drup>
well, it's pretty much "let rec f () = e >> f()"
<aantron_>
so i guess this map would have to scan to the end of the list, chaining chunks of length K together to be processed after the scan. each one of these chunks would then be scanned a second time, but the stack depth would not exceed K if we force queueing in lwt between each chunk. is that the shape of computation you had in mind? the allocations would be only the new list, and and the N/K lwt promises and queue cells, where N is the len
<Drup>
(when I was thinking about map_p, at some point I though "what I want is like while%lwt, how does it work" ... "oh")
<aantron_>
:p
<Drup>
Yes
<Drup>
Or not even scanning a second time actually
<aantron_>
i couldn't think of a way to avoid that
<flux>
but let rec f () = Lwt.return () >>= fun _ -> f () is tail recursive?
<Drup>
Basically, my initial idea was to do exactly like the batteries, but instead of using custom made one-write references objmagic'ed, we use ... Lwt.t
<aantron_>
flux: yes i think so
<Drup>
well, wait/wakeup, to be more precisely
<Drup>
batteries version*
<aantron_>
Drup: i don't see how to use Lwt.t to mutate the list itself, though, which is what batteries does. AFAICT it mutates the "next" pointers
<aantron_>
i guess we might not even need lwt for what im proposing with the chaining, it just may or may not be convenient, since we already have lwt around in lwt_list :)
<Drup>
(async is really the wrong thing to use here)
<Drup>
You keep a un-resolved Lwt.u that points to the queue of the list that has yet to be filled
<aantron_>
i'll have to look it at it after eating, but im worried that this might necessarily be allocating something per list element (the code as written seems to be, and there might be no way to optimize that). i would expect that to have about the same performance as naive tail-recursion, and off the top of my head the only way to avoid that is to deal with the list as a whole using standard map, in chunks like standard map, or mutate the ne
<Drup>
I don't really know how costly wait/wakeup is. My intuition was that it wasn't, but I might be wrong about that.
<aantron_>
wait allocates a promise, which is about as far as a list cell (for comparison with the intermediate list cells allocated by tail-recursive map)
<aantron_>
as fat*
<Drup>
Hum, I though it was just mutating the lwt value
<aantron_>
which lwt value? maybe there is a better implementation of wait, but right now it creates something like a 1-word block pointing to a 4-word blocking (a Pending {...} promise). so it's actually larger than a list cell, though both are pretty small
<aantron_>
(block headers not being counted by me)
<aantron_>
it shouldn't even be called wait really, it's the basic promise constructor that creates pending promises
<Drup>
"Lwt.wakeup x v" would replace "x" (which contains Pending) to "Resolved v"
<aantron_>
yes
<Drup>
I tough it was just doing that, with additional error reporting stuff
<Drup>
Well, I'll look at you writeup when I have some time, because I don't see why this allocates a closure
<aantron_>
i don't know about a closure, but it does allocate a promise
<Drup>
Oh, promise, not sure, right
<aantron_>
(Lwt.t)
<aantron_>
:)
<Drup>
Yeah, right
* Drup
got confused
<aantron_>
and i'll write a trampolined map.. and plug it into jsthomas' benchmarking code :)
slash^ has quit [Read error: Connection reset by peer]
Merv_ has joined #ocaml
jbrown has quit [Ping timeout: 255 seconds]
ivanacostarubio has joined #ocaml
jbrown has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
SpiceGuid has joined #ocaml
zpe has quit [Ping timeout: 258 seconds]
Merv_ has quit [Ping timeout: 240 seconds]
kakadu has joined #ocaml
tane has quit [Quit: Leaving]
kakadu_ has joined #ocaml
kakadu has quit [Ping timeout: 240 seconds]
nicoo has quit [Remote host closed the connection]
nicoo has joined #ocaml
pierpa has joined #ocaml
sam__ has joined #ocaml
pzp has joined #ocaml
sam__ has quit [Ping timeout: 240 seconds]
al-damiri has joined #ocaml
Merv_ has joined #ocaml
_andre has quit [Quit: leaving]
<aantron_>
Drup: i simplified the trampolined map idea a lot, it's basically now an "unrolled" tail-recursive map
<aantron_>
and so far it looks like it is the best-performing map on large-ish lists (the ones in that window between when containers/base is best, and when stdlib just fails completely)
<aantron_>
and the worst-performing on small lists
<Drup>
what does it look like ?
<aantron_>
the code? let me clean it up. im doing a search in the performance space for the next 30 min maybe
<Drup>
ok
<aantron_>
it basically builds a list of lists in the first pass, each Kth nested list being a pointer K*(chunk size) into the input list
<aantron_>
those nested lists are reversed
<aantron_>
this is basically the first half of naive tail-recursive map, but skipping chunk size elements at a time to build the intermediate list
<aantron_>
anyway
<aantron_>
im going to write the docs around and in the code, so i'll explain fully then :)
<Drup>
sounds fancy
<aantron_>
its certainly fancier than the simple map implementations :)
john51 has quit [Ping timeout: 240 seconds]
<Armael>
ohai aantron_; I'd like to work at some point in the future on fixing this issue with compiling markup to js
john51 has joined #ocaml
<Armael>
I'm willing to do the work, but I was wondering if you had opinions on how the issue should be addressed?
<aantron_>
Armael: hi :)
<aantron_>
i was going to wait in case @hhugo (or someone else from js_of_ocaml) had sage advice first
<Armael>
ah, yes
<aantron_>
but otherwise, we should probably implement some "generic" trampolining mechanism
<aantron_>
i haven't really thought through how that would look
<Armael>
I guess we would like to only enable it when compiling to jsoo
<Armael>
because it's probably going to slow markup by a non negligible amount
john51 has quit [Read error: Connection reset by peer]
<aantron_>
yes, i gave that some thought.. but that seems difficult to detect, since jsoo is a last operation on what looks like regular bytecode compilation
<aantron_>
it might not slow down markup that much though, we would have to see
sh0t has quit [Ping timeout: 255 seconds]
<aantron_>
also there are optimizations to be made to markup that could be relatively much more significant than the slowdown
<Armael>
I gave a shot at making 'a cont abstract, with make/app functions, and then mechanically fixing the type errors anywhere in markup
<aantron_>
that sounds like a lot of stuff to do :/
<Armael>
I didn't quite finished, I got lost at some point
<Armael>
yea
<aantron_>
hopefully you prototyped first?
<Armael>
prototyped?
<aantron_>
like wrote some throwaway cps code that is using this mechanism
<aantron_>
(im sorry there's so much code in markup, going to have to blame the html people.. but also thank them for being thorough :p)
<Armael>
mm not really, but I know how to do it
sh0t has joined #ocaml
<Armael>
I already did that kind of stuff before
<aantron_>
it may help to guess the performance effect, though it might not transfer over eactly
<Armael>
ah, yea
john51 has joined #ocaml
<Armael>
also, what surprised me is that I get a stack overflow with a single Markup.next invocation
<Armael>
with like "<p></p><p></p>...." as input
<aantron_>
what if you pass ~encoding:Encoding.utf_8?
<Armael>
am I correct when saying that Markup.next should only look for the first 3 chars?
<aantron_>
the first step in parsing HTML is auto-detecting the encoding, and that can be expensive
<aantron_>
i mean
<Armael>
ah
<aantron_>
it can read a lot of chars, iirc 1024
<aantron_>
if there is a BOM it uses that, otherwise it looks for an ascii-compatible-encoded <meta charset> in 1024 bytes of data
<aantron_>
(modulo any details im missing due to it being like 1.5 years later :))
<Armael>
ah, I see, with ~encoding:Encoding.utf_8 it doesn't SO anymore
<aantron_>
ok good :)
mengu has joined #ocaml
<Drup>
Armael: doesn't SO at all ?
<aantron_>
actually, is it possible that many inputs are "fixed" by passing the encoding to markup? i would still expect it to choke on large text nodes
<Drup>
or it simply takes longer input ?
<Armael>
can you give an intuition on the number of continuation called by Markup.next, depending on the input?
enterprisey has quit [Remote host closed the connection]
<Drup>
IIRC, we fix the encoding in tyxml, is that right ?
<Armael>
takes a longer input
<aantron_>
Drup: yes
<aantron_>
but also Drup, this is a jsoo-only issue
<aantron_>
in tyxml Markup runs in the PPX
<Drup>
(context: Armael is making a small web "app" that, given a bunch of html, output pretty tyxml code that does it)
<Drup>
So, it calls the ppx and then prettify the output
aciniglio has quit [Ping timeout: 240 seconds]
<aantron_>
Armael: encoding detection aside, markup.next reads enough bytes to decide to emit one signal (in most situations). most signals correspond to tags, which have relatively few bytes, and text nodes, as you know, which can be arbitrarily long. the number of continuations called per byte should be somewhere around 5, not sure right now
<Drup>
(I hope at some point we can simply add a --pretty option for the ppx, but that doesn't change the SO issues)
<aantron_>
these are multi-shot continuations, i was hoping the optimizer would just inline them heavily. in any case they are not constantly being allocated iirc
<aantron_>
ah, i see
jlam__ has joined #ocaml
<Armael>
when fixing the encoding, I'm able to make Markup.next SO with an input like "<a title="lots of text ......."></a>"
jlam__ has quit [Read error: Connection reset by peer]
<aantron_>
yep
jlam__ has joined #ocaml
<aantron_>
an opening tag is a single single, and markup will go through the continuations for each byte of that attribute value
<aantron_>
single signal
<Drup>
Couldn't this be improved significantly if you were using a string stream instead of a char stream ?
jlam has quit [Ping timeout: 240 seconds]
<Drup>
(or a lexbuf-style streaming API, whatever works)
<aantron_>
that would only affect the first layer of parsing
<aantron_>
yeah markup should probably be optimized internally in various ways
<aantron_>
but most of these continuations are like "run the decoding loop through one iteration and call f"
<aantron_>
so unless the code is changed not to be built that way, that will be there no matter what size chunks you read from the data source
<Drup>
shame we can't run flambda's magic on that :(
<aantron_>
yeah, for jsoo?
<Drup>
yeah
<aantron_>
i guess this might be not so difficult to get around. the places that can read a lot of bytes are the tokenizers, parsers, and the encoding detectors
<aantron_>
gah
<aantron_>
why no tail-calls :(
<Drup>
:javascript:
<aantron_>
anyway i will accept any reasonable change to the internals of markup, as well as many kinds of changes to the api (string input streams, especially for Markup_lwt, for instance)
<aantron_>
the library was meant to have its internals rewritten
<aantron_>
lol yes
Merv_ has quit [Ping timeout: 248 seconds]
jlam__ has quit [Read error: Connection reset by peer]
jlam has joined #ocaml
<Armael>
(re)
<Armael>
so would it be useful to read chunks instead of single bytes in order to mitigate the SO issues?
<Armael>
or would there still be other problematic parts of the code
<aantron_>
it would still be problematic. it would reduce the number of continuation calls from say 5 per byte to 4 per byte. im not even fully sure about that
<Armael>
ok
<Armael>
so why are there so many k-calls per bytes?
sam__ has joined #ocaml
<aantron_>
because each byte needs to be read, then decoded to a uchar, then given location information, then passed through the tokenizer (so i guess 5 is actually 4)
sepp2k has quit [Ping timeout: 246 seconds]
<aantron_>
(the location information probably needs optimization)
<aantron_>
so i guess it's about 4 continuations per byte, 3 if you use string streams
<Armael>
ok, makes sense
<Armael>
js not having tail-calls is such a pain
<aantron_>
that code would have to run either way, it's just expressed in CPS using mostly fixed multi-shot continuations, and im either counting on optimizers to inline it into straight-line code, or otherwise optimize it by hand. i get the impression flambda is going a good job here, and even the older optimizer too
<aantron_>
though i havent actually checked the asm output
<aantron_>
but a unicode decoder written specifically for markup (not for general use) in this style, was outperforming uutf, so presumably it doesnt suck.. though there might be mistakes in specific instances that cause allocation or prevent optimization
<Armael>
I don't understand why continuations need to be multi-shot?
<Drup>
aantron_: I ran non-trivial pieces of code through the ppx, so at the very least, most of if are tail-calls
<aantron_>
because im many places they are allocated once, and then the code that gets them calls them over and over
<aantron_>
Drup: im reasonably certain that markup.ml is tail-recursive. i've run it on big inputs with spacetime, etc. (actually found a tail recursion bug that way in Markup_lwt)
<aantron_>
so tail-recursive and non-leaking :)
<Armael>
I'll try to write a super-toy example and trampoline it
<Armael>
in order to get a lower bound on the slowdown
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
kevinqiu has quit [Ping timeout: 255 seconds]
<aantron_>
Armael: essentially multi-shot continuations are more of a way of composing a program together "kind of" statically, rather than passing arbitrary future code to execute to arbitrary places. in my imagination, it makes them more susceptible to inlining. i could be wrong
<Armael>
yea I see
<aantron_>
that sounds good
sam__ has quit [Ping timeout: 248 seconds]
deep-book-gk_ has joined #ocaml
copy_ has quit [Quit: Connection closed for inactivity]
geol has joined #ocaml
deep-book-gk_ has left #ocaml [#ocaml]
<geol>
Hello. I'm trying to understand some code. What does ->- do?
<geol>
Right. Thanks again. I'm using Intellij. Best i could find was an old OCaml plugin but it'
<geol>
s better than nothing
sam__ has joined #ocaml
<octachron>
on windows, I have heard good things about VS code+ocaml (or reason)
<geol>
Thanks again.
ygrek has joined #ocaml
SpiceGuid has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.46/20161213183751]]
kakadu_ has quit [Remote host closed the connection]
<sam__>
i recommend vscode too. even if you are not on windows.
sh0t has quit [Remote host closed the connection]
geol has quit [Quit: Page closed]
Merv_ has joined #ocaml
Merv_ has quit [Ping timeout: 260 seconds]
dhil has quit [Ping timeout: 240 seconds]
zmt00 has joined #ocaml
averell has quit [Ping timeout: 240 seconds]
jlam__ has joined #ocaml
jlam has quit [Ping timeout: 268 seconds]
sh0t has joined #ocaml
<sam__>
so can i generate an opam file using jbuilder too or?
iitalics has joined #ocaml
<aantron_>
sam__: AFAIK jbuilder depends on you already having foo.opam files, but also i saw in the manual that maybe you can generate the dependencies fields
andreas_ has quit [Quit: Connection closed for inactivity]
averell has joined #ocaml
argent_smith has quit [Quit: Leaving.]
snowcrshd has quit []
jlam has joined #ocaml
tizoc has quit [Quit: Coyote finally caught me]
jlam__ has quit [Ping timeout: 248 seconds]
tizoc has joined #ocaml
iitalics has quit [Quit: /thread]
pierpa has quit [Quit: Page closed]
ousado has joined #ocaml
Merv_ has joined #ocaml
<aantron_>
dang. its fast
<aantron_>
now i have to check extremely carefully that it's correct
cranmax has quit [Quit: Connection closed for inactivity]