<wmeyer>
def-lkb: small, means, done in weekend :-)
<wmeyer>
and then we can publish it on a webpage
<wmeyer>
I strongly support it.
<def-lkb_>
hello wmeyer
lamawithonel_ has quit [Read error: Connection reset by peer]
lamawithonel_ has joined #ocaml
<wmeyer>
for instance there are batteries there is core and there is extlib but sometimes I just want basic super-combinators like (<|) or (-|) adn don't want to link to the big libraries
<wmeyer>
other idea, a shell library, want to spawn some commands in shell, but don#t want to link to whole ocamlnet or use just use Unix module
BitPuffin has quit [Quit: WeeChat 0.4.2]
<wmeyer>
ping adrien
<def-lkb_>
mmm, ok
<wmeyer>
how many times you wanted to use (|>) and needed to declare it yourself
BitPuffin has joined #ocaml
<wmeyer>
why not to add "-tags 'package(simple)'" to your ocamlbuild commands
<def-lkb_>
open a request to add |> in standard library :)
<wmeyer>
that would be nice yes :-)
<wmeyer>
I think we all agreed that |> should be a backward infix application
q66 has joined #ocaml
<gasche>
was def-lkb_ joking? |> is in 4.01
<gasche>
the "small libraries" I would personally consider writing are small domain-specific libraries
<def-lkb_>
gasche: right, but I wasn't aware of that addition
<gasche>
to parse and produce one file format, interact with one successful (but not too large) other-language library, etc.
<def-lkb_>
do you have specific formats or libraries in mind ? (to start with)
<gasche>
the problem is that I don't have much of a use of these libraries today, and it feel weird writing libraries that you don't consider using yourself on the long-term
<gasche>
well
<gasche>
OpenCV, Midi, a physics engine, I don't know
<Kakadu>
YAML parser
<gasche>
collect all the "I consider using OCaml for my project, do you have a library for X?" questions
<gasche>
exactly, YAML
<Kakadu>
btw, is somebody interested in monadic parser-combinator library with DSL for writnig grammars in BNF-like form? (I have ported it to ocamlbuild recently)
<gasche>
I'm quite sure people would be
<gasche>
there is frequent request for parser-combinator libraries
<gasche>
(there is one that is decent, Jun Furuse's Planck)
<gasche>
(I personally am fine with using parser generators)
eikke has quit [Ping timeout: 272 seconds]
<wmeyer>
Kakadu: BNF is not PEG keep in mind this
<wmeyer>
porting directly a BNF grammar to parsing combinators is error prone
<wmeyer>
but usually grammar files are not huge, so you might find the BNF grammar handy anyway
<whitequark>
gasche: I've seen a midi library for ocaml
<wmeyer>
gasche: I think best time would be before christmas so we can package them in OPAM on a chrismas eve
mcclurmc has joined #ocaml
<wmeyer>
whitequark: that was just an example. How about 3D modelling formats or music tags library, or unit conversion library
<wmeyer>
there is plethora of stuff we can fit to OPAM
<pippijn>
DXF parser
<pippijn>
DXF is quite a common format in commercial vector graphics software
<whitequark>
bindings to libdxf :)
<pippijn>
(autocad)
<whitequark>
you'd probably have to lay your life to rewrite a dxf parser in ocaml
<pippijn>
yes
<pippijn>
but bindings to a library do fine
<wmeyer>
whitequark: bindings are fine too
<whitequark>
one thing which I really like in ocaml is that it's really easy to write robust bindings
<whitequark>
compared to dynlangs like ruby or horribly complicated beasts like jni
<Drup>
gasche: I'm interested to, modulo irl constraints
<gasche>
we could put a call for participation on the caml-list at some point
Patchou has quit [Ping timeout: 245 seconds]
<Drup>
too*
<gasche>
I think that to work well, there should be a bit of preparation done upfront
<gasche>
collecting ideas, and also *examples* and tool recommendatations
<gasche>
ctypes is a good suggestion, but you need an example of non-trivial ctypes binding to point to people to get them rolling
<gasche>
(the further they can go by adapting existing working code *without* a deep understanding of the tool, the better)
<gasche>
something that also needs investigating is how OPAM handles non-pure-OCaml libraries
<gasche>
if I write a libdxf (or xdf or whatever) binding, how should I go at packaging it by the end of the sprint?
<gasche>
finally, I could ask IRILL for a room to gather physically in Paris for people that would be interested; maybe Anil would be ok having people in Cambridge as well (but of course distance participation would be fine as well)
<gasche>
(the point of the physical meeting point is not to be more productive on such an easily decentralizable sprint, but rather to add some social interaction as well)
BitPuffin has quit [Ping timeout: 260 seconds]
olibjerd has joined #ocaml
<gasche>
hm
peterbb has quit [Ping timeout: 272 seconds]
<gasche>
I think we could target December for the actual sprint; in the meantime, I'll make a couple of small-library attempts to get a better idea of the kind of problems participants would run into, and see for physical infrastructure
<companion_cube>
o/
<Kakadu>
gasche: maybe some events like Clojure cup can be useful
<companion_cube>
gasche: about non-pure-ocaml binding packaging, apparently in opam you write a fake package that just checks whether the foreign code is present
<gasche>
ok
<companion_cube>
see conf-foobar packages
<gasche>
Kakadu: I'm already regretting taking one more (albeit small) responsibility here
<companion_cube>
(e.g. conf-gtkviewsource)
<gasche>
don't get me started on more ambitious projects :p
<companion_cube>
which kind of small libraries are you planning to write?
<Kakadu>
No offense, this task is more for OCamlPro than us
<gasche>
I don't know yet companion_cube
<Kakadu>
Drup: Have you ever thought about taking the best parts from RoR and prting it to ocsigen?
<gasche>
last weekend I was inspired
<gasche>
and I spent a few hours browsing the doc of the R ggplot2 package
<gasche>
(and related work)
<gasche>
I'd like to try to adapt the Grammar of Graphics approach to an OCaml library
<gasche>
but that's maybe more than a week-end project
<gasche>
for a "small library" print I'd like to find *small stuff*
<gasche>
the same kind of things as "is there an OCaml library to parse IPv(4,6) frames?" asked on the list recently
<gasche>
or the URL/URI handling library
<adrien>
16:43 companion_cu : gasche: about non-pure-ocaml binding packaging, apparently in opam you write a fake package that just checks whether the foreign code is present
<gasche>
possibly stealing interfaces directly from other-languages libraries
<adrien>
it seems to be the same approach as in godi
<gasche>
(I've heard that Go had a great webserver interface; but I personally wouldn't work on anything competing with ocamlnet)
szacun has joined #ocaml
<gasche>
adrien: it should be, as GODI did it right
<companion_cube>
did you ever use ocamlnet?
shinnya has quit [Ping timeout: 245 seconds]
<gasche>
companion_cube: yes, I used it during this year ICFP contest
<gasche>
I started trying to use ocaml-curl which was lighter
<companion_cube>
wow, so you managed to understand its documentation ^^
<gasche>
but ocaml-curl is not documented
<gasche>
ocamlnet is documented
<gasche>
hm
<companion_cube>
what about cohttp?
<gasche>
I'm not sure what the problem is, I didn't have any trouble with ocamlnet's documentation
<gasche>
I didn't need the server-side part, only a library to send client request to the contest's server
<gasche>
I don't know much about cohttp; it may have fit the bill just as well
<companion_cube>
ah.
<gasche>
but my (extremely limited) experience with ocamlnet was positive : it worked as advertized
<companion_cube>
I tried to grasp how its lightweight threads worked
<gasche>
one thing about the contest is that they returned a lot of weird response codes (not just "OK" and 404); a lot of "lightweight client-side web library" make simplistic assumptions that don't work well with that
<mrvn>
any that don't use simple octet streams for the data?
<companion_cube>
gasche: do you have a list of ideas you would like to see hacked?
<Drup>
I'm more in favor of cohttp because it works well with lwt
<Kakadu>
Drup: Have you ever thought about taking the best parts from RoR and prting it to ocsigen?
<Drup>
Kakadu: what are the best parts of RoR ?
<Kakadu>
No idea yet. :)
<Drup>
yeah, precisely my point.
<Kakadu>
I was listening a message about clojure and RoR few days ago
<Drup>
keep looking, if you find something, do a feature request, but not sure if you will actually do :)
<adrien>
easy?
<Kakadu>
and this people was good at PR
<companion_cube>
fast*
<companion_cube>
:]
<adrien>
to write? :P
<Drup>
Kakadu: that's actually the main point with RoR, they are good at PR
<companion_cube>
safe!
ontologiae has quit [Ping timeout: 272 seconds]
BitPuffin has joined #ocaml
Tamae has joined #ocaml
<whitequark>
Kakadu: Drup: as a person whose career was once built on RoR, I can explain it; I've thought about it a lot
<whitequark>
I think the real strength (and weakness) of RoR is how it allows you to do a lot of things quite ad-hoc: you don't have, for example, explicitly list routes for simple applications, they "just work"
<whitequark>
or same with ActiveRecord, which is horrible, because it conflates persistence and model layer, but also awesome, because 95% of time you're doing really simple queries, and it excels at really simple queries, thus allowing you to not write tons of boilerplate.
ollehar has quit [Ping timeout: 272 seconds]
<whitequark>
from my description of it you'd think that RoR is the new PHP, and some have this point of view, and if we're talking about 1.x and 2.x I would just agree. however, lately a lot of bad code and architecture was fixed, so I think that the concept in general is sound.
<whitequark>
that is: what your users will do *most* of time is solve very simple, typical, slightly varying tasks. make your framework excel at doing that: short, clear and concise. yet, allow to gradually complexity without it becoming unmaintainable spaghetti.
ollehar has joined #ocaml
<Drup>
that's the advantage of favouring a model of application over other, indeed. ocsigen try not do this choice, on purpose.
<whitequark>
it's not just that
<whitequark>
Ruby has very strong introspection and metaprogramming. OCaml... well, it practically doesn't. so a Rails on OCaml is probably impossible.
<whitequark>
(one of the reasons I'm working on my language, which is ML type system with Ruby metaprogramming. :)
<companion_cube>
awww
<companion_cube>
you should rather wish for ocaml-ty to arrive
<whitequark>
one of Rails cornerstones is how it queries your classes and asks if they implement particular interfaces
<companion_cube>
so that you have a description of types and still jeep ocaml
<companion_cube>
keep*
<Drup>
oh yeah, but that's different, that's the usual ability to slap some shit together with highly unsafe languages like ruby. that barely works, but that works "enough".
<whitequark>
with structural typing as OCaml has, that's just impossible.
<whitequark>
Drup: completely disagree.
<mrvn>
on the other hand you far quicker arrive at something that actualy works right
<whitequark>
there is barely any reason OCaml cannot have similar metaprogramming facilities.
<Drup>
depends when you draw the line about metaprogramming
<whitequark>
you *have* to give up some of the eagerness in the language in order for them to be convenient
<mrvn>
and changing the api is a nightmare in weakly typed / duck typed languages
<gasche>
(not the sprint organization itself; I'd like to keep this page general and therefore useful before and after the supposed sprint)
<companion_cube>
whitequark: how do you keep type safety with introspection?
<gasche>
I have a very short list of ideas on this page, please add some more
<Drup>
as companion_cube just said, that's not that easy
<whitequark>
mrvn: Ruby isn't weakly typed
<Drup>
one way is type classes
<companion_cube>
wow, openCV as a "small library" :DDD
<companion_cube>
whitequark: it's very dynamically typed
<Drup>
whitequark: isn't it ?
<mrvn>
s/weak/dynamic/ then
<whitequark>
it's dynamically typed, yes :)
<mrvn>
runtime types suck for maintainability
<whitequark>
Drup: companion_cube: I can go on explaining how my language works for a very long time, so let's try from the other end: How introspection prevents type safety?
<Drup>
afaik, ruby type system is very similar to python's one, wich I know correctly, and python is very weakly typed
<wmeyer>
mrvn: it depends. Normally we say that weak typing means that one is able to convert from one type to another implicitly, whetever it's runtime or compile time
<companion_cube>
whitequark: if introspection is only used to read, it's ok. If it allows to modify, then you need to type-check that hte modification preserves well-typedness
<whitequark>
^ Ruby doesn't do that. 0 != false, etcetc
<mrvn>
wmeyer: the problem is that runtime type checks only show up when you hit the wrong code path
<whitequark>
(it does for numerics, but that's not really a problem)
<mrvn>
wmeyer: a strong static type system shows the error when you compile
<whitequark>
companion_cube: true. I only allow to extend existing classes in the language, not modify their members
<wmeyer>
mrvn: yes, strictness in typing is less useful with dynamic types
<whitequark>
it is much more restrictive than Ruby itself, but I never wanted to do *all* of Ruby tricks. I wanted only the sane ones.
<Drup>
whitequark: isn't that equivalent to typeclasses ?
<whitequark>
Drup: perhaps
<Drup>
so yeah, that's far from the full power of what's usually called, "introspection"
<whitequark>
hm, why so? "introspection" as in reading is unrestricted
<whitequark>
the key part is that I allow to run code before typechecking, which can define methods, query structure of classes, and so on
<mrvn>
whitequark: duck typing?
<whitequark>
mrvn: yes, I have that. I have monomorphization exposed in the language
<gasche>
I think you should write a structured description of your language design somewhere
<mrvn>
I find that duck typing somewhat conflicts with types and class hierachies.
<gasche>
instead of mumbling about it on IRC when people get curious
<whitequark>
gasche: I wrote one, but it seems that it's too hard to understand or something
<gasche>
you'd spend a bit more time on it, but then it can reuse, and also writing stuff down gives you knew ideas
<gasche>
and then ask them for feedback on the document; what should be improved?
<gasche>
Drup, what do you think of whitequark's link?
<whitequark>
(and everyone else here who's curious here, too: ^)
peterbb has joined #ocaml
<mrvn>
isinstance(foo, Bla) doesn't realy make sense with duck typing. There should be a check if foo implements all the functions of class Bla, not if it is a Bla.
talzeus_ has quit [Remote host closed the connection]
<whitequark>
mrvn: isinstance(foo, Comparable). plus, you can just call the functions you want, with the arguments you want.
<whitequark>
if it typechecks, foo is Bla.
talzeus has joined #ocaml
<companion_cube>
gasche: actually I don't have any ideas of small libraries I'd want ^^
<companion_cube>
I'd rather have new language features
<gasche>
you have a couple of weeks to think about some and add them there, please
<companion_cube>
ok
<mrvn>
whitequark: foo should be Comparable if it implements the compare function, not only if it is dreived from Comparable.
<whitequark>
mrvn: the latter *is* ad-hoc, but that's deliberate.
<Drup>
companion_cube: reinvent a new square wheel.
<whitequark>
mrvn: (foo is Comparable) that's how the check works.
<gasche>
the problem is that most well-established OCaml users have focused on a problem domain where they don't need much libraries
<companion_cube>
you should put the link in the topic, if not already done
<gasche>
because we don't have much
<companion_cube>
Drup: I can do this alone :p
<gasche>
or where they themselves developed the libraries they need
<gasche>
(eg. ocamlnet, biocaml, etc.)
<whitequark>
mrvn: it checks whether foo has <, <=, >=, >, ==, !=, <=> with correct signatures.
<Drup>
companion_cube: it's more fun to hack in a room fill with other ocaml people :]
<gasche>
to think about small libraries idea, you must go back the beginner stage
<gasche>
or listen to what *other* people want
<whitequark>
mrvn: there's also a mixin you can use to implement most of those based on <=>.
<companion_cube>
Drup: probably.
<gasche>
or look at what other language communities are doing
<companion_cube>
whitequark: the "compare : 'a -> 'a -> int" is much better
<whitequark>
mrvn: (I could also make <,>,... sugar for <=>, I'm not sure yet. the above is how Ruby does it. Isn't important.)
<mrvn>
whitequark: if your language does that then ok. Other languages check if it is derived from the Compaable class.
<companion_cube>
I'd say lots of things already exist in ocaml, but the problem is how to make them easy to use
<whitequark>
mrvn: yes, java-style interfaces. that's silly. recent trend seems to interpret the class as implementing X if it implements all parts of X, not explicitly says that it implements X.
<whitequark>
(go has this as well)
<gasche>
OCaml had it in 2000 :-'
talzeus has quit [Ping timeout: 246 seconds]
<pippijn>
whitequark: I like it
<whitequark>
companion_cube: well, with typeclasses, yes. however ruby/foundry (my language) both have methods so you gotta have explicit <, <=, etc
<gasche>
(I wouldn't exactly call structural typing a "recent trend" but I'm just joking here)
<mrvn>
whitequark: that's why I said it conflicts with duck typing. Duck ytping implies it doesn't need to say anything, it just have to quack and walk like a duck.
<pippijn>
whitequark: we use smalltalk-inspired object system in perl at my current job
<whitequark>
gasche: C++/Java are earlier than that 2000 so still correct :)
<mrvn>
The odd thing is ocaml objects are more like duck typing.
<companion_cube>
statically checked duck typing
<mrvn>
yep
<whitequark>
mrvn: well, right? if you just implement <=> and friends you will be Comparable, regardless of how you did that
<whitequark>
isinstance(foo, Comparable) is a quick way to check for types of members.
<companion_cube>
which is the good kind of duck typing
<whitequark>
companion_cube: yes
<whitequark>
yes :)
<whitequark>
pippijn: (it) the article? or just duck typing?
<pippijn>
whitequark: the kind of object model you have
<pippijn>
I also like the article
<whitequark>
well, it works like that in pretty much all dynamic languages I know
<whitequark>
the trick is how to add it to static languages :)
<whitequark>
(the article) I also have almost all of the features mentioned actually implemented
<whitequark>
so I can talk about how it works in practice too
<whitequark>
mrvn: (ocaml objects) there's a set of problems with ocaml objects. mainly it's very hard (impossible? I gave up) to implement mutually recursive methods
<companion_cube>
it's not, but type error messages are terrible
zpe has quit [Remote host closed the connection]
<companion_cube>
you just need a self value
<Drup>
whitequark: I'm reading, and it really sounds like poor man typeclasses to me.
zpe has joined #ocaml
<whitequark>
I understand that structural typing and doing everything eagerly are design decisions in ocaml, but they really make life hell :/
<mrvn>
companion_cube: ocaml objects have a self and self type. You just have to specify them.
<companion_cube>
mrvn: yep
<companion_cube>
that's why mutually recursive methods are doable
<whitequark>
companion_cube: I tried to make two objects, a parent and a child, where a parent has a list of children and a child keeps a link to the parent
<mrvn>
and recursive objects work too but due to some bug you sometimes have to lift a type.
<mrvn>
whitequark: that only works with mutables.
zpe has quit [Read error: Connection reset by peer]
<mrvn>
whitequark: or Obj.magic for the root
<whitequark>
I've tried to make typechecker accept it for like three days, including asking in this channel (gasche tried to help me)
zpe has joined #ocaml
<whitequark>
eventually just ditched the objects completely
<whitequark>
even if it is possible, this is not *usable*
<mrvn>
whitequark: it's perfectly usable. You just need Obj.magic to assign the first parent.
<Drup>
urk
<whitequark>
Drup: (typeclasses) well, I think I've seen this or similar technique to be referred to as "ad-hoc typeclasses", which it probably is
<Drup>
mrvn: no, that's not "prefectly usable" when you need Obj.magic
<mrvn>
Drup: it's ugly inside but perfectly usable to use from the outside.
<whitequark>
Drup: I don't consider that part very interesting, the partial evaluator and meta-language are the things I'm proud of
<whitequark>
mrvn: I agree with Drup
<mrvn>
Drup: alternatively you can use a mutable option type. That's clean but otherwise ugly to use.
<whitequark>
the real question is why do I need to jump through weird hoops to implement an extremely common OO pattern?
<whitequark>
I shouldn't have to
<mrvn>
whitequark: because of the value restriction
<whitequark>
mrvn: yes, I understand that, and no, it doesn't make it good
<mrvn>
whitequark: it leas to classes being called before they are initialized or types from being unsafe
<mrvn>
s/leas/leads/
<Drup>
whitequark: the fact is, I don't believe you actually need all that stuff if you have real typeclasses
<mrvn>
and yes, it sometimes sucks.
<whitequark>
(in Foundry, I solve this by performing CFA on constructors and checking that half-initialized state never actually gets used.)
<Drup>
whitequark: it may be a bit more explicit, no more "deep magic" by runtime inspection, but the end result is the same
<mrvn>
Drup: what you can do is define a base class with a parent method that raises an exception and derived classes that actualy have a parent.
<mrvn>
Drup: That is imho the cleanes solution
<whitequark>
Drup: wait, runtime inspection? I don't have runtime inspection or deep magic
<whitequark>
or what do you mean by that?
<Drup>
mrvn: that's what I did when I need this kind of stuff
<Drup>
mrvn: don't tell me :p
<whitequark>
also, if I understand this correctly, I do have typeclasses, under a different name, I just don't mention it in that article.
<Drup>
whitequark: it's not very clear, what does "object.respond_to?(:stuff)" do ?
<whitequark>
Drup: returns true if object has a method called stuff
<whitequark>
false otherwise.
ygrek has joined #ocaml
<Drup>
is it at runtime or not ?
<whitequark>
at compile-time. if it cannot be resolved (folded to a constant) at compile-time, it's an error.
<Drup>
ok
<whitequark>
the compiler will only attempt to constant-fold certain expressions so that compilation doesn't become equivalent to halting problem
<Drup>
not really clear in the document. In general, your document is not very easy to read, it's a bit to close to musing. You are using lot's of abbreviation I have no idea what it means
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
<whitequark>
Drup: yes, that seems to be the case :/ I plan to rewrite it. would you have any advice on how to do it best?
<whitequark>
it also assumes familiarity with Ruby (I guess this was a mistake) and abbreviations mostly come from the field of compiler construction (guess this was a mistake too, should've been more explicit)
<Drup>
I'm familiar with compilers, I doesn't mean I have all abbreviations in mind all the time.
<whitequark>
my main problem is that I have a lot of unusual features which only make sense when used together, so it's hard to explain them (and their rationale) one-by-one
<Drup>
whitequark: and imo, the main selling would be to compare to known stuff
<Drup>
you show exemple, and mostly I'm like : "yes, and what ?"
<mrvn>
Has anyone ever tried to statically type something like python?
<whitequark>
mrvn: plenty of times
zpe has quit [Ping timeout: 252 seconds]
<mrvn>
successfully?
<whitequark>
shedskin, starkiller being the most advanced examples
<Drup>
mrvn: look at CPython (I think it's the correct name)
<whitequark>
imo no
<Drup>
it's used inside Pypy
<whitequark>
Drup: mrvn: that's RPython
<Drup>
oh yes, R*
<Drup>
too many <FOO>Python :D
<mrvn>
Does that understand when methods are added later in the lifetime of an object?
<Drup>
probably not
<whitequark>
I think not
<whitequark>
starkiller did not
<Drup>
RPython use a restriction of python
<whitequark>
it's based on a much earlier work on statically typed Smalltalk by Ole Agesen
<mrvn>
Seems to be quite common with threads. The run() method adds stuff to the class.
<whitequark>
mrvn: I won't really call any of the above success. you have a language with syntax of X, and a very simple and inexpressive type system on top of that, which people who are most likely to use that (X programmers) have no idea how to use
<whitequark>
i.e. how to fix your code when it is rejected, and how to actually make it work. also, lots of common idioms are forbidden--for example, heterogenous arrays--and nothing is provided as replacement--for example, neither of those have union types.
<mrvn>
My concern would be specifically that calling a method on something can change the type of it. I don't know any type system that can track that.
<ggole>
Python is a pretty poor ML.
NoNNaN has joined #ocaml
<whitequark>
mrvn: this (and lots of much weaker assertions) are just not tracked
<whitequark>
so for example while you can change class of an object in python, you simply cannot in those statically-typed-pseudo-pythons
<gasche>
Mezzo may be able to track this kind of recursive strong update
<whitequark>
same for smalltalk and every other attempt I've seen so far (there were also several for Ruby...)
<mrvn>
whitequark: yeah. But that would be the feature I was interested in
<Drup>
whitequark: on a side note, did you look at haxe macro system ?
<whitequark>
mrvn: then you're searching in the wrong area. statically-typed-X (X = Python, Ruby, ...) seem to be always done by ex-X programmers. I don't know any with a sensible type system.
<ggole>
TypeScript?
<ggole>
(Although it is not sound.)
<whitequark>
yeah
<whitequark>
Drup: no, did not.
<whitequark>
should I?
<Drup>
probably :p
<whitequark>
Drup: from a quick look, seems not very different from camlp4, conceptually
olibjerd has quit [Ping timeout: 245 seconds]
w0rm_x has joined #ocaml
<whitequark>
Drup: generally, I'm opposed to macro systems for metaprogramming (as opposed to syntactic extensions), it's too fragile and contrived
<whitequark>
to using*
<whitequark>
I've explained what I consider a better approach in the article.
<whitequark>
perhaps we didn't understand each other
w0rm_x has quit [Ping timeout: 268 seconds]
<whitequark>
Drup: I'll look at it again tomorrow. I need to sleep now, though. o/
w0rm_x has joined #ocaml
<companion_cube>
gasche: which hamt implem would you recommand? :p
dsheets has joined #ocaml
dsheets has quit [Remote host closed the connection]
dsheets_ has joined #ocaml
Kakadu has quit []
malo has joined #ocaml
zpe has joined #ocaml
Neros has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
dsheets_ has quit [Quit: Leaving]
dsheets_ has joined #ocaml
mcclurmc has quit [Quit: Leaving.]
dsheets_ is now known as dsheets
<gasche>
companion_cube: I don't actually know
<gasche>
I had a private discussion with both authors but that wasn't terribly conclusive as they were both too busy to actually compare their impl.
w0rm_x has quit [Ping timeout: 272 seconds]
<gasche>
I guess you want one that is both correct and fast
<companion_cube>
anyway, the acid-state thingie is much more interesting imho
<companion_cube>
but harder
thorsten` has quit [Read error: Operation timed out]
<wmeyer>
companion_cube: what you are talking about now?
<companion_cube>
what am I talking about usually? ^^
<Drup>
gasche: you should do "small library of the week" in ocaml.org, as you did on reddit at some point :)
thorsten` has joined #ocaml
iZsh has quit [Remote host closed the connection]
smondet has quit [Read error: Operation timed out]
<Drup>
the same things you do every night, companion_cube. Trying to reinvent the wheel. :D
smondet has joined #ocaml
<companion_cube>
Drup: heyyyyyyy
<companion_cube>
want to be "minus"? :p
iZsh has joined #ocaml
<Drup>
(actually, it's the brain's sentence ;))
<companion_cube>
should be "we" then
<companion_cube>
so I'll be the brain, and you the follower
<Drup>
(and it's "pinky and the brain", in english)
<Drup>
(I find french names better, for once)
<wmeyer>
companion_cube: hi.
<companion_cube>
hi wmeyer
<companion_cube>
I'm been blamed by everyone for "reinventing the wheel" nowadays
<Drup>
it starts being a funny characterization more than a blame :D
<companion_cube>
hmmmmmmmm
<companion_cube>
maybe I'm being too paranoid ^^
<companion_cube>
"c³, the wheel crafter"
<pippijn>
companion_cube: you always reinvent the wheel!
* pippijn
jumps on the bandwagon
<adrien>
companion_cube: :D
<wmeyer>
adrien: \o
<companion_cube>
ahhhhhhh
<companion_cube>
when all you have is a car, everything starts looking like a wheel
darkf has joined #ocaml
ggole has quit []
caligula_ has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
caligula_ has joined #ocaml
yacks has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
Neros has quit [Ping timeout: 252 seconds]
Neros has joined #ocaml
szacun has quit [Quit: leaving]
<jdoles>
ocaml build setup.ml refers to some compiler that doesn't exist. Now what?
<adrien>
"ocaml build setup.ml" is not a typical command
<adrien>
"ocaml setup.ml -build" maybe
<jdoles>
adrien: yes, that.
<adrien>
run -configure or ./configure again?
<jdoles>
adrien: it talks about ~/.opam/4.00.1/bin/ocamlbuild existing.
<jdoles>
adrien: or rather, it says "not found".
<companion_cube>
ocaml setup.ml -configure ?
<adrien>
you changed your toolchain recently?
<jdoles>
adrien: so, it apparently believes that it should look there.
<companion_cube>
eval `opam config env` maybe
<jdoles>
companion_cube: none of those suggestions work.
<jdoles>
adrien: it's a new toolchain.
<jdoles>
adrien: I am now supposed to be running 4.01beta (or something similar)
<adrien>
oasis has some cache files
<jdoles>
adrien: so, where it gets the 4.01(without the beta) from, I have no idea.
<jdoles>
I also ran oasis setup
<adrien>
I don't know if "ocaml setup.ml -clean" will remove them
<Drup>
you need distclean
<adrien>
but worth a try (you need to clean anyway since you've changed the toolchain)
<Drup>
"ocaml setup.ml -distclean" should remove all the cache stuff
<jdoles>
Drup: thank you!
<companion_cube>
ok, I should let the experts talk :(
<jdoles>
Please introduce a command, ocaml setup.ml -justfuckingbuild
<jdoles>
Or ocaml setup.ml -dowhateverittakes
<Drup>
jdoles: "ocaml setup.ml -distclean && ocaml setup.ml -build" is quite equivalent to that :p
<jdoles>
Drup: wrong
<adrien>
I would have said "rm -r"
<jdoles>
Drup: it requires -configure too
<Drup>
-build should call the configure phase by itself
<jdoles>
Drup: it complained about a lack of setup.data.
<Drup>
huum, ok
<jdoles>
Anyway, *I* I think my brain shouldn't be concerned with such details.
<adrien>
you changed your toolchain
<Drup>
changing toolchain in ocaml is quite a big deal
<adrien>
s/in ocaml //
<Drup>
well, it's worse in ocaml :p
<adrien>
C++ has ABI; C currently has LTO in most compilers, Ada and Fortran will have issues too; ...
<adrien>
and ocamlbuild is written in ocaml and has plugins which are written in ocaml
<jdoles>
If it had any brains, it would have said: "looks like you changed compiler, do you want me to fix everything?"
<jdoles>
Or preferably it would have said nothing and just did it.
<jdoles>
It's not like it's deleting source code.
<companion_cube>
but we don't have AI yet
<jdoles>
It's not called AI.
<companion_cube>
"If it had any brains"
<jdoles>
Besides, we do have artificial brains running in some lab@IBM.
watermind has joined #ocaml
<Drup>
I'm not sure you will be happy using those inside a build system
<nicoo>
Drup: I'm not sure any AI would be happy about being used as a build-system :)
<companion_cube>
what do you think jenga is?
<nicoo>
jdoles: It is not necessarily a good idea to try an idiot-proof a build-system as much as possible
<nicoo>
to try to*
<jdoles>
So, whatever distclean undoes is the same kind of thing as running autoreconf?
<jdoles>
(except then in the C world)
<jdoles>
Or GNU world, if you care that much.
<jdoles>
nicoo: I think it's a great idea.
<adrien>
oasis has caches
<jdoles>
nicoo: I like good error messages.
<jdoles>
I also hate caches that don't actually cache.
<jdoles>
A cache is supposed to be an optimization.
<jdoles>
It's not supposed to break correctness.
<jdoles>
Some people didn't get the memo on that.
<adrien>
but as much as you might have to distclean when changing compiler, sometimes you're happy that it doesn't do it automatically because you hadn't noticed you were using the wrong compiler
<adrien>
didn't break correctness
<nicoo>
jdoles: Changing your build environment mid-way breaks stuff, yes.
<nicoo>
But even detecting that the environment changed is non-trivial
zpe has joined #ocaml
Arsenik has joined #ocaml
w0rm_x has joined #ocaml
w0rm_x has quit [Read error: Connection reset by peer]
w0rm_x has joined #ocaml
robink has quit [Quit: No Ping reply in 180 seconds.]
robink has joined #ocaml
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
tane has quit [Quit: Verlassend]
tani has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
user_ has joined #ocaml
user_ has quit [Client Quit]
user_ has joined #ocaml
pkrnj has joined #ocaml
<user_>
hello. I'm currently trying to decompress data I got from a web server. I managed to get the data from string Pipe.Reader.t (using Cohttp_async) into a string. However Gzip seems to require an in_channel, and I cannot convert the string to an in_channel. I've also tried to figure out if there was a way of doing it directly through the Pipe.Reader, or via a Stream, but I couldn't find any way to do it. Can someone please point me in the
ygrek has quit [Ping timeout: 272 seconds]
<Drup>
do you want to decompress the data because you are receiving a compressed file or because you want to use compression over your http stream ?
<user_>
i'm receiving a gzip'd reply from the server, so I need to decopmress it
tani has quit [Ping timeout: 272 seconds]
<Drup>
so, first case
<user_>
yes
tane has joined #ocaml
<Drup>
I don't really now Core so I can't really help you, but in the worst case, you can probably open a input chanel that target a string
<companion_cube>
that's why we need abstractions over streams :/
<user_>
Drup: that is what I've been trying to do. I'm very new to the language/functional programming, and could not figure out a way to go from "string" to "in_channel"
<Drup>
companion_cube: I think those are in Core, at least there is some in batteries
<companion_cube>
Drup: the problem is, there is no common, widely accepted abstraction
<companion_cube>
so gzip, which is not a core thing, has trouble interoperating
milosn has joined #ocaml
ousado has quit [Read error: Connection reset by peer]
<def-lkb_>
user_: the Gzip module provide an high level interface designed to work with channels
ousado has joined #ocaml
milosn_ has quit [Ping timeout: 245 seconds]
<def-lkb_>
user_: to use another abstraction (here a Pipe of a string), you'll have to directly use Zlip externals
<user_>
def-lkb_: yes, but as far asI know I don't have one. To the best of my knowledge I must either create one from a Pipe.Reader, or from a string, but I don't know how.
<def-lkb_>
You can still use the gzip.ml code as a starting point.
<user_>
oh, and create my own in_channel ?
<Drup>
user_: which gzip binding are you using ?
<def-lkb_>
No, your own binding working with string Pipe.Reader.t
<user_>
Drup: i'm using the gzip provided by camlzip installed through opam
mcclurmc has joined #ocaml
<Drup>
I don't see any other solution than the one proposed by def-lkb_
<user_>
ok. Thank you :)
<Drup>
(or don't use Core, there is a solution for batteries)
<companion_cube>
that's really too bad
<companion_cube>
maybe camlzip ought to be patched to allow to provide strings/write into buffers
<def-lkb_>
(Drup, which one ?)
<Drup>
at some point, there was a GZIP module in batteries that operator on batteries IO stream directly
<Drup>
operate*
<def-lkb_>
Ok.
<Drup>
but I don't find anymore, so maybe it was in batteries 1 only
<user_>
Drup: I'll see what I can find. Thank you :0
<user_>
:)
<companion_cube>
I think camlzip should be the reference, but it only reads from in_channel
<user_>
companion_cube: yes, that is the code that I have. I can tell you that it certainly isn't for someone who is writting his first project in the language
<companion_cube>
user_: it's not really linked to the language, but to the libraries ^^
<def-lkb_>
companion_cube: well, the low-level interface exposes enough information to implement Gzip abstractions without having to modify camlzip