<def`>
The problem is an incompatibility introduced by 4.02.1, and I don't know which way is safe, but I would like to avoid maintaining a 4.02.0 and >=4.02.1 typercheckers
<def`>
4.02.1
<ggole>
I'll upgrade then.
<def`>
If that's fine for you, you can switch now. Otherwise I hope we'll make progress on the issue todayy
<def`>
(Also, if you are compiling from git, there is only 2 branches to comment to make it build with 4.02.0)
bjorkintosh has quit [Ping timeout: 250 seconds]
ollehar has quit [Ping timeout: 258 seconds]
bjorkintosh has joined #ocaml
pii4 has joined #ocaml
<ggole>
def`: 4.02.1 works fine, thanks
<ggole>
Maybe a version check and a message would be useful though
<ggole>
Also, configure bitches at me that something is badly wrong when it doesn't find findlib: however, the problem is nothing more than findlib is missing (which is normally the case after an opam switch)
<ggole>
It's not really a problem, but it is a bit more alarming than necessary.
segmond has quit [Ping timeout: 255 seconds]
ysz has joined #ocaml
vogler has joined #ocaml
malc_ has quit [Ping timeout: 245 seconds]
segmond has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
ysz has quit [Remote host closed the connection]
freling has joined #ocaml
freling has quit [*.net *.split]
ollehar has joined #ocaml
ysz has joined #ocaml
freling has joined #ocaml
samrat has quit [Ping timeout: 250 seconds]
_2can_ is now known as _2can
freling has quit [*.net *.split]
johnelse_ is now known as johnelse
<companion_cube>
I'm fairly confident it won't, but is it possible to limit OCaml's memory usage within OCaml?
siddhart1v has quit [Quit: leaving]
siddharthv has joined #ocaml
keen___ has joined #ocaml
siddharthv has quit [Client Quit]
siddharthv has joined #ocaml
<ggole>
There's a bunch of control stuff in the Gc module, but I don't think a limit is included
keen__ has quit [Ping timeout: 258 seconds]
kakadu has joined #ocaml
<companion_cube>
I thought so :/
<ggole>
Can you use rlimit instead?
<companion_cube>
I don't remember how portable it is :s
<flux>
I wonder what happens when you exceed rlimit in ocaml
<flux>
I would expect a crash
<ggole>
Hmm, it's POSIX
<flux>
instead of emergency gc
<flux>
you can make efforts to minimize the memory food print at the expense of runtime, of course
<ggole>
Wouldn't it be the gc that exceeds the limit?
<companion_cube>
it's not in my shell, nor in my man pages
<companion_cube>
only ulimit...
<companion_cube>
ah, setrlimit
<ggole>
Sorry, rlimit refers the set/getrlimit calls
<ggole>
Which I think ulimit uses these days
<companion_cube>
and they aren't bound in Unix
arj has quit [Quit: Leaving.]
<flux>
I think there's a Unix extension module that has them
<flux>
if not anything else, then perhaps Core?
<Leonidas>
whitequark: stupid question but how do I use the lwt ppx in utop?
rand000 has joined #ocaml
dmbaturin_ is now known as dmbaturin
<Leonidas>
let%lwt foo = Lwt.return ();; fails to parse
arj has joined #ocaml
zozozo has quit [Quit: leaving]
<whitequark>
#require "lwt.ppx";; first
<Leonidas>
still doesn't work
AlexRussia has joined #ocaml
<Leonidas>
also tried #ppx "ppx_lwt";;
<whitequark>
hm
f[x] has joined #ocaml
<whitequark>
what is the exact error?
<Leonidas>
(doesn't work = the call succeeds, but the error stays the same)
<Leonidas>
Error: Parse error: "module" or "open" or [opt_rec] expected after "let" (in [str_item])
<companion_cube>
hmm, can't find which of ulimit's parameters are for the actual size of the heap
<whitequark>
are you using OCaml >=4.02?
<Leonidas>
oh, maybe it just works with let%ppx … in …?
<Leonidas>
4.02.1, yes
<Leonidas>
utop 1.15
<def`>
try without camlp4
<companion_cube>
ok, -d (data seg size)
<whitequark>
oh, def` is right
<Leonidas>
how?
<whitequark>
remove #camlp4o from your .ocamlinit, remove any packages that require camlp4 like sexplib.syntax and so on
<Leonidas>
remove from the system? that's quite a bit :-/
<whitequark>
no, remove from your ocamlinit
<whitequark>
don't load them, basically
<Leonidas>
~/.ocamlinit is empty
<Leonidas>
(actually, nonexisting)
zozozo has joined #ocaml
<whitequark>
ok, then camlp4 should not be loaded. are you trying out the ppx syntax in a fresh toplevel instance?
<Leonidas>
oh, I see, when I jusr require lwt.ppx it works
<Leonidas>
I suppose it might be because of cohttp.ltw
<adrien>
there might be a reason to have lablgtk support GTK+3 now
<adrien>
"This is another very old request – GtkGLExt and GtkGLArea have been around for more than a decade. In 3.16, GTK+ will come with a GtkGLArea widget."
<Leonidas>
yep
<adrien>
and clean the awful mess
<def`>
rm -rf gtk*
<Leonidas>
rm -rf qt* while at it
<def`>
:) right
<whitequark>
and what are you going to use? ncurses?
<adrien>
efl!
<Leonidas>
FLTK! :p
<def`>
what's the best? bad guis or no gui?
<Leonidas>
(does that still exist?)
<whitequark>
qt is good.
<adrien>
yeah
<adrien>
but ftlk looks the same as before
<adrien>
it's very small however
<adrien>
only 100K or so I think
<def`>
like qt
<adrien>
but maybe all the weight is in the C++ libs
<whitequark>
your $tiny_homegrown_gui library can die in a fire
<adrien>
I dislike Qt's upstream
<adrien>
too difficult to interact with
<whitequark>
for several reasons, starting with: it doesn't support my 170 dpi display
<Leonidas>
whitequark: so basically, can't use ppx at the moment in utop because I need cohttp.lwt, but that breaks ppx :-/
zozozo has quit [Client Quit]
<whitequark>
Leonidas: that sounds like a cohttp bug
zozozo has joined #ocaml
<def`>
i don't give a f about your display
<whitequark>
it shouldn't require the syntax extension in cohttp.lwt
<Leonidas>
whitequark: that's entirely possible.
<Leonidas>
#require "lwt.ppx";;
<whitequark>
def`: every display is going to be hidpi since about today
<Leonidas>
let%lwt foo = Lwt.return ();; works
<whitequark>
if your UI library is unable to support that, it should die.
<whitequark>
def` is going to need to troll harder ;p
<flux>
def`, I think you're mixing hippies and hidpi
dsheets has joined #ocaml
<def`>
it's a gentle warmup, not really a troll :)
<flux>
but that cool retro term is truly a work of art
<whitequark>
Leonidas: yep, cohttp bug. cohttp requires *.syntax where it shouldn't
<whitequark>
it's fixed in (unreleased) 0.12.0
dsheets has quit [Ping timeout: 244 seconds]
ontologiae has joined #ocaml
oscar_toro has quit [Ping timeout: 250 seconds]
ontologiae has quit [Ping timeout: 272 seconds]
sepp2k has quit [Ping timeout: 245 seconds]
sepp2k_ has joined #ocaml
kaustuv has joined #ocaml
<kaustuv>
Why is travis on opam-repository reporting build failures on 3.12 and 4.00 when it specifies ocaml-version: [>= "4.01.0"] ?
freling has joined #ocaml
<whitequark>
link?
_andre has joined #ocaml
ysz has quit [Remote host closed the connection]
arj has quit [Quit: Leaving.]
<AltGr>
hm, because it's dumb and tries anyway
AltGr has left #ocaml [#ocaml]
dsheets has joined #ocaml
Thooms has joined #ocaml
<Leonidas>
whitequark: good to know, I was about to file a bug :-)
srax3 is now known as srax
jerith_ is now known as jerith
<whitequark>
Drup: "Thanks, I just released 1.5.5 with this patch."
rand000_ has joined #ocaml
rand000 has quit [Ping timeout: 272 seconds]
ggole_ has joined #ocaml
ggole has quit [Read error: Connection reset by peer]
<Leonidas>
*sigh* Is there a way to use a function in an ml file that is defined later in the file? So I don't have to shuffle definitions around?
<ggole_>
let ... and ... is the usual way
<ggole_>
...but that can involve some shuffling
<Leonidas>
ggole_: the point is I have my helper functions defined at the top but for one I need a higher level function and shuffling around will destroy the order of "nonexposed functions, then exposed functions" which would be ugly.
<Leonidas>
but I'll reshuffle, then
<flux>
use references or higher order funtions ;)
oscar_toro has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
<ggole_>
Leonidas: hmm, I'd just intermingle them and try not to get too attached to the order.
<Leonidas>
okay, will do.
<flux>
at times order would be nice, though. it makes ugly diffs when you need to shuffle stuff around.
siddharthv is now known as siddharthv_away
<uggwar>
why would ocamlbuild say that there is no implementation for the module tsdl when I have it installed with opam, added the package dep in _tags?
<uggwar>
*confused*
<uggwar>
:-)
<uggwar>
i'm using dbuenzli's build structure as a reference, but i must have missed something crucial
<uggwar>
sorry, ocaml is new to me (obviously) ;-)
samrat has quit [Ping timeout: 255 seconds]
<kaustuv>
<src/game.native>: package(tsdl)
<kaustuv>
or do <src>: include, and have a separte _tags in src
<uggwar>
kaustuv: yes! it worked! woohoo! :-)
<uggwar>
thanks everyone!
<uggwar>
moved deps into src/_tags. feels better
<uggwar>
i obviously need the dependency on both the source and the build target
<ggole_>
companion_cube: RLIMIT_AS, I believe
<ggole_>
Oh, you figured it out
ggole_ is now known as ggole
<companion_cube>
yes, it works
<companion_cube>
I don't really understand why, but since it works...
<ggole>
It tells the kernel to refuse requests for memory from things like mmap once the limit is reached
<ggole>
Eventually malloc will ask for more memory and get none, returning NULL to the OCaml memory management machinery, which will handle it (I imagine by either GCing harder or falling over)
MercurialAlchemi has quit [Ping timeout: 240 seconds]
MercurialAlchemi has joined #ocaml
<companion_cube>
the heap is managed with mmap?
arj has joined #ocaml
<ggole>
That's the usual way to allocate address space on modern systems
<ggole>
I think that OCaml itself just calls malloc, but at some point there will be an allocation syscall of some kind, and rlimit will take effect there.
<whitequark>
RLIMIT_AS is wrong.
<whitequark>
it limits address space. you can map a 20G file into your address space on a 64-bit system and it will consume no resources.
<whitequark>
in fact, it's the preferable way to work with files
<whitequark>
let me find the limit that you need
<whitequark>
companion_cube: you should use RLIMIT_RSS.
<whitequark>
well, if you want *specifically* heap, then RLIMIT_DATA, but RLIMIT_RSS maps most closely to "real memory consumption"
<whitequark>
including mmap(MAP_ANONYMOUS), thread stacks, and so on
<ggole>
"This limit only has effect in Linux 2.4.x, x < 30, and there only affects calls to madvise(2) specifying MADV_WILLNEED."
<ggole>
Is that right?
<whitequark>
oh, hm.
<ggole>
malloc might indeed use that flag, but...
<whitequark>
no, it's not, let me look further.
samrat has joined #ocaml
<adrien>
mmap() isn't always faster though, shrinking with it is dangerous and expanding is difficult
<adrien>
if you're write-only, it might well be slower too
vogler has quit [Quit: WeeChat 0.4.3]
<whitequark>
yes, shrinking is problematic. there was a patch flying around that disallowed truncating.
<whitequark>
companion_cube: well. basically, you need the equivalent of ulimit -m
<whitequark>
I thought -m maps to RLIMIT_RSS, but it does not. let me figure out what does.
nicoo has quit [Write error: Connection reset by peer]
<companion_cube>
I don't think RLIMIT_DATA limits the ocaml heap properly
<companion_cube>
it didn't work on my case
<whitequark>
yes, because of mmap
<whitequark>
O_o
<whitequark>
ulimit -m maps to RLIMIT_RSS.
<whitequark>
ggole: man page lies, apparently, because RLIMIT_RSS surely works for me
<ggole>
:/
<companion_cube>
Specifies the limit (in pages) of the process's resident set (the number of virtual pages resident in RAM). This limit has effect only in Linux 2.4.x, x < 30
<companion_cube>
oooook, won't use RSS
<whitequark>
okay, I've checked and it doesn't work.
<whitequark>
wtf.
<ggole>
Strange option.
nicoo has joined #ocaml
<ggole>
Poking around, seems _RSS is a bit of an atavism."I am wondering why setrlimit for RLIMIT_RSS is not enforced?"
<flux>
you can set the virtual memory size
<flux>
indeed the amount of data in resident (actual) memory cannot be limited
<flux>
it would probably affect memory mapping and swapping etc; limiting virtual memory has been good enough for me to prevent firefox from eating all the memory :)
Thooms has quit [Quit: WeeChat 1.0.1]
<def`>
what happens if it tries ? firefox is killed?
<whitequark>
yes
<whitequark>
companion_cube: it's possible to limit "real" memory with cgroups
<whitequark>
functions push and pop the stack map entries into a global variable
<whitequark>
well, that's how it's done with the shadow stack collector, at least.
<whitequark>
it's a really bad one. very slow.
<whitequark>
I would recommend you check out Boehm for your use case, it's a good low-effort collector.
slash^ has joined #ocaml
<artagnon>
Boehm isn't precise, no?
<whitequark>
if you want decent precise GC, wait until the recent GC work gets merged
<whitequark>
Boehm is not.
<whitequark>
it can be made precise in heap, I believe, but not easily on stack.
jbalnit has quit [Remote host closed the connection]
<artagnon>
I want to get some gc working with llvm, so I understand what the problems are.
<artagnon>
I didn't understand the shadow-stack example; where is the handle to the global variable?
<artagnon>
The declaration StackEntry *llvm_gc_root_chain; is in the runtime.
<artagnon>
Or does the runtime declare the global variable for the plugin to pick up?
* artagnon
is confused
<jpdeplaix>
artagnon: I'm currently doing a copying GC with llvm
<artagnon>
To access the stack map, use GCFunctionMetadata::roots_begin() and _end() << this is the best explanation I found.
<artagnon>
jpdeplaix: Nice!
<jpdeplaix>
(for my own language but maybe it can help for you)
<artagnon>
How does the gc connect to the plugin?
<jpdeplaix>
I don't use the plugin system :D
<artagnon>
Huh? How do you print out a stackmap for the gc to consume?
jbalnit has joined #ocaml
ollehar has joined #ocaml
<artagnon>
I understand how shadow-stack connects. It hardcodes a global variable name.
_5kg has quit [Ping timeout: 255 seconds]
sepp2k_ has quit [Quit: Konversation terminated!]
jwatzman|work has joined #ocaml
jwatzman|work has quit [Client Quit]
jwatzman|work has joined #ocaml
<ggole>
"ML's syntax is indeed less confusing than OCaml's. And that's the reason I'm working on a compiler front-end replacement for OCaml"
<ggole>
Didn't we have one of those already?
<def`>
revised syntax ? Well, it's more an alternative parser than an alternative front-end
<def`>
The type system is the same
artagnon has left #ocaml [#ocaml]
<ggole>
I can't argue that the existing syntax is wartless, but backwards incompatible changes don't seem like a great path forward.
boogie has joined #ocaml
<def`>
Yes, but the way this guy is presenting his project makes me think he works with another type system
<def`>
So unrelated (and I agree that a revised syntax is not a good idea)
rand000_ has quit [Ping timeout: 260 seconds]
<ggole>
Oh, hmm
<whitequark>
hrm, artagnon quit :/
elfring has quit [Quit: Konversation terminated!]
nojb has quit [Quit: nojb]
ollehar has quit [Remote host closed the connection]
ollehar has joined #ocaml
Thooms has joined #ocaml
araujo has quit [Ping timeout: 256 seconds]
dsheets has quit [Ping timeout: 256 seconds]
kakadu has quit [Quit: Page closed]
hhugo has joined #ocaml
hausdorff has quit [Remote host closed the connection]
hausdorff has joined #ocaml
_5kg has joined #ocaml
hugomg has joined #ocaml
hausdorff has quit [Ping timeout: 258 seconds]
f[x] has quit [Ping timeout: 244 seconds]
rand000 has joined #ocaml
<_obad_>
is there an official way of using sexp and lwt together?
<ggole>
heh: 'Not_found' seems to originate from 'Not_found' whose ML file could not be found
<ousado>
ggole: is that a quote?
<ggole>
That's merlin telling me that it doesn't know where Not_found is (I ran locate on it by accident)
<ousado>
ah
<ousado>
not even merlin can find the origin of exceptions
bytbox has joined #ocaml
<ggole>
It can, but my stdlib installation doesn't keep the necessary files around
<ggole>
I just found the wording amusing, that's all
kakadu has joined #ocaml
<def`>
ggole: report issue, locate might simply not search for exceptions :'
<ggole>
It seems to find the ones I define.
<ggole>
def`: but what's the "seems to originate from" about?
BitPuffin has quit [Read error: Connection reset by peer]
ollehar has quit [Ping timeout: 245 seconds]
<def`>
ggole: looking for not_found.cmt
<ggole>
Oh, it thinks it might be a module
<ggole>
Right!
marynate has quit [Quit: Leaving]
hhugo has quit [Quit: Leaving.]
<Unhammer>
so I wanted to try ppx_deriving, how do I get utop to give me a "show" function?
<Unhammer>
if I do
<Unhammer>
type t = [ `A | `B of int ] [@@deriving show];;
<Unhammer>
I just get
<Unhammer>
type t = [ `A | `B of int ]
<Unhammer>
did
<Unhammer>
#require "ppx_deriving.show";;
<Unhammer>
though it seems something more is required
<Unhammer>
that is, utop requires me to require something more
<whitequark>
Unhammer: do you have ppx_deriving 1.0 and utop 1.15?
hausdorff has joined #ocaml
<Unhammer>
utop 1.15
<Unhammer>
oh my ppx_deriving is just 0.3
<Unhammer>
though I just installed it
<Unhammer>
whitequark, should utop handle show after that "#require ppx_deriving.show"?
larhat has joined #ocaml
hhugo has joined #ocaml
hausdorff has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
c74d has quit [Remote host closed the connection]
<whitequark>
Unhammer: with ppx_deriving 1.0
<whitequark>
please upgrade from 0.3, 0.3 used a questionable method for loading deriver plugins
<Unhammer>
aha, guess I'll just wait until it hits opam, just wanted to play around with it
hausdorff has joined #ocaml
<whitequark>
it should've hit opam already.
<whitequark>
oh. it's not. sigh.
<whitequark>
what the hell, I updated my PR *five hours ago* and it's *still* in the build queue?
<whitequark>
Travis is so broken.
<Unhammer>
reimplement it in ocaml!
<Unhammer>
:)
c74d has joined #ocaml
<mrvn>
How does it decide what to build first? I never noticed a delay.
<whitequark>
mrvn: chronological order.
<whitequark>
the issue currently is that OS X workers are 1) very busy 2) very, very, very slow 3) hold up the whole queue.
<mrvn>
I guess my tuests don't include OS X
elfring has joined #ocaml
<Drup>
mrvn: in case of opam, they are very slow because they recompile the compiler each time
<Drup>
(yes)
<whitequark>
Drup: because the OS X workers are awfully slow and apart from compiler, they also reinstall homebrew every single time
<Drup>
ggole: what was this quote about OCaml/ML from ?
<whitequark>
it's multiple levels of terrible, to be honest
oscar_toro has quit [Quit: Leaving.]
oscar_toro has joined #ocaml
Simn has quit [Quit: Leaving]
<ggole>
Drup: in a discussion about that ancient SML/OCaml comparison page, somebody on HN wrote that comment
<whitequark>
>HN
<whitequark>
you could stop there, really
ollehar has joined #ocaml
<ggole>
Yeah, pretty much
<Drup>
ggole: no link, I presume
hhugo has quit [Quit: Leaving.]
<ggole>
To anything concrete about the proposal? No.
<Drup>
ahah, and jdh is in this thread
<Drup>
okay, you can't get more fabulous than that anyway
bytbox has quit [Remote host closed the connection]
Bluddy has joined #ocaml
lordkryss has joined #ocaml
Denommus has quit [Ping timeout: 245 seconds]
slash^ has quit [Read error: Connection reset by peer]
Nahra has quit [Remote host closed the connection]
cdidd_ has quit [Remote host closed the connection]
hausdorff has quit [Remote host closed the connection]
Nahra has joined #ocaml
cdidd has joined #ocaml
hausdorff has joined #ocaml
Denommus has joined #ocaml
<adrien>
just went over the discussion on HN
<adrien>
tomorrow we'll probably get the "ocaml sucks" page linked to
<adrien>
too*
<adrien>
since we're getting things from the attic, might as well pull that one
hhugo has joined #ocaml
ggole has quit []
samrat has quit [Quit: Computer has gone to sleep.]
manizzle has quit [Ping timeout: 260 seconds]
hausdorff has quit [Remote host closed the connection]
<dmbaturin>
adrien: OCaml sucks page? Where is it, I'd like to read. :)
<dmbaturin>
Also, what is HN?
<adrien>
try any search engine
<adrien>
HN = hacker news, i.e. news.ycombinator.com
<adrien>
once you've found the "ocaml sucks" page, you'll understand why it's actually good to be able to force google to take down results about you
<whitequark>
well, ocaml is not a person
<adrien>
(summary: because google ranks higher links on which people click, which are usually links at the top of the results, so you get a positive feedback loop without control)
<whitequark>
that page is a mix of legitimate complaints and complete bullshit, though
<Drup>
and outdated things
<adrien>
it's written by someone who likes lisp
<dmbaturin>
I remember a number of pages stating that ocaml sucks, so the question is really "which one".
<adrien>
and its age is the worst factor
<adrien>
I can't understand how it's still around
<adrien>
dmbaturin: just look for "ocaml sucks"
hausdorff has joined #ocaml
araujo has joined #ocaml
<dmbaturin>
Now I remember what I actually wanted to ask. It seems in SML lots of functions from pervasives take tuples, while their ocaml counterparts are curried. What are the (possible) reasons for it?
<Drup>
bad design ? :D
<Drup>
(in SML)
sinelaw has joined #ocaml
<dmbaturin>
Well, I haven't written an ML compiler yet, so I can't reason about its implications, other than that tuple are annoying to write. :)
<sinelaw>
can anything go wrong if refs are allowed to contain polymorphic functions?
<def`>
dmbaturin: OCaml abstract machine makes it really fast to pass arguments in a curried way
<dmbaturin>
def`: Is it true for native binaries too? Also, any papers or docs I should read about how curried functions actually work in native code?
<def`>
dmbaturin: yes
<def`>
euh, ZINC report as usual
<Drup>
I suppose the zinc paper is still valid
<dmbaturin>
True, I was going to read the ZINC report as someone suggested earlier. Will do it.
<Drup>
which is, in fact, exactly what String.concat is doing
<dsheets>
uhhh :-( at least we have and check md5sums of package tarballs???
<Drup>
whitequark: oh, I see. why does it "hang" ? My understanding is that it was taking forever to compile, hence slowing everything
<whitequark>
Drup: shitty code
<whitequark>
shitty OS
<Drup>
ahah
<whitequark>
it's not *supposed* to hang.
<whitequark>
but OS X under virtualization is very, very bad.
<whitequark>
I'm surprised it works at all.
<Drup>
ok
<Drup>
the only thing I don't like with bors is the amount of noise
<Drup>
bors is very very noisy
<whitequark>
well, I don't have to force the exact same codebase as Mozilla, right?
<whitequark>
don't have to use*
ygrek has quit [Ping timeout: 245 seconds]
<Drup>
you proposed it, I'm just commenting :p
manud has quit [Quit: manud]
SomeDamnBody has joined #ocaml
Hannibal_Smith has quit [Ping timeout: 272 seconds]
WraithM has joined #ocaml
ustunozgur has quit [Quit: Leaving...]
<whitequark>
hm, can't sleep anyway
<whitequark>
might as well set up buildbot
SomeDamnBody has quit [Ping timeout: 265 seconds]
<sheijk>
hm, is there a way to print Parsetree.expression to debug generated code? can't see how to use the ppx_tools dumper on code i generated myself right now
<whitequark>
Pprintast.expression fmt expr;;
<whitequark>
where fmt is a Format.formatter
<Drup>
sheijk: "ocamlfind ppx_tools/rewrite"
<Drup>
rewriter*
<whitequark>
yup, that is useful as well
<sheijk>
whitequark: ah, cool. is there some overview of the modules related to or useful for ppx filters or just "anything in the compiler source"?
hausdorff has quit [Remote host closed the connection]
<whitequark>
it's basically just Pprintast and Pparse
<whitequark>
for everything more advanced you will need to delve deep into the compiler source anyway
<Drup>
it's more like "basically under parsing/"
<Drup>
+everything
<Drup>
and ppx_tools
madroach has quit [Ping timeout: 250 seconds]
<sheijk>
ppx_tools doesn't have the rewriter tool in my installation (installed using opam). but would it be useful when i'm generating invalid code, anyway? (was doing something like [%expr [%e list_var] :: ""])
hausdorf_ has joined #ocaml
<whitequark>
upgrade ppx_tools
madroach has joined #ocaml
<whitequark>
oh
hausdorf_ has quit [Remote host closed the connection]
<whitequark>
it's not released yet
<sheijk>
ah, 0.99.2 helps
<whitequark>
pin it.
hausdorff has joined #ocaml
<whitequark>
really?
<whitequark>
oh, I see, it does
<sheijk>
yep. now seeing ~/.opam/4.02.0/lib/ppx_tools/rewriter after opam upgrading it
<sheijk>
ah, nice. rewriter even works if i'm generating invalid code. yay
nojb has quit [Quit: nojb]
<whitequark>
yes, it doesn't typecheck or anything
NoNNaN has quit [Remote host closed the connection]