<Drup>
You want a printf-like notation for ppx in order to un-nest them ? :)
<whitequark>
NO
<whitequark>
whitequark.org/no
<Drup>
oh !
<Drup>
it's so cute
pjdelport has quit [Quit: Connection closed for inactivity]
<Drup>
why the strong objection, by curiosity ?
<Drup>
I can think of multiple reasons :p
troutwine_away is now known as troutwine
<whitequark>
I find the current printf syntax ... barely passable in a language like OCaml
<whitequark>
and the current format syntax thoroughly disgusting
<Drup>
ahah
<whitequark>
printf should be basically
<whitequark>
Printf.printf "the value of i is: {i}"
<Drup>
but you can't curry that !
<companion_cube>
agree with Drup
<whitequark>
80% of the time I don't want to
<companion_cube>
I do :p
<companion_cube>
also, what about %a ?
<Drup>
whitequark: and how would you compose printers ?
<whitequark>
that desugars to %a
<Drup>
and how do you magically decide which printer to use ?
<whitequark>
oh, right, need type-driven decisions
<whitequark>
grmbl
<Drup>
:D
<whitequark>
I'll still make ppx_quasiquot, because I'm insane
<whitequark>
using the substitution technique I elaborated earlier
<Drup>
whitequark: this work just fine in a language without global type inference
<Drup>
(or with lot's of introspection)
<whitequark>
ocaml doesn't have global inference?
<Drup>
it does, my point
<Drup>
"this = type-driven code generation"
<Drup>
(a field which deserves a lot of research grants, because there are lots of stuff to do)
thomasga has joined #ocaml
<whitequark>
I'll just put a "let __var$i = assert false" there and substitute %a arguments with __var$i
<def`>
One could imagine gathering a set of constraints and eventually call an external extension to generate an implicit instance
<whitequark>
and look what type typechecker will assign
<whitequark>
brutal. but efficient.
troutwine is now known as troutwine_away
<Drup>
whitequark: (did you know : it's basically what eliom is doing ...)
<whitequark>
hah!
<whitequark>
I didn't even know that eliom needs that
<whitequark>
(but it is obvious in retrospect)
pjdelport has joined #ocaml
<whitequark>
ooooh I'm going to give a lightning talk on Eliom at a Rails conf in russia
<Drup>
the client/server typing is a mess
<whitequark>
TODO: actually learn eliom
<whitequark>
(cough)
<Drup>
whitequark: well, there is a video about ocsigen from OUPS :)
<Drup>
whitequark: your idea is simple on paper
<Drup>
and it almost work
<Drup>
until you mix polymorphism in
<Drup>
and then, everything explode
<whitequark>
example?
<whitequark>
oh, like 'a list ?
<whitequark>
it'll derive a value with a free type variable
<whitequark>
a type*
<Drup>
No, like "the type is fixed by the client but the server doesn't know it because the inference is no bidirectionnal"
<whitequark>
I'll pattern-match the generic signature of Show over that and it'll work
<whitequark>
oh, in Eliom
<Drup>
in general, if you have two universe (inside and outside the quotation) that needs to communicate their type constraints.
<Drup>
fortunately for you, you don't need it for basic printing
<whitequark>
yes...
penglingbo has quit [Ping timeout: 240 seconds]
<whitequark>
you could *maybe* marry the two typing environments
<Drup>
yes
<Drup>
I will work on that around septembre
<Drup>
september*
<Drup>
I expect it to be acrobatic :D
<whitequark>
lol
<bernardofpc>
Drup: where do you work?
<Drup>
in september, i will work in the ocsigen team, basically
<Drup>
for now, in the verimag lab
<bernardofpc>
is that INRIA-related ?
<Drup>
french-research-that-is-not-inria :D
<bernardofpc>
CNRS ?
<bernardofpc>
hum, Grenoble
thomasga has quit [Quit: Leaving.]
jwatzman|work has quit [Quit: jwatzman|work]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
avsm has joined #ocaml
beanrustler has joined #ocaml
oriba has quit [Quit: oriba]
<beanrustler>
Beginner question: I'm trying to run Sys.command inside an infinite while loop and I'm getting a type error. Has int, expects unit. Can anyone offer some guidance? Many thanks.
<whitequark>
ignore (...)
<whitequark>
i.e. ignore (Sys.command ...)
hausdorff has quit [Remote host closed the connection]
strmpnk has joined #ocaml
englishm has joined #ocaml
<beanrustler>
whitequark: Wow, thanks; that certainly cleared it up. Would it be too much to ask why that's needed, or to have a reference to an explanation?
<whitequark>
the idea is that purely side-effecting expressions have type `unit', and while is fundamentally an imperative construct
<whitequark>
so the return type of whatever's inside is unified with unit
hausdorff has joined #ocaml
<tobiasBora_>
Does anyone has ever see this error "cannot load shared library dlllwt-unix-stubs" ?
<whitequark>
ohhh, I remember something like that
<tobiasBora_>
(I get it when I run a bytecode of my app on windows)
<whitequark>
oh, windows, so not opam. no idea then
englishm has quit [Remote host closed the connection]
englishm has joined #ocaml
<tobiasBora_>
But the bytecode isn't supposed to pack all libraries ?
<whitequark>
hm?
<whitequark>
try building with -custom
englishm1 has joined #ocaml
<tobiasBora_>
Great that's the solution I didn't though about that thank you !
Denommus has joined #ocaml
troutwine_away is now known as troutwine
hausdorff has quit [Remote host closed the connection]
craigglennie has quit [Quit: craigglennie]
<tobiasBora_>
Grrrr.... I just link the Batteries library to my project (I don't use any function) and it calls the unknow C primitive wait_pid...
<tobiasBora_>
Why is it raised even if I don't call any function ?
troutwine is now known as troutwine_away
q66 has quit [Quit: Leaving]
beanrustler has quit [Quit: Page closed]
tristero has quit [Ping timeout: 240 seconds]
tristero has joined #ocaml
tobiasBora_ has quit [Quit: Konversation terminated!]
englishm has quit [Remote host closed the connection]
englishm1 has quit [Quit: Leaving.]
<Drup>
there is show with a pp, no point of dump
penglingbo has joined #ocaml
englishm has joined #ocaml
<Drup>
oh, actually dump also does *un*marshalling
<tautologico>
Default is useful when you're programming with traits / type classes
<whitequark>
out of what?
<tautologico>
not the case in OCaml
<Drup>
whitequark: the thing that Dump outputs ? :D
<whitequark>
I don't want to see the source
<Drup>
Enum is mostly pointless
<Drup>
I would rather have an Iter, and use companion_cube's sequence
<whitequark>
Iter?
<Drup>
derive an Iter function.
<Denommus>
Drup: Enum?
<Drup>
Denommus: link above
englishm_ has joined #ocaml
<Drup>
oh, no, Enum is not an enumeration
<Drup>
meh
englishm has quit [Read error: Connection reset by peer]
<Denommus>
Drup: aaah, it's like an Enumerator. I was thinking of a tagged union
<Drup>
those modules are badly named
<whitequark>
am currently wondering if having [@@deriving Eq] create val equal_t : ... is bad
<whitequark>
maybe I shouldn't have blindly cargo-culted the names from Rust
tidren has quit [Remote host closed the connection]
<whitequark>
but I kinda like them
<Drup>
hum ? what do you mean ?
<Denommus>
whitequark: are you learning OCaml from a Rust background?
tidren has joined #ocaml
<Drup>
there is no such thing as a "Rust background"
<whitequark>
Denommus: no
<whitequark>
also what Drup says
<Drup>
Rust is too young for that
<whitequark>
but I've only seen deriving in Rust
<Denommus>
Drup: hehe, you have a point.
<Drup>
whitequark: it comes from haskell
<whitequark>
yes
tidren has quit [Read error: Connection reset by peer]
<whitequark>
oh, that's Eq and Ord there, too
<Drup>
what is the naming scheme in Rust ?
<Drup>
yes
tidren has joined #ocaml
<whitequark>
Show, Eq, Ord, Rand, Hash, Clone
<Denommus>
but then, if the first statically typed language with a decent type system you have ever seen is Rust, then... well, OCaml is more approachable from Rust than from lots of mainstream languages
<Drup>
and Show
<whitequark>
now that we have open-types, can do deriving(Dyn)
<Drup>
hum
<Drup>
what would it do ?
<Denommus>
I know more Rust than Haskell and now I'm trying to learn OCaml, for instance. And I already think I like it more than Haskell because of the module system
philtor has joined #ocaml
divyanshu has joined #ocaml
<Denommus>
though a friend of mine is making me want applicative functors instead of generative ones. I just don't know how much the lack of applicative functors affect OCaml, though, since it is structurally typed
<whitequark>
Drup: type dyn += Dyn_foo of foo = Dyn.t ;; let dyn_of_foo x = Dyn_foo x ;; let foo_of_dyn d = match d with Dyn_foo x -> Some x | _ -> None
<Drup>
oh, t @@deriving Dyn would add a t case to a predefined universe type
<Drup>
huum.
tidren has quit [Remote host closed the connection]
<whitequark>
well, you could say
<Drup>
I'm not sure how useful it is, it's not really an idiom I have in ocaml
<whitequark>
@@deriving Dyn { t = "Foo_dyn.t" }
englishm has joined #ocaml
tidren has joined #ocaml
englishm_ has quit [Remote host closed the connection]
<companion_cube>
elfring: what do you mean by configuring a comparison function?
<elfring>
companion_cube: When would you dare to select a comparison approach which will be different from the function "compare" of the standard library?
<companion_cube>
I often do, because I need specific behavior (mostly ignoring parts of the values)
<whitequark>
compare is also slow
troutwine is now known as troutwine_away
<Drup>
specialize compare is ok, isn't it ?
<Drup>
(poly compare is very slow indeed)
<whitequark>
but it won't specialize for complex structures
<Drup>
indeed
<Drup>
(a shame, since it would be quite fast on variants, since they are basically ints ...)
* whitequark
mumbles something about deriving Ord
<Drup>
:)
<companion_cube>
:)
* companion_cube
went the combinators way
<companion_cube>
but both can be combined ;)
<elfring>
Do you pass your special comparison functions around for some applications?
<algoriddle>
They have to go after them, if they care.
<Drup>
I won't bet on inria to do anything for the ocaml community
<Leonidas>
also, ocamlpro does afair quite a lot for the community, too
<Drup>
(and also, lefessan is technically inria research)
oriba has joined #ocaml
<Drup>
(he's just "delegated" to ocaml-pro as scientific consultant)
holomorph has joined #ocaml
arjunguha has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hausdorff has quit [Remote host closed the connection]
<Drup>
but "We own the domain and we want visibility, so we just force you to go through our website" is ridiculous, I understand the reason, but it's not a behavior I find acceptable, even if ocaml-pro is doing good stuff for the community.
<Leonidas>
but it is their website, after all
<Drup>
what is ?
<Leonidas>
ocaml-lang.org
<Leonidas>
*domain
<Leonidas>
if I own ocaml-sucks.org, I doubt anyone would want me to redirect to ocaml.org ;)
<Drup>
I never said they didn't have the *right* to do it, I said I don't find this behavior acceptable from lefessant
<ggole>
Bit domain squatty :/
<def`>
ggole +1
<Drup>
exactly what ggole said.
<Leonidas>
a bit, maybe.
<Leonidas>
and trademark-wise it is odd, since they even have OCaml in their name.
hhugo has joined #ocaml
englishm_ has quit [Remote host closed the connection]
englishm has quit [Quit: Leaving.]
zpe has joined #ocaml
Thooms has joined #ocaml
Eyyub has joined #ocaml
hausdorff has joined #ocaml
englishm1 has joined #ocaml
englishm_ has joined #ocaml
<Kakadu>
Shit
<Kakadu>
Second guy can't compile lablqt
<Kakadu>
Becuase Qt-developers can't fix pkg-config for Mac
<Kakadu>
I will be glad to fix it myself but I do not have Mac at all
zpe has quit [Ping timeout: 240 seconds]
FreeArtMan has quit [Ping timeout: 240 seconds]
hhugo has quit [Quit: Leaving.]
Eyyub has quit [Ping timeout: 245 seconds]
hhugo has joined #ocaml
troutwine_away is now known as troutwine
<whitequark>
orbitz: what is the rationale behind making them look like functor applications?
<whitequark>
I don't see any reason to do that.
<orbitz>
because i want to seperate out what something can be from what it is
<orbitz>
whitequark: Like we discusssed in your protobuf email, I want to generate a module that can generate and consume my type with protobufs, I don't want it to be part of my type defintion
<Drup>
orbitz: this issue is that the deriving mecanism is syntactic
<Drup>
you *need* the type definition
<Drup>
you can't derive anything without it
<companion_cube>
can't the ppx retain the type definition in memory ?
tac_ has quit [Quit: Goes to gym]
<companion_cube>
because I agree, deriving stuff on foreign types would be nice
<Drup>
accross compilation unit ?
<companion_cube>
(open types, that is)
<Drup>
errr
<Drup>
yes, but please do write the infrastructure for it, because I don't want to.
<orbitz>
Drup: for protobufs I don't, I just need an interface for the type
<pippijn>
whitequark: why did you choose to make ppx_deriving incompatible with the original deriving (which does the module thing)?
<orbitz>
for any serializer
shinnya has joined #ocaml
<companion_cube>
cough GADT cough
<whitequark>
pippijn: original deriving is not widely used, so compatibility is not an issue;
<Drup>
huuum
<Drup>
it isn't ?
<whitequark>
additionally, it has an extension for using the derived types, Show<t> or something, that can't be reproduced without camlp4
<companion_cube>
Drup uses it, so it's widely used
<Drup>
I don't really use it, actually
<pippijn>
whitequark: Show<t> is "short" for Show_t
<Drup>
except for eliom-related stuff
<whitequark>
pippijn: so I decided to just generate the code that exists on its own in the OCaml ecosystem
* companion_cube
coughs more
<Drup>
orbitz: by "interface" what do you mean
<Drup>
orbitz: be precise, is it a module, what does it contains, is it ppx time, compile time or run time ?
<whitequark>
yes, I want ppx_deriving to generate the code at compile-time
<whitequark>
traversing GADT descriptions is hardly more useful than just polymorphic compare
<orbitz>
consider sig type t val get_x : t -> int val set_x : int -> t -> t end. I want to do module Protobufified = Protobuf.Make(MyThing)
<orbitz>
but MyThing is really any interface as long as it as setter's and getter's an some type t
<Drup>
but it's far less powerful than a full deriving mechanism.
<whitequark>
what? how would you even use that with Protobuf
<Drup>
I mean, it's just a simple functor application ...
<orbitz>
NO
<orbitz>
No*
Hetu has quit [Quit: Verlassend]
<orbitz>
I'm saying I want it to look like that
<orbitz>
and be semantically like it
<orbitz>
but it's actually creating this module by generating code
<Drup>
I'm not sure I see the point =__=
<orbitz>
because then I acn do module XMLified = XMLifier.Make(MyThing)
<Drup>
I mean, if you generate code only using an interface, you're just reinventing functor application
<orbitz>
and I can do module JSONified = JSONifier.Make(MyThing)
<whitequark>
and what is the point of that?
englishm_ has quit [Remote host closed the connection]
englishm1 has quit [Quit: Leaving.]
<orbitz>
Drup: the difference is the actual code is based on the names of the interface elements
mort___ has joined #ocaml
<Drup>
is it ?
<orbitz>
whitequark: the point would be taht anyone can use my type with wahtever serializer they want without me caring
paddymahoney has quit [Remote host closed the connection]
<orbitz>
currently with ppx_protobuf the type defintion is intermingled with the fact that it's going to be serialized via protobuf
englishm has joined #ocaml
<orbitz>
i want to decouple these things
<whitequark>
then the introspection must happen at runtime
philtor has joined #ocaml
<whitequark>
well
<whitequark>
how would you add protobuf annotations to fields with your system?
<orbitz>
No it musn't
<whitequark>
then that's just impossible.
<Drup>
orbitz: I think I need an exemple to show me how it's not just functor application.
<whitequark>
both syntactically and semantically.
zpe has quit [Remote host closed the connection]
englishm has quit [Remote host closed the connection]
<orbitz>
Drup: because functors require a conceret interace
<orbitz>
I want to take interface swith names like set_* and get_*
englishm has joined #ocaml
<orbitz>
and turn them into code
englishm_ has joined #ocaml
<Drup>
but you have one, you have get and set.
<orbitz>
Drup: I want to take any module with get_* and set_* and produce protobuf code
<whitequark>
orbitz: I don't think you understand what problem deriving solves
<whitequark>
because it is not possible to "take any module with get_ and set_ and produce protobuf code"
<orbitz>
why isn't it?
<whitequark>
this simply doesn't make sense, I'm not aware of any way you could derive protobuf encoding from that
<whitequark>
you don't have enough information, and the interface is simply unsuitable
<companion_cube>
orbitz: what would "MyThing" look like ?
<Drup>
orbitz: so, you are reinveting functor application just to handle the fact that you want get_x instead of get ? this is silly ...
<orbitz>
companion_cube: anything with a type t and functions that looke like set_* and get_*
<companion_cube>
I don't see what set/get means in this case
<orbitz>
Drup: no, I want to look at the module and get all functions taht look like get_* and set_*
<orbitz>
companion_cube: just getters and setters on some type
<companion_cube>
for instance if I have a type complex={re:float; img:float} ?
<companion_cube>
what's getter/setter ?
<orbitz>
get_re, set_re
<orbitz>
val get_re : t -> float val set_re : float t -> t
<bitbckt>
maybe you're referring to something similar to https://github.com/facebook/swift, but uses value names, rather than annotations to generate code?
<companion_cube>
orbitz: that wouldn't work for sum types
<Drup>
orbitz: this is really a very very minor issue to design such a complex thing
<orbitz>
Drup: how so? functors cannot do this, and i want code generated at compile time
<whitequark>
orbitz: that wouldn't work for sum types or tuples or polymorphic types or immutable records
<whitequark>
or basically the majority of ocaml datatypes
<whitequark>
except records with all mutable fields.
<Drup>
orbitz: functor can't do this because you are imposing a miningless constraint
<orbitz>
bitbckt: not quite, specifically i want to decouple the type i've defined with what it can be serialized with
<Drup>
I mean, the only reason is because you want get_t instead of get
* companion_cube
goes back to 'a ty
<Drup>
this is *silly*
<orbitz>
whitequark: why? it returns t on set
<orbitz>
Drup: no i don't want get_t
<whitequark>
orbitz: what? how would you construct a `complex' value
<whitequark>
show this step by step.
<orbitz>
sig type t val set_re : .. val get_re : .. val set_img ... val get_img : .. val create : re:float -> img:float -> t end
<whitequark>
ok
<whitequark>
the short answer is "I don't need that and no code I ever seen needs what you want, so this is not an use case I'm interested in supporting, especially since it is a huge hassle"
<orbitz>
right, i didn't ask you to support it, i just asked if you knew how to do it
<whitequark>
you're basically adding 1) another layer of indirection 2) requiring the ppx to import Typedtree (module definition from some other place)
<Drup>
orbitz: and how do you handle sum types ?
<whitequark>
for no real reason whatsoever
<orbitz>
Drup: I don't know yet
<whitequark>
lol
<Drup>
yeah ...
<orbitz>
whitequark: it is for a reason: decoupling the type defintion from the serializatoin
<companion_cube>
I agree on the part that it would be nice to decouple those
<companion_cube>
very nice even
<companion_cube>
let the user choose
<orbitz>
whitequark: with the current ppx solution, hwat happens if i need to support json too?
<Drup>
orbitz: @@deriving Json
<companion_cube>
that's a big limitation with Core
<whitequark>
you define a type that uses the existing type as manifest
paddymahoney has joined #ocaml
<whitequark>
then add @@deriving Json to that
<companion_cube>
Drup: you can only do this in your code
<orbitz>
whitequark: does that work if it's someone elses type?
<whitequark>
yes
<orbitz>
how does that look then?
<orbitz>
and what if their concrete type is hidden from me?
<orbitz>
(I just have a manipulation API)
<bitbckt>
I see what you mean, now... *click*
<whitequark>
if their concrete type is hidden from you, you don't use *type-driven* code generation
<companion_cube>
that means you can't use any library then...
<orbitz>
whitequark: then that's fine, i want to use signatuer direven code generation or whatever you want to call it
<companion_cube>
whitequark: what do you mean by "use the existing type as manifest"?
<Drup>
that means we could benefit for *one standard tool* for the whole ecosystem.
mort___ has quit [Quit: Leaving.]
<Drup>
from*
<whitequark>
companion_cube: orbitz: let me demonstrate with an example
<companion_cube>
no way a library writer will know which deviring to provide
<companion_cube>
"oh you wanted json? too bad I derived only xml"
<orbitz>
Drup: I'm not sure I'm explaining my goal clearly enough
<orbitz>
Drup: whatever the mechanism: I want to decouple what external formats a type can turn into from the defintion of the type
<Drup>
orbitz: I think I got the goal right, I disagree completly with the method, however
<orbitz>
Something that looks like functor application seems like an obvious starting point
<whitequark>
so for example, you have Pervasives.fpclass
<whitequark>
and you want to derive Show for it
<Drup>
and afa the goal goes
<whitequark>
that's what you say, yes?
<orbitz>
whitequark: for the simplest case, yes
<Drup>
I would prefer a @@deriving companion_cube's GADT serializer thing
<companion_cube>
^^
<Drup>
this would be actually correctly designed
<orbitz>
Drup, companion_cube what is that?
<Drup>
instead of trying to piggy back functor application syntax for something different
<companion_cube>
it's a GADT that describes the structure of a type
<orbitz>
Drup: like i said, functor application seems a reasonable starting point, but i don't really care waht it looks like as long as it's not intermingling the type defintion with the serialization
<companion_cube>
whitequark: tht wouldn't work for private types :/
<whitequark>
without rewriting the type, where would you specify all those attributes?
<whitequark>
and for the really simplest case I will write another ppx, that imports Typedtree and uses Untypetree to write the plain definition for you
<orbitz>
i could specify those attributes on the API functions
<whitequark>
orbitz: wat?
<whitequark>
no
<whitequark>
you would not know what the user would want to derive
<whitequark>
as you just said
<orbitz>
I know they want an int
<whitequark>
so you wouldn't know to define [@protobuf.encoding varint];;
<orbitz>
what form that int takes on the wire is up to me
<whitequark>
you need to attach attributes to fields or accessors or whatever, invariably
<whitequark>
I do not see your syntax allowing that.
<orbitz>
if this is about concrete syntax just throw that out of your head
<orbitz>
I don't care abou the syntax
<orbitz>
I want to be able to write serializers for types I can't see
<orbitz>
and don't own
<whitequark>
write them by hand.
<whitequark>
since you can't see them, type-driven code generation, by definition, doesn't work
<orbitz>
I know
<whitequark>
if you don't own them, you can use the method I presented above
<whitequark>
not sure about private ones...
<Drup>
orbitz: and anyway, you don't see/own ... but you still except this "MyThing" to be available ?
<orbitz>
I'm arguing there is another option than type-driven code geneation and writing by hand
<nlucaroni>
as in, type x = Module.y [@@deriving Json] or something?
<orbitz>
Drup: what do you mean?
<Drup>
orbitz: the module with the accessors
<orbitz>
nlucaroni: no, I want it at the module level
<Drup>
You expect it to be available
<whitequark>
nlucaroni: type x = Module.y = (original definition with more attributes) [@@deriving Json]
<orbitz>
Drup: yes, or at least the underlying type has a featureful enough API that I can write one
<whitequark>
there is a standardized interface for types
hhugo has quit [Quit: Leaving.]
<Drup>
it's a big assumption.
<whitequark>
because ocaml only accepts one particular syntax
<orbitz>
Drup: not really, most types are pretty useless otherwise
<whitequark>
there is no standardized interface for the serializers that orbitz describes
<orbitz>
whitequark: but types are almsot always hidden
<whitequark>
and I don't even see an emergent pattern among OCaml projects
<Drup>
orbitz: I have enough counterexamples in my mind, but ok.
<whitequark>
orbitz: if the type is hidden, it means you shouldn't use type-driven code generation on it
<whitequark>
simple as that
<Drup>
whitequark: well, there is companion_cube's thingy, but it's slightly too ivory tower (to use your own vocabulary) to be used. (and companion_cube doesn't really advertise it)
<orbitz>
whitequark: I know, as I said i'm arguing for somepalce between type deriven and written by hand
<whitequark>
I think a ppx_deriving module that generates GADTs for companion_cube's thing may be a good idea
hausdorff has quit [Remote host closed the connection]
jwatzman|work has joined #ocaml
nojb has joined #ocaml
ollehar has quit [Ping timeout: 250 seconds]
hausdorff has joined #ocaml
<companion_cube>
whitequark: are you sure Eq is similar to (==) and not (=) ?
<whitequark>
(=) of course
<whitequark>
ugh
<companion_cube>
you should fix you readme
<companion_cube>
aww, looks like deriving Ord doesn't make the type an instance of OrderedType
FreeArtMan has joined #ocaml
<companion_cube>
becuase it's compare_foo and not just compare
hausdorff has quit [Remote host closed the connection]
<Drup>
companion_cube: { suffix = "" }
<Drup>
(until whitequark implemented the clever heuristic)
<nojb>
I am trying to make Graphics_js.open_graph work with no success. I get a javascript error: "Graphics.open_graph: cannot open the window" Any ideas?
<whitequark>
Drup: that doesn't work yet though
<Drup>
nojb: the whole code ?
<Drup>
whitequark: oh :D
<whitequark>
Drup: for reasons which will be clear later
<companion_cube>
my true concern is more that you'll have to tell explicitely that Foo.t is compared using Foo.compare
<nojb>
test.ml: let _ = Graphics_js.open_graph " "
<whitequark>
tomorrow I guess
troutwine is now known as troutwine_away
<nojb>
compile with js_of_ocaml +graphics.js test.ml
<nojb>
Drup: sorry for the nagging, but after putting the appendChild call in there I get a javascript error: "'null' is not an object (evaluating bT.body.appendChild)" ... do you know why this happens ?
<Drup>
put your script at the end of the file
<nojb>
brilliant! it worked!
<nojb>
thanks!
philtor has joined #ocaml
englishm1 has joined #ocaml
english__ has joined #ocaml
agarwal1975 has joined #ocaml
philtor has quit [Ping timeout: 250 seconds]
troutwine_away is now known as troutwine
englishm_ has quit [Ping timeout: 264 seconds]
englishm has quit [Ping timeout: 272 seconds]
philtor has joined #ocaml
tautologico has joined #ocaml
troutwine is now known as troutwine_away
hausdorff has quit [Remote host closed the connection]
tormar has quit [Ping timeout: 250 seconds]
hausdorff has joined #ocaml
mort___ has joined #ocaml
<hhugo>
nojb: Graphics_js.open_graph should work but you might need to way the document to be ready.