talzeus__ has quit [Read error: Connection reset by peer]
es917 has quit [Ping timeout: 240 seconds]
shinnya has joined #ocaml
es917 has joined #ocaml
cdidd has quit [Remote host closed the connection]
ihm1 has quit [Quit: ihm1]
csakatoku has joined #ocaml
ihm1 has joined #ocaml
ygrek has quit [Ping timeout: 256 seconds]
ben_zen has joined #ocaml
cdidd has joined #ocaml
madroach has quit [Ping timeout: 264 seconds]
madroach has joined #ocaml
steshaw has joined #ocaml
talzeus has joined #ocaml
steshaw has quit [Client Quit]
steshaw has joined #ocaml
talzeus has quit [Read error: Connection reset by peer]
walter has joined #ocaml
adu has joined #ocaml
ygrek has joined #ocaml
walter has quit [Read error: Connection reset by peer]
walter has joined #ocaml
adu has quit [Client Quit]
adu has joined #ocaml
adu has quit [Quit: adu]
steshaw has quit [Remote host closed the connection]
adu has joined #ocaml
walter has quit [Quit: This computer has gone to sleep]
adu has quit [Quit: adu]
fayden has quit [Quit: Bye]
q66 has quit [Quit: Leaving]
fayden has joined #ocaml
Drup has quit [Quit: Leaving.]
adu has joined #ocaml
weie has joined #ocaml
talzeus has joined #ocaml
shinnya has quit [Read error: Operation timed out]
breakds has quit [Remote host closed the connection]
ben_zen has quit [Quit: sleeep]
walter has joined #ocaml
yacks has quit [Quit: Leaving]
chrisdotcode has quit [Ping timeout: 264 seconds]
contempt has quit [Remote host closed the connection]
adu has quit [Quit: adu]
es917 has quit [Quit: es917]
bondar has joined #ocaml
csakatok_ has joined #ocaml
csakatoku has quit [Ping timeout: 248 seconds]
gour has joined #ocaml
ggole has joined #ocaml
ulfdoz has joined #ocaml
ygrek has quit [Ping timeout: 256 seconds]
ihm1 has quit [Quit: ihm1]
<whitequark>
interesting. I found myself gravitating to a styling convention: every function, esp. module-internal, which takes more than 2 arguments, should just take *all* of them labelled.
<whitequark>
or, if you really have to have optional ones, take at most 1-2 unlabelled, at the very end of the list.
<adrien>
:)
ttamttam has joined #ocaml
<whitequark>
adrien: hm?
<ggole>
My criterion is whether there are arguments of the same type
<whitequark>
ggole: hm. my main (and most beneficial) use case so far is a module which performs SSA conversion
<whitequark>
it's full of functions like this: and ssa_of_actual_args ~entry ~state ~receiver ~actual_args =
<whitequark>
label punning also helps a lot to keep it all readable
<ggole>
Mmm, 4+ arguments is a good, uh, argument for labels.
<ggole>
Yeah. When I first learned about that I thought it was a hack, but it is quite a nice hack.
<whitequark>
it's a pity record punning isn't nearly so useful
<whitequark>
record field*
<ggole>
As in let { foo_field } = ... in ...?
<ggole>
It would be nice to be able to use natural names for fields.
<whitequark>
yeah. in almost every nontrivial module, I have >1 record, and in order to avoid possible name clashes in the future, I add prefix to all of them preventively
<ggole>
Yep.
<whitequark>
i.e. type lambda_arg = { la_location : Location.t; ... }
<whitequark>
it stops being annoying after a while, but it's still, uh, not very clean
<whitequark>
I wonder if it's possible to have both labels with same names and deterministic inference
<ggole>
In a later version we might be able to have type foo = Foo { fielda: a; fieldb: b;}
<whitequark>
oh, that's neat
<adrien>
if you have the records in small modules, you can do two things:
<adrien>
Module.({ field1 = ...; field2 = ... })
<adrien>
or
<adrien>
{ Module.field1 = ...; field2 = ...; field3 = ... } (* you only need to write "Module" once)
<whitequark>
yeah, but I don't really want to have them in small modules, that's a) lots of noise in sources b) problems with mutually recursive definitions
<whitequark>
people generally say that recursive definitions are an antipattern, but I use them all the time.
* whitequark
shrugs
ulfdoz has quit [Ping timeout: 260 seconds]
<adrien>
right, I'm mostly mentioning that for when you happen to already have an architecture suitable for that
<adrien>
hmm
<adrien>
I mean, so that you don't unnecessarily double-prefix fields
<whitequark>
oh, sure
<whitequark>
this also won't work very well for field access
<whitequark>
I think you need to prefix every access, otherwise the compiler will (rightly) complain that the type can depend on order of inference.
<ggole>
One module per record is too much
<ggole>
And if you don't do that you end up with conflicts in random places. Thus prefixing. :(
<whitequark>
yeah, and if you want structural typing for records (like for classes), then it's either slow (indirect dispatch), or you need global inference and monomorphization
<whitequark>
(well, it would be just classes then)
<whitequark>
maybe it's possible to hack unification instead... say, right now you can have two kinds of types in type environment associated with a variable contained a record: it's either a type variable 'a or a record type foo
<whitequark>
what if we add a third state? with the meaning of "we know that this variable should have fields foo and bar with types 'a and int, and perhaps others"... { foo: 'a; bar: int; .. }
<whitequark>
this way it would not depend on the order in which inferencer processes terms
<ggole>
How would you compile let foo r = r.bar ?
skchrko has joined #ocaml
<ggole>
Currently the compiler can determine the offset with which to load bar from r
<whitequark>
oh, the third state is purely intermediate
bondar has quit [Ping timeout: 240 seconds]
<whitequark>
i.e. it must be replaced with something else (fully known named record type) before codegen
<ggole>
I don't think that would play well with let polymorphism.
<whitequark>
say, the compiler would look at all record labels in scope, and if there's no conflicts, then select the relevant record type (as it does right now in recent ocaml!), otherwise it'll just error out
<whitequark>
hm.
<whitequark>
yeah, I think you're right.
<ggole>
You really need something to disambiguate
djcoin has joined #ocaml
bondar has joined #ocaml
Nahra has joined #ocaml
Nahra has quit [Changing host]
Nahra has joined #ocaml
ygrek has joined #ocaml
<whitequark>
I really wish assert had a string argument.
<whitequark>
in clangs, there's a very useful pattern: assert(Invariant && "Invariant is broken")
<adrien>
Raise exception Failure with the given string.
<whitequark>
that doesn't work with -noassert.
<adrien>
why do you use -noassert then?
<whitequark>
to make production builds faster?
<whitequark>
exceptions and assertions have different use cases
<adrien>
hmmm
<adrien>
have you noticed a difference?
<adrien>
(I'm curious; I never benchmarked them)
<whitequark>
oh, it's not the overhead of assertion itself
<whitequark>
assert (expensive_condition ())
<whitequark>
say you would want to check that the graph is always topologically sorted or something.
<adrien>
I see
<adrien>
let my_assert f = if debug_level > some_threshold then f ()
<adrien>
and you can set debug_level to many levels
<whitequark>
I can just use camlp4 to make assert behave like I want
<adrien>
then you call "my_assert (fun () -> expensive_condition local_var1 local_var2)"
<adrien>
sounds heavy
<flux>
assert (if not Invariant then failwith "This is sad" else true) :)
<whitequark>
it would be forty lines of code or something... not really complex
<adrien>
and having several levels of debug is quite nice :)
<whitequark>
adrien: I find on/off debug with module granularity much more useful
<whitequark>
flux: that is sad indeed
<whitequark>
:D
<ggole>
Macros might be the devil, but they are really useful for that kind of thing
<adrien>
you could have that at the top of your modules: "let my_assert = my_assert "NameOfThisModule""
<adrien>
small boilerplate
<adrien>
well, you should check there isn't some "pa_assert"
<adrien>
already
<CissWit>
whitequark: i used to add a comment at the end of such lines like "(* debug : 5 *) and do something like -pp 'grep -v "debug :"' when compiling without debug, or using a shell script to check the "debug level". ugly but it works quite well
mika1 has joined #ocaml
cago has joined #ocaml
<whitequark>
CissWit: that's arguably worse than macros
Simn has joined #ocaml
bondar has quit [Ping timeout: 264 seconds]
<CissWit>
well, it's a macro actually
Kakadu has joined #ocaml
ontologiae has joined #ocaml
ocp has joined #ocaml
<gasche>
companion_cube: are you going to ICFP?
<companion_cube>
gasche: no
<adrien>
gour: not sure I understand your question: more bindings and choice iz better ; I've looked at the architecture but I don't remember it very well
<adrien>
gour: for some things (but which?), I feel like lablgtk's approach is better and it feeled like some of the wisdom gained from lablgtk (which you can get by reading the source, reading some page by Dawid Toton [ mispelled ] or by asking on the MLs) could have been used
<adrien>
but again, I don't remember the specifics
testcocoon has quit [Quit: Coyote finally caught me]
<gour>
adrien: well, i'm just curious how do you like wx toolkit in general and consequently effort to bring bindings to ocaml? it seems you're not so enthusiastic about labltqt/qt-ocaml
<adrien>
not a huge fan of wx even though I haven't used
<adrien>
bit heavy, very long to compile
<whitequark>
ugly also
<adrien>
I have memories of it not fitting that well on windows actually
<gour>
whitequark: you mean API, not widgets?
<whitequark>
gour: widgets
<gour>
whitequark: how, when it uses native widgets for each platform?
<gour>
it does not make sense to me :-/
<whitequark>
gour: hm, I last checked it long ago... but it used to only have classic widgets on winxp and later, and something like motif style on linux
<gour>
it must be ages ago
<whitequark>
perhaps
testcocoon has joined #ocaml
<adrien>
wireshark is wx
<gour>
it uses gtk on linux and there is new Cocoa port for Mac
<adrien>
you can find screen captures of it
<whitequark>
adrien: oh, I've used wireshark... yeah, its gui is okay
<whitequark>
so I guess wx has improved since
<gour>
whitequark: wx provides gui abstraction for each platform and it's the only one, iirc, using native widgets
<adrien>
I think they have a fairly poor choice of icons :)
<adrien>
but others should look mostly good
<adrien>
filezilla wasn't perfect last time I looked at it but it was OK
<whitequark>
I'd say that qt is good enough for linux & windows
<whitequark>
and native cocoa is the only thing which is good enough for os x
ttamttam has quit [Ping timeout: 245 seconds]
<adrien>
well, you can make it in opengl too
<whitequark>
how would that achieve native-looking widgets?
<adrien>
a background with a pic, a single line of text and a single button; that should be more than enough for mac os x users :P
* whitequark
sighs
<adrien>
:D
<Kakadu>
gour: hi!
<Kakadu>
do you have Qt5 nearby?
beckerb has joined #ocaml
<gour>
Kakadu: nope, but i can install
* gour
is running debian sid
* Kakadu
too
* Kakadu
is going to test how lablqt install via opam
<gour>
atm i don't even have ocaml installed (only Ada)...
<gour>
it's interesting that most of the replies on the mailing list i got are about GUI options, not much about Ada vs OCaml :D
djcoin has quit [Ping timeout: 245 seconds]
<adrien>
you already know the answer you'll get from the caml-list
<gour>
well, answer without some facts is just bias...i haven't got even that
<gasche>
I don't think you've ever said which kind of software you would be writing
<gasche>
some things are particularly nice to do in OCaml, but if your backend logic mostly involve, say, numeric computation, you may see much less of a difference with Ada
<gour>
multi-platform general gui desktop app
<whitequark>
I'm not sure who in their right mind would use Ada for that
<gour>
ivolving usign 3rd party C lib for computational stuff and using sqlite3
<whitequark>
it has a nearly nonexistent community, apart from everything else
<whitequark>
probably smaller than ocaml's.
<gasche>
I'm afraid I don't know what a "general gui app" is, but I'm glad other do so that I don't have to write them myself :D
<gour>
whitequark: that is my main concern...ocaml is much more communit/open-source friendly
<gasche>
heh
<whitequark>
gasche: I guess an app where GUI code dominates everything else by size
<gasche>
people often complain that the OCaml community is too small or closed-minded, but compared to Ada we're the good guys
<gour>
:-)
<whitequark>
compared to the five people who write ada in 2013?
mfp has joined #ocaml
<gasche>
:p
Drup has joined #ocaml
<gour>
to me ada2012 looks as nice language
<whitequark>
I know one of them. he tries to use Ada to write embedded software for ARM microcontrollers.
<whitequark>
it's sad. sad and miserable.
<gour>
it's also ranked higher on different 'language popularity' index pages :-)
<gasche>
I'm not sure what the 2012 norm added to the language
<dnm>
Ada (2012 or otherwise) and OCaml are pretty different. ;]
<whitequark>
gour: afaik there's about one OSS Ada compiler (gnat), and it's completely horrible
<gasche>
but to me Ada feelds like a clunky version of Pascal with a not-unreasonable design
<whitequark>
also ^
<dnm>
gasche: Preconditions, postconditions, etc.
<dnm>
whitequark: Define horrible?
<gour>
whitequark: how many OSS compilers for ocaml?
<whitequark>
dnm: incomplete and buggy, according to that guy
<gasche>
dnm: wasn't that already in SPARK/Ada in practice?
<gasche>
gour: it's true that OCaml is a single-implementation language
<whitequark>
gour: one with at least three working backends (machine code/bytecode, java, js)
<gasche>
(to the point that the difference between spec. and impl. is blurred, so this definitely has downsides)
<gasche>
but that's possibly better than a community where the open-source compiler is subpar because everyone serious use someone's commercial offering
<gour>
with gnat one can get commercial support too (for lot of $$$s)
<gasche>
I think Ada is a reasonably good choice if you want support for partial static verification, though
<dnm>
gasche: SPARK before HiLite was a superset of a subset of Ada; HiLite and SPARK 2014 look to be more integrated into the base language.
<gasche>
JSC/Java and SPARK/Ada are reasonably advanced on that road
Yoric has joined #ocaml
<dnm>
Possibly for some eventual merging, but that won't happen right away.
<gasche>
clearly it's not gour's problem domain, though
<dnm>
HiLite's SPARK release uses why3, IIRC, for their VCG; lots of stuff pulled from Frama-C and Why. Yannick Moy working at AdaCore is definitely part of that.
<gasche>
yep
<whitequark>
gasche: I heard Ada has some really strange features in type system
<gasche>
but I mean it's an area where Ada beats OCaml
<whitequark>
limited variant of dependent types, IIRC, which is almost impossible to translate efficiently
* dnm
shrugs
<dnm>
I like Ada.
<dnm>
But I don't use it everywhere.
<gour>
:-)
ggole has quit [Ping timeout: 256 seconds]
<dnm>
I wouldn't mind a "CompCert for Ada" one day. ;]
<gour>
dnm: what about ada vs ocaml for my use case?
<dnm>
gour: Sorry, I missed what your use case was. What was it again?
<gour>
dnm: general desktop gui app, using 3rd party C lib for some computation, sqlite3 storage back-end...multi-platform (if possible), open-source
<dnm>
You can do it with Ada. Whether or not it's the best choice, I don't know. If it's between Ada and OCaml, I'm not sure, as I've not tried to write typical GUI desktop apps in OCaml.
<dnm>
But clearly people do.
<gour>
dnm: i do not want to use C(++), and after eliminating quite some langs arrived at ada vs ocaml...python is last resort, but some people which were doing similar things, abandoned projects 'cause it was too slow
<gour>
dnm: have you used gtkada or qtada?
<gasche>
I don't think python's performance would be a bottleneck for GUI programming, but dynamic typing sure is painful
<dnm>
gour: Nope, not yet anyway.
<gour>
gasche: that's certainly pain which i'd like to avoid...therefore looking at type-safa/compiled language
<dnm>
Python would be fine; I doubt performance would be the issue there.
<whitequark>
gasche: it is.
<whitequark>
performance is a bottleneck, that is.
<gour>
yep, it is
<whitequark>
for example if you have a list with >500 elements, pygtk/pyqt apps start to lag badly.
<gour>
if i don't want to fiddle with cython and/or going into C
Yoric has quit [Ping timeout: 264 seconds]
<whitequark>
ubuntu used to have that problem throughout its python-based GUI parts, and they were almost unusable.
<gour>
i expect to have queries in the order of 10k and then display results in tree list
<gour>
then render stuff. animate etc.
<gour>
dnm: my ada's concern is that there are practically no open-source projects/community (everybody seems to launch missiles), while ocaml's ecosystem is a bit alive and improving (opam, merlin,...)
<dnm>
Eh, I don't think that's true, there's an open source Ada community, but it's probably not as large nor seems as "unified" as OCaml's.
<dnm>
But OCaml is a more popular language, so that makes sense.
<dnm>
If you want to write in something people are more likely to contribute to, then OCaml may be better for that.
<dnm>
But that's just my perception.
<gour>
ok
<gour>
some years ago i was playing with haskell, but few contributors which showed up run away in fear...i had to postpone everything and hopefully ada/ocaml are more friendly :-)
<whitequark>
haskell is probably the worst non-esoteric language you may want to use for GUIs
ggole has joined #ocaml
<gour>
well, it's interesting that one of their GSoC projects this year was qt-binding generator
<Kakadu>
What are results?
<gour>
Kakadu: iirc, the project accomplished more general C++ generator to be used for qt
<gour>
dnm: gnat seems to perform well...how do you compare, in general, performance of ocaml compiler in real-world?
<dnm>
I haven't done comparisons of anything in OCaml to anything compiled with AdaCore's GNAT GPL.
<gour>
in language-shootout gnat beats ocaml in most benchmarks...
<dnm>
I think I'd have to write as close to the same program as possible in both languages, then try to match compiler options, etc. to get something roughly apples to apples, and I haven't had a desire to do that yet.
<Kakadu>
It seems my opam repo is almost ready. gour, can you get Qt5 on your machine?
<dnm>
language-shootout is microbenchmarks though, no?
<gasche>
whitequark: I'm dubious that performance would really be an issue
<gour>
Kakadu: what else i'd need?
<Kakadu>
gour: opam
<gasche>
mercurial for example has a lot of "UI" (meaning the hard work is in I/O and system calls) and performs very well
<Kakadu>
gour: I hope it's all
<gasche>
I would suspect large-list issues to be an artifact of bad implementation choices (processing items you won't display anyway) rather than language choice
<gasche>
I remember some KDE programs having performance issues on large item lists, they were due to a dumbly quadratic implementation rather than any constant factor issue
<gour>
gasche: in any case writing such program in python without type-safety is not at all attractive to me
<gour>
similar with C(++) and associated pointer fiddling :-)
<dnm>
gour: Do you already know Ada (or OCaml)?
<whitequark>
gasche: it really is an issue with python gui stuff, I've encountered this a lot of times.
<gasche>
ok
<gasche>
gour: I fully agree that software engineering in Python is a pain
<gour>
dnm: nope, just basic familiarity with each...long ago i did use pascal and few years ago spent quite some time with haskell
<dnm>
gour: They're pretty different. You might try both a bit and see what you prefer writing in... might be the thing that makes the most difference. =]
demonimin has quit [Remote host closed the connection]
<gour>
dnm: i liked haskell a lot and FP...otoh, imperative is also OK with me, although i'm not so fond of OOP
demonimin has joined #ocaml
<gour>
before trying haskell i took a look at ocaml, but then i did not like so much use of 'let'...now i see it a bit differently :-)
<Kakadu>
probably better to `opam switch 4.00.1` or even `opam switch 4.01.0`
* Kakadu
uses 4.00.1
Yoric has joined #ocaml
<gour>
Kakadu: i've 3.12.1
<Kakadu>
you need newer one
<Kakadu>
My demo app uses compiler-libs
<Kakadu>
AFAIR, they were introduced in 4.00.0
dsheets has joined #ocaml
ttamttam has quit [Quit: ttamttam]
<gour>
ahh...
yezariaely has joined #ocaml
<yezariaely>
for debugging purpose I often write let result = ... in debug "logoutput"; result is there any simpler approach, without wrapping the result into a name, I do not see?
<yezariaely>
(where debug is a simple printf more or less)
<ggole>
debug "logoutput"; ...? Or do you need the print to come afterwards?
<yezariaely>
let res = a in debug "foo"; res where a is a complex expression. and might call another debug. But I want the debug "foo" be the last to be called.
<watermind>
in the very end of the blog post the author mentions a " #type syntax to match a set of options "
<watermind>
I have no idea what he means with that
<watermind>
what are these | #identifier in match statements?
<watermind>
couldn't find it anywhere in the docs
<gasche>
it is in the doc
<gasche>
it is related to polymorphic variants
<gasche>
if you give the name foo to a closed set of variants, you can use the pattern #foo to match that set
ygrek_ has quit [Ping timeout: 245 seconds]
<gasche>
idiomatic usage:
<gasche>
match x with #foo as x -> ... | #bar as x -> ...
<gasche>
the 'as x' component refines the typing information for x
<gasche>
watermind: note that if you don't use polymorphic variants, you don't need to care about that
<gasche>
and they have downsides for all this great flexibility they give to you (basically, error message suck)
Ptival has quit [Ping timeout: 245 seconds]
<companion_cube>
it's this kind of lesser-known features, like lazy in pattern matches
<Kakadu>
lazy pattern matches?
Ptival has joined #ocaml
<watermind>
gasche: I see, that's interesting
<companion_cube>
Kakadu: match x with (llet f x = match x with (lazy y) -> y+1;;
<companion_cube>
oops
<companion_cube>
let f x = match x with (lazy y) -> y+1;;
<companion_cube>
and combinations thereupon, if your constructors/records contain lazy types
<Kakadu>
ah
<watermind>
companion_cube: I don't get that.. wouldn't it make more sense to have the lazy in the x? because what if I include multiple matches, some with lazy and some without?
<gasche>
in fact "lazy" in a pattern forces the matched value
<gasche>
so it's not a "lazy pattern" in the Haskell sense at all, on the contrary
<companion_cube>
watermind: x is of type foobar lazy_t
<watermind>
companion_cube: oh I see
<companion_cube>
and there you can force it while pattern-matching
<watermind>
right got it
<gasche>
it's actually a nice syntax as it is symetrical to expressions
<gasche>
let (lazy x) = lazy 1
<companion_cube>
the extension proposed by Alain Frisch is pretty neat too
<gasche>
hey
<companion_cube>
ho
<gasche>
OCaml 4.01.0 released
<companion_cube>
what a surprise for you !
<companion_cube>
:D
<companion_cube>
I didnt' know you were the one to thank for the spell checking in "no such identifier"
<gasche>
that's the whole reason why I added attribution information; I want to get credit for the most useful 4.01 feature
<watermind>
we can't opam install ocaml can we?
<gasche>
in fact you can
<rks`>
gasche: :D
<Kakadu>
why not?
<companion_cube>
watermind: you can, there is opam switch
<watermind>
oh
<gasche>
but the switch isn't made yet I guess
<gasche>
but
* adrien_oww
notes that gasche is building up his resume
<gasche>
opam switch install 4.01+rc1 or something should work
<rks`>
no
<companion_cube>
the RC2 is available
<rks`>
the switch is 4.01
<rks`>
but is synced with the RC atm.
<watermind>
maybe I should just wait for now :P
<rks`>
yeah
<gasche>
watermind: indeed, there is no point in hurrying up
<watermind>
gasche: what new feature were you referring to?
<gasche>
detection of typo on unbound identifiers
<gasche>
the compiler will ask you: Did you mean 'blablabla'?
<watermind>
oh that's great!
tom39341 has left #ocaml []
<companion_cube>
gasche: please don't implement it for keywords thou: "did you mean 'let' instead of 'lwt'?"
<rks`>
...
<companion_cube>
:D
<rks`>
companion_cube: your file is *supposed* to be preprocessed
<watermind>
caret diagnostics would be really nice too
<watermind>
as in the more recent gcc's
<gasche>
watermind: do you have a link to an example?
<gasche>
I certainly read about that but forgot what it is
<companion_cube>
rks`: tshh tshh you ruin everything
<watermind>
basically it's an error message showing the offending expression and a ^ pointing out where the error should be
<gasche>
hm
<gasche>
the ocaml toplevel has done that for ages
<gasche>
but I don't see the point in batch-compiler error message
<watermind>
really?
<gasche>
the intended usage mode is that your editor lets you jump to the error position instantly
<gasche>
which makes this useless
<watermind>
right... so we can set that up in tuareg?
<gasche>
it should be there by default
<watermind>
hmm have to check that
<gasche>
if you run the compiler from Emacs, that is C-c C-c or M-x compile
<gasche>
it will parse the OCaml location printing format
<gasche>
underline the location
<gasche>
and then there is a shortcut to jump to the next one
<gasche>
(my fingers know it but I don't)
<gasche>
or you can click on it as well
<gasche>
I would guess someething like C-` C-`
<gasche>
hm
<gasche>
I would be delighted to attack a new low-hanging fruit for OCaml usability, or coerce someone into providing a patch
<gasche>
but I'm afraid the next bottleneck is the quality of the syntax error messages, which requires a bit more work than that
<gasche>
(but I've been thinking about that seriously since Arthur's blog post)
<watermind>
gasche: still unsure how it works
<watermind>
so running toplevel with C-c C-s and then interpreting a file doesn't need to do anything different from running the interpreter in the console
<watermind>
and C-c C-c just calls make -k
breakds has quit [Remote host closed the connection]
<watermind>
s/need/seem
<Drup>
watermind: you can change that
<gasche>
well
<gasche>
if you're editing a self-contained foo.ml
<gasche>
just change the C-c C-c compile command into, say
<gasche>
ocamlc -c foo.ml
<gasche>
you'll get error messages, and you can jump at the right place
<gasche>
(of course it works across multi-file, and you can use "ocamlbuild foo.byte" or whatever)
<whitequark>
gasche: it would be really good to be able to make it report 1-based columns.
<gasche>
note that if you use Merlin (under either Vim or Emacs), you don't even need to call the compiler directly to get the error messages
<whitequark>
guess I should file a bug
<gasche>
but the jump-to-next-error command (not sure it's its name) will show you precisely the right notation
<gasche>
you shouldn't ever need to count columns manually
<gasche>
s/notation/location/
<companion_cube>
I still do it manually, but it's not so hard to jump at the right column
<gasche>
hm it may be "goto-next-locus" (at least this one work but it may have a more general semantics)
<gasche>
companion_cube: why not use C-` C-`?
<rks`>
next-locus ? :D
<gasche>
if it was a Harry Potter reference, I missed it
<companion_cube>
gasche: I use vim, which does it, but it kind of messes with tabs
<rks`>
companion_cube: you should never use tabs. :)
gour has quit [Quit: WeeChat 0.4.1]
<companion_cube>
rks`: not tabulations, editor tabs
<gasche>
hm
<rks`>
ah
gour has joined #ocaml
<companion_cube>
more generally it makes me lose my buffer layout, but I never took time to try to fix it
<gasche>
that's strange, in OCaml it preserves it (except of course that one
<companion_cube>
most of the time anway, just jumping to the line where the error is is enough
<watermind>
gasche: right that does work
<companion_cube>
don't even have to read the message ^^
<gasche>
window is used for compiler output)
<watermind>
would be nice if it automatically highlited the errors on emacs, rather than having to click through them
<asmanur>
that's what merlin does
<watermind>
is merlin another emacs mode?
<gasche>
more or less, yes
<gasche>
but it doesn't conflict with Tuareg I think
<companion_cube>
watermind: for both emacs and vim
<adrien_oww>
- The future of GTK is somewhat uncertain; it seems to be focussed
<adrien_oww>
only on supporting GNOME now [1].
<adrien_oww>
it'll continue working
<adrien_oww>
also, the win32 bindings might be usable nowadays thanks to mingw-w64
<kerneis>
adrien_oww: question about cygwin, ocamlfind and make
<gour>
adrien_oww: that is perspective created by GTK team and it will be hard to get rid of it...it reminds me on lighttpd & memory leaks...long after the bug(s) were fixed, people on mentioning lighttpd would say: "It leaks memory."
<kerneis>
hmm, not a question in fact, just complaining that life is hard
<kerneis>
on Unix, I use $(shell ocamlfind query destdir) to fix ocamlfind install when $DESTDIR is set
<ggole>
companion_cube: it's nice to see which constructor you are missing for exhaustiveness checks
<kerneis>
but on cygwin, it gives me a win path
<kerneis>
and I have to convert it using cygpath
<kerneis>
is there a simpler way?
<ggole>
I do find that a successful compilation buffer is pretty useless though
<companion_cube>
ggole: indeed
<ggole>
(I munged together some hack to get rid of that.)
<kerneis>
(all of this because cygwin's make does not support win paths - they *removed the feature* in 2006)
<kerneis>
(probably got some hint by GNOME devs)
ollehar has joined #ocaml
mort___ has joined #ocaml
yacks has joined #ocaml
<adrien_oww>
kerneis: doubt it; the ocaml* tools are native windows and they won't understand cygwin paths
<adrien_oww>
kerneis: you're using cygpath?
<adrien_oww>
gour: well, I agree but it's stable (although ugly)
<adrien_oww>
kerneis: ok, saw that you're using cygpath
<adrien_oww>
kerneis: windows paths are a big issue in cygwin because they are of the form C:/...
<adrien_oww>
which means
<adrien_oww>
all: some dep C:/foo
<adrien_oww>
too many colons
<gasche>
ggole: I used to run "ocamlc -i .." instead of "ocamlc -c ..."
<gasche>
the problem is, some error checks/warnings are delayed inbetween -i and -c, so you won't get all information
<gasche>
in practice for non-trivial projects my compilation commands are always of the form
<gasche>
ocamlbuild stuff && ./test stuff
talzeus has joined #ocaml
<gasche>
(well whatever command also runs the code to give me correctness feedback)
talzeus_ has joined #ocaml
<kerneis>
adrien_oww: yeah, fortunately enough I can avoid them in most of my compilation process
<kerneis>
I'm just having troubles with make install
<ggole>
I usually build a toplevel and run whatever tests in that.
<ggole>
That could probably be more efficient.
talzeus has quit [Ping timeout: 245 seconds]
<watermind>
from the merlin blog " Reporting type and parsing errors before compiling "
<watermind>
before compiling? I thought that'd be using on the fly compilation with flymake or something of the sort
<watermind>
how do you report errors before compiling?
<gasche>
they mean "before you explicit ask for a compile"
<gasche>
it does parse and typecheck incrementally / on the fly
<ggole>
As in 'flymake' style... oh
<gasche>
doesn't really "compile" though as there is no executable production
<ggole>
Hmm, wonder how nicely it handles incomplete source
<watermind>
gasche: oh incrementally? I didn't even know compilers did that...
<gasche>
ggole: as nicely as it can :]
<Drup>
it doesn't, it's only merlin
<gasche>
ggole: as you could expect, it will be very reliable until the first erroneous program point, and go down the toilet after that
<gasche>
Drup: to be fair, it relies on the fact that it's possible to type-check OCaml program incrementally, as is already used by the toplevel
<ggole>
If it realises the buffer is incomplete and just gets out of the way, that's fine
<gasche>
(I mean the capability is there in the distribution codebase)
<rks`>
what do you mean « go down the toilet » ?
<gasche>
ggole: it's designed to precisely get involved on incomplete buffers
<gasche>
if the buffer is complete and correct, you don't need merlin, "ocamlc -bin-annot" will do just as well
<ggole>
Right.
<rks`>
sure
<gasche>
(which is what, say, ocp-index uses)
<kerneis>
oh wait, I must convert both ways...
<kerneis>
pfff
<gasche>
rks`: I mean that typing information is much less reliable, etc.
<rks`>
right
<gasche>
or even syntax category recovery
<watermind>
gasche: does this mean it can tell which functions changed since last time and use some sort of dependency check to see what needs to be typechecked again?
<ggole>
(I'm under the impression that at least part of the appeal of such tools is that you don't have to do anything at all in order for the feedback to arrive.)
<watermind>
ggole: yes, I use flymake in haskell (via ghc-mod) and it's really useful
<ggole>
It's not distracting?
<watermind>
not that much I don't think so
<ggole>
I guess I should try merlin and find out. ;)
<watermind>
personally I'd prefer if the feedback were less intrusive
<watermind>
as it stands it marks your whole line red if there's an error
<ggole>
You can change all that though.
<rks`>
really watermind?
<watermind>
so if you stop typing to think, the line gets red
<watermind>
yeap
<rks`>
ggole: I guess so, the few times I saw it work on emacs it wasn't that intrusive
<watermind>
personally I'd prefer just a red ball on the left
<watermind>
or a red ! or something, other than colouring the whole line
<gour>
adrien_oww: you mean gtk2? gtk3 is not and gtk2 is dead-end
<gasche>
it is true that "getting in the way of my thoughtflow" is one criticism against constant-feedback interfaces
<ggole>
They're probably more useful for bashing out dumb code than for thoughtful coding.
<Drup>
autocompletion with type indication is quite useful.
<ggole>
...so, pretty useful. I bash out a lot more dumb code than I'd like.
<rks`>
watermind: the user has to add the flag, the package creator can't do a thing about it
<rks`>
(yet)
bondar has joined #ocaml
bondar has quit [Read error: Connection reset by peer]
<ggole>
Hmm, does merlin depend on tuareg-mode?
<ggole>
I get funcall: Symbol's function definition is void: tuareg-mode
<gour>
does opam makes use of distro pacakges/ports obsolete?
<gour>
*make
<gasche>
gour: my advice is to use opam to setup your OCaml development environment, but your distro package/ports to install OCaml *programs* you want to use as a simple user
mort___ has quit [Ping timeout: 276 seconds]
<gasche>
(coq, unison, etc.)
<Drup>
ggole: the emacs mode probably do
<ggole>
Seems to run anyway.
<gour>
gasche: thanks. iwas primarily thinking about the former, iow. env
<ggole>
Nice, jump to definition is handy.
<ggole>
Although it doesn't seem to like record accesses.
<asmanur>
ggole: yes by default it does use tuareg-mode but you can configure it
<ggole>
OK, I'll poke around the docs a bit.
<ggole>
Cheers.
<asmanur>
(check out M-x customize-group merlin)
<ggole>
Hmm, I just get two faces.
<ggole>
Seems that there is the group merlin-faces but no merlin.
<asmanur>
hm
<asmanur>
oh right
<asmanur>
its coming with 1.4
<asmanur>
nvm :-°
<asmanur>
C-h v merlin-<tab> then :-°
<ggole>
OK.
<ggole>
Looks like I can tweak merlin-favourite-caml-mode to avoid the error.
<asmanur>
yes
<ggole>
(I'm guessing that will appear in the missing group.)
ollehar has quit [Ping timeout: 240 seconds]
<ggole>
I have an array variable stmts: jump to definition will go to the argument as expected for the naked variable, but fails with 'stmts. not found.' for an array access stmts.(foo).
<ggole>
Hmm, guess I should just report it rather than bitching to asmanur.
<rks`>
yes :)
<ggole>
This is quite nice though.
<rks`>
so we have a trace of it
<ggole>
I really like that I don't have to fiddle with build settings or run any commands to have it work.
<asmanur>
:)
<ggole>
Low friction.
<rks`>
weeeeeeell
<rks`>
on big projects, you have to setup a config file
<asmanur>
"tomorrow you will have to learn about .merlin"
<ggole>
Hah
<rks`>
but otherwise, if you just have stuff in the current directory
<companion_cube>
:)
<ggole>
Well, that's half expected.
<rks`>
and you don't use any findlib package
<companion_cube>
.merlin is very simple though
<rks`>
everything should be working fine
<ggole>
For one-off files not having to fiddle is a boon.
<rks`>
yeah
<ggole>
For big things, you do it once and it is amortised over the project.
<rks`>
(and you can always load findlib packages directly from your editor)
<pippijn>
how would one go about binding perl and ocaml?
<rks`>
one wouldn't.
djcoin has quit [Quit: WeeChat 0.4.0]
<pippijn>
why not?
<rks`>
because perl.
<pippijn>
fine
<rks`>
:p
<pippijn>
python?
<pippijn>
$yourfavouritescriptinglanguage
<ggole>
Few things other than C are simple enough to write/generate bindings for and remain sane.
<pippijn>
apparently there is a pycaml
<pippijn>
ah
<pippijn>
ok, I remember how to do that
<pippijn>
the perl object will contain a value registered as global root
ttamttam has joined #ocaml
ttamttam has quit [Client Quit]
* gour
is reading tutorial about usage of ;; vs ;
<watermind>
gour: afaik it's pretty simple... please someone correct me if I'm wrong ; is just the sequencing operator s ; t evaluates s, forgets its result, then evaluates t
<watermind>
gour: and ;; is usually just used in toplevel to denote end of instruction
<pippijn>
;; is end of sentence
<gour>
watermind: i read about some rules wehn ;; might be omitted
<pippijn>
I use it for functions with side-effects
<pippijn>
gour: it is never necessary
<watermind>
pippijn: gour: is that ever needed (aside from toplevel)
<gour>
to omit?
<pippijn>
to write it, except in the REPL
<watermind>
pippijn: you use ;; for functions with side effects??
<pippijn>
sometimes
<pippijn>
let foo a =
<pippijn>
something 1;
<pippijn>
something 2;
<pippijn>
something 3;
<pippijn>
;;
<watermind>
but isn't it redundant?
<pippijn>
watermind: I prefer this to omitting the final ;
<watermind>
oh
<watermind>
right
<gour>
it is not so hairy as i thought when encountering ocaml for the first time several yrs ago
<watermind>
personally I find that if a language doesn't use semantic indentation then it should avoid ambiguity at all cost
<watermind>
so top let's should require some delimiter
<watermind>
e.g. endlet
<pippijn>
just ;;
<pippijn>
some people do:
<pippijn>
let foo a =
<pippijn>
begin
<pippijn>
code;
<pippijn>
end
<watermind>
problem is ;; is not required, and ;; can easily become a ; by acident
<watermind>
yes but my point is, shouldn't be optional
<pippijn>
sure
<pippijn>
I got it
<watermind>
e.g. compare if then else in pascal and in ADA
es917 has joined #ocaml
<pippijn>
but no need to introduce another terminal
<pippijn>
just use ;; and make it mandatory
<ggole>
Ugh, ;;s everywhere?
<pippijn>
if/then/else in ocaml can be surprising
<pippijn>
if cond then expr else otherexpr
<watermind>
the two reasons why I don't like that are, 1. you can write ; by mistake 2. you need delimiters for other constructs also (e.g. match) and they should all be different and easy to identify
<pippijn>
then, adding an assert
<pippijn>
if cond then assert (othercond); expr else otherexpr
<pippijn>
oops
<watermind>
so I like, endlet, endif, endmatch
<ggole>
If you want that then you need either delimeters or indentation sensitivity
<pippijn>
I'm not opposed to significant whitespace
<pippijn>
haskell did that well
<pippijn>
python did it wrong
<ggole>
It has downsides
<ggole>
But source code does become nicer to read.
<ggole>
F# has some whitespace thing iirc
<gour>
watermind: endlet, endif, endmatch are part of ocaml?
<pippijn>
what's the downside of haskell's whitespace sensitivity?
<pippijn>
gour: no
<ggole>
Where you don't need ins
<ggole>
You can't paste code and have the editor autoreindent it
<pippijn>
oh
<pippijn>
that's true
<ggole>
It's a minor niggle at most
<ggole>
(You also have to be careful to not do dumb things like Python's lambda, I guess.)
<pippijn>
just don't be dumb like python
<pippijn>
haskell is neat
<ggole>
Python syntax could be ok if you changed x = 1 from assignment to binding.
<watermind>
gour: no they're not
<pippijn>
ggole: introducing a new scope with every binding?
<ggole>
Yeah
<pippijn>
like ocaml let x = 1 in?
<pippijn>
ok
<pippijn>
I don't think so
<travisbrady>
Any ctypes experts know why I'd be getting "Error: Unbound value field"?
<ggole>
Why not? Recursive definitions?
<pippijn>
python's "if" doesn't have a value, does it?
<pippijn>
python is an imperative language
<ggole>
I was referring to its syntax, not its nature
<pippijn>
ok
<pippijn>
I find this problem in perl, recently
<ggole>
Of course you would have to change some things to suit functional programming
<pippijn>
ever since I started using ocaml
<pippijn>
I find myself wanting if to have a value
<pippijn>
instead, perl has ?:
<pippijn>
which is ugly
<travisbrady>
I can get utop to auto-complete 'Ctypes.field' but then it spews the "unbound value" error?
<ggole>
Almost as ugly as pythons foo if bar else baz
<travisbrady>
s/?//g
<pippijn>
what's that?
<ggole>
That's python's 'else expression' :/
Drup has quit [Quit: Leaving.]
<pippijn>
that's if bar then foo else baz?
ttamttam has joined #ocaml
<ggole>
Yep
Drup has joined #ocaml
<pippijn>
that's even worse
<pippijn>
it's half inverted
<ggole>
Yes, so evaluation isn't left to right.
<pippijn>
then-expr "if" cond "else" else-expr
<ggole>
Unlike the rest of the language.
<pippijn>
right
ttamttam has quit [Client Quit]
<pippijn>
perl has that, but without the else part
<pippijn>
which is better, imo
<pippijn>
print "Hello" if $cond;
<ggole>
I don't see the appeal.
<pippijn>
print "oh noes" unless $cond;
<ggole>
It's a bit more Englishy
<pippijn>
the appeal is shorter code
<pippijn>
no need for {}
<ggole>
if $cond then print "Hello"?
<pippijn>
not in perl
<ggole>
Hmm
<pippijn>
if ($cond) { print "Hello" }
<ggole>
Bleh.
<pippijn>
with postfix if, you need no {} and no ()
<pippijn>
I use postfix for sometimes
<pippijn>
s/foo/bar/g for @array;
<ggole>
I see I know even less Perl than I thought I did.
<pippijn>
somefunc $_ for @array;
<pippijn>
chomp for @input;
<pippijn>
^- often
<pippijn>
(removing EOL from all lines of the input)
<pippijn>
die "omg" unless $cond;
<ggole>
I like die. Better than failwith imo.
<pippijn>
I find it neater, especially when there are several such things in a row, than having if (!$cond) { die "omg" }
<pippijn>
ggole: I use die in my C parser :)
<pippijn>
types.ml: | ty -> die (Type_error ("set_base_type", None, [ty]))
<ggole>
It'd also be nice if failwith was a wrapper around ksprintf
ihm1 has quit [Quit: ihm1]
<ggole>
I've defined that one a few times now.
<pippijn>
ah yes
<pippijn>
and it would be nice if the C version caml_failwith did that, too
<gour>
afaict, ocaml-types lib allows one to write 'thin' binding for some C lib...what if one wants to provide higher-level ocaml-ish API? just wrap the bindings created by ocaml-types or something else?
<pippijn>
unsigned short i = 3, j = 4; sizeof(3 + 4);
<pippijn>
eh
<pippijn>
unsigned short i = 3, j = 4; sizeof(i + j);
<pippijn>
also, the sign of i+j is..?
<ggole>
Hmm... signed.
<pippijn>
yes
<pippijn>
and that's funny, because
<pippijn>
if (i+j > (unsigned short)5) ...
<ggole>
I think unsigned short is promoted to int before the addition.
<pippijn>
gives you a warning :)
<pippijn>
sign-compare
<ggole>
Lovely.
<pippijn>
ggole: exactly
<pippijn>
it becomes *signed* int
<pippijn>
when both operands are unsigned short
<pippijn>
who came up with that :/
<pippijn>
(and thought it was a good idea)
<ggole>
And then truncated when assigned to a short: so binding has different semantics to an expression.
<ggole>
Not wonderful.
<ggole>
I have no idea why people think C is well designed.
<pippijn>
C's low level semantics are so bad
<pippijn>
high level semantics are easier
<pippijn>
like, how structs work and statements
<pippijn>
jump statements are pretty clear
<ggole>
Yeah, structs are pretty clean (except for bit fields).
<kerneis>
oh, if you love C so much, I have a bug in CIL which prevents recent kernels to boot when CIL compiles qemu
<ggole>
And enums.
<kerneis>
older kernels (2.6.32) boot just fine
<kerneis>
ahd I have no fucking clue what the bug is
dsheets has quit [Read error: Operation timed out]
<pippijn>
:\
<kerneis>
probably so bug in integer truncation somewhere I guess
<kerneis>
but have fun debug such a high-level behaviour
<pippijn>
how is that high level?
<kerneis>
well, what I observe is qemu not being able to boot a kernel, trapped in an infinite loop
<pippijn>
ok
<kerneis>
executing gazillions of lines of code on each loop
<kerneis>
because, this is qemu, you know
<ggole>
Sounds fun to debug... lots of layers.
<pippijn>
yes
<kerneis>
and for kernels that boot, everything seems to run fine, so it's very disturbing
<kerneis>
I think I'll have fun track this one down (next month)
<pippijn>
reminds me of debugging my GLR parser core
<pippijn>
but that was ocaml, and therefore reasonably easy
<pippijn>
I have a bit of a type safety problem there
<pippijn>
too much magic..
<pippijn>
and I can't really do it without magic
travisbrady has quit [Quit: travisbrady]
<caseyjames>
Can someone suggest a way to compare list A's values to list B's values to return list of B indices of the nearest B value for each A value? I'd like to capture the B value on each side of the A value with their distances from the A value.
<ggole>
Nearest in what sense?
<caseyjames>
| a - b |
<caseyjames>
So one adjacent is Left the other is <=
<def-lkb>
just sort the list ?
<caseyjames>
Do you mean by combining lists A and B? Couldn't there be consecutive A values that would be nearest to each, where here here a needs its adjacent B's.
<def-lkb>
1. define a distance function 2. define a comparison function that orders two elements according to their distance to a third one
<def-lkb>
3. map the list of a: for each a, sort the b list using the comparison function defined in (2) using a as the origin element
<def-lkb>
this gives you a runtime of n * m * log (m), where n is length of a list, m is length of b list
ihm1 has joined #ocaml
travisbrady has joined #ocaml
<caseyjames>
Would | a -b | make that
<caseyjames>
a the origin element
<def-lkb>
yes
<caseyjames>
Also is that a good run time? I'm new to ocaml
<ggole>
You don't need to sort, you can find minima in linear time.
<def-lkb>
and the comparison function would be: compare a b1 b2 = compare (distance a b1) (distance a b2)
<def-lkb>
oh you're right ggole, I thought caseyjames asked for the neighborhood… therefore it's better to keep the minimum
<caseyjames>
so does that approach stand... I'm firing up emacs to test it out
<ggole>
min_by could be adapted to return one without altering the complexity (or needing another pass over the list).
<caseyjames>
ggole I will try that out. Thank you guys for the help. Out of curiosity - do you just learn to memorize the different runtime complexities with different patterns?
<def-lkb>
In your case, complexity is straightforward :)
<ggole>
It's "obvious" for this case.
<ggole>
The min_by is a linear loop over the second list.
<ggole>
That is done once for every element in the first list.
<ggole>
So the complexity is O(len(A) + len(B)).
<ggole>
Er, *
<ggole>
You could do better by copying to an array, sorting B and finding distances with binary search.
<def-lkb>
?
<ggole>
It would be easy to screw that up though.
tane has joined #ocaml
<def-lkb>
that would work only for a 1-dimensional dataset
<ggole>
Hmm?
<def-lkb>
( |a-b| suggest general metric space… you could still use high-dimensional datastructures to have better runtime, but this is another subject)
<ggole>
I'm thinking integers, for which sorting will preserve the relationship.
<caseyjames>
Would approaching binary tree as or through the type system be recommended? Do you find yourselves making all sorts of tree like structures in your daily use?
contempt has quit [Remote host closed the connection]
<def-lkb>
ggole: yes, usual ordering on integer has only one dimension…
<ggole>
Oh, I see what you mean. Yeah.
<caseyjames>
I'm getting an error Error: This expression should not be a function, the expected type is 'a Core.Std.List.t with the input something [1, 1, 2, 4, 6, 9] [1,4,5,8,10];;
<caseyjames>
I'm using something [1; 1; 2; 4; 6; 9] [1; 4; 5; 8; 10];; and getting the same error
Kakadu has joined #ocaml
<ggole>
Perhaps you changed something?
<ggole>
The code as in the paste seems to work (though like I said, it doesn't find indices).
<caseyjames>
Heres the full thing. I am running it from Top-Level in Tuareg mode with ;; added to each let... could that be the cause?
<ggole>
;; after each *top-level* let should be ok
<caseyjames>
I haven't dug into compilation yet
jbrown has quit [Remote host closed the connection]
<ggole>
You should be able to just copy the whole thing straight into the toplevel though.
<ggole>
With one ;; at the end.
<caseyjames>
With that i get List.map (fun elt -> elt, closest elt ys) xs ^^ Error: The function applied to this argument has type f:('a -> 'b) -> 'b list This argument cannot be applied without label
<ggole>
*sigh*
* ggole
shakes his fist at Jane St
<ggole>
OK: add ~f: in front of the (fun there
<ggole>
This is due to a minor change in the replacement standard library you are using.
<caseyjames>
ahh... is there tension about that?
<ggole>
No. The expanded standard libraries are very much a good thing.
jbrown has joined #ocaml
<ggole>
Occasionally there can be a misunderstanding like this though.
rwmjones has quit [Read error: Operation timed out]
<caseyjames>
It compiled once I got all the ;; back in
<kerneis>
caseyjames: are you learning OCaml with Real World OCaml?
<caseyjames>
yes indeed
<kerneis>
hence Core
<caseyjames>
so do you fold recommend turning to binary trees and other data structures as a common way of solving problems or in keeping it as simple as possible, does that rarely come up?
<kerneis>
I use trees all the time
<gour>
caseyjames: how do you like learning ocam with realworld book?
<kerneis>
but I deal with problems where they come up naturally
<kerneis>
it really depends on your task
<caseyjames>
like something like this, a binary search seeemed like a might be the way to go, but i really don't know much about it all.
<ggole>
Binary search is an operation over arrays, not over trees.
<ggole>
(There's a tree involved if you squint hard, but it is implicit.)
<caseyjames>
I'm liking Real World Ocaml, but I also read That Lean you a haskell and real world haskell, without every getting much coding time in... I think it's a bit steep for beginners.
<ggole>
It wouldn't make this problem simpler: it may make your code run faster if you had large data sets.
<whitequark>
RWO is more a reference manual than tutorial, yes
<ggole>
You should definitely code more then.
<caseyjames>
I mean more using recursive types to create lists or lists type data structures
<ggole>
Reading and thinking is always good, but you need to write a fair amount of code to become competent.
<gour>
caseyjames: i had RWH from before...did major port of it
<caseyjames>
I'm coding quite a bit with Ocaml. It was Haskell I had not really touched.
<caseyjames>
gour: meaning a port of the code?
<ggole>
Well, lists are already there
<ggole>
But recursive types are very common in OCaml code
rwmjones has joined #ocaml
<caseyjames>
I'm noticing the code is not returning the distance just the nearest value [(1, 1); (1, 1); (2, 1); (4, 4); (6, 5); (9, 8)] could that be another core thing?
<ggole>
If you want the distance, you'll have to modify min_by to keep a count.
<ggole>
Er, if you want the index.
<ggole>
The distance is implied by the pair: you can just calculate that easily enough.
<caseyjames>
right. Can this code be tweaked to include each A adjacent B's not just the nearest?
<ggole>
So nearest that is greater and nearest that is smaller?
<caseyjames>
[(LeftAdj index distance), (OtherAdj index distance); ...] so for elements visually b_____ (A)__b_
<caseyjames>
Sorry [ ( (LeftAdj index distance), (OtherAdj index distance) ); ...]
<ggole>
I'm not sure what that means.
<caseyjames>
A tuple of tuples... The inner tuple contains the B data and the outer one give the pair of the nearest B value on each side of the A value
<ggole>
Right, that's pretty much what I meant. Yes, you can do that without changing the code a great deal.
<ggole>
If you are learning, it would be a good exercise to look at min_by, understand how it calculates the minimum, and adjust it to do what you want.
Yoric has quit [Ping timeout: 268 seconds]
<caseyjames>
Yes that what I'm digging into now, I just want to make sure it was in a form that would let me get where I need
<gour>
caseyjames: no, just went through the code
<caseyjames>
Thanks for all the help btw. I am really enjoying the recursive approach, but it really is starting over
<caseyjames>
oh
<gour>
iirc, there is ocaml code for okasaki's book?
<caseyjames>
I had heard that it was ported, it has been somthing I've been meaning to sit down with once I finish Real World Ocaml and don't feel like looking at Haskell code is going to botch my sense of ocamls syntax
<caseyjames>
gour: I don't know what you were referring to with "no, just went through the code" no it wont work?
<gour>
caseyjames: i mean that i did not finish whole RWH book...gave up before
<gour>
on haskell
<caseyjames>
Ahh yes, I got 2/3rd of the way in, decided no more haskell for a while. I've actually been getting stuff done in Ocaml so it feels like it'll ctick
<gour>
heh
thomasga has joined #ocaml
smondet has joined #ocaml
ggole has quit []
ulfdoz has joined #ocaml
Snark has quit [Quit: leaving]
zarul has quit [Quit: Leaving]
zarul has joined #ocaml
dsheets has joined #ocaml
gour has quit [Quit: WeeChat 0.4.1]
Anarchos has quit [Quit: Vision[0.9.7-H-280704]: i've been blurred!]
Kakadu has quit [Remote host closed the connection]
ben_zen has joined #ocaml
rossberg has quit [Ping timeout: 240 seconds]
rossberg has joined #ocaml
darkf has joined #ocaml
penryu has joined #ocaml
<penryu>
I have the regretable situation of porting an F# program to Ocaml. in one case, it uses an Int32.TryParse call in a guard. is there an analogous operation in ocaml that doesn't involve parsing twice?
_andre has quit [Quit: leaving]
ollehar has quit [Ping timeout: 256 seconds]
ollehar has joined #ocaml
thomasga has quit [Quit: Leaving.]
<penryu>
(regretable only in that it uses a lot of the CLR that doesn't translate easily back to ML proper)
Drup has joined #ocaml
smondet has quit [Remote host closed the connection]
travisbrady has quit [Quit: travisbrady]
<wmeyer>
penryu: most likely the caml code will use exceptions
<pippijn>
wmeyer: obuild became much more usable now
<wmeyer>
penryu: so the coresponding function will raise an exception when the format of the integral you want to parse is not recognised
<wmeyer>
try to look at the documentaion for Scanf to see what kind of exception is raised
<pippijn>
you can install it and run "obuild" in a project, and it builds
<wmeyer>
(in OCaml exceptions are relatively fast, therefore they are used ubiquosly)
rwmjones has quit [Read error: Operation timed out]
<pippijn>
why is Not_found != Not_found?
<asmanur>
because malloc () != malloc ()
<pippijn>
ok
<pippijn>
why does Not_found alloc?
ihm1 has quit [Quit: ihm1]
<wmeyer>
penryu: what I can advise you, is to build a proper wrapper for it, something that parses the Int32 and returns an option type instead of raising an exception
<penryu>
right. was just thinking that sounds like the best option.
<penryu>
what are the merits of Scanf vs int_of_string?
<wmeyer>
scanf is just more general
<wmeyer>
and int_of_string is specialised for parsing ints
<wmeyer>
scanf is very old C like format based parser
ulfdoz has quit [Ping timeout: 264 seconds]
rwmjones has joined #ocaml
ihm1 has joined #ocaml
wagle has quit [Remote host closed the connection]
<penryu>
thanks
tane has quit [Quit: Verlassend]
Drup has quit [Quit: Leaving.]
Drup has joined #ocaml
ihm1 has quit [Quit: ihm1]
Simn has quit [Quit: Leaving]
derek_c has joined #ocaml
wagle has joined #ocaml
derek_c has quit [Ping timeout: 264 seconds]
palomer has joined #ocaml
<palomer>
hey, is there some lwt syntax for bind f (fun () -> y) ?
<palomer>
ie lwt () = x in y ?
<palomer>
something like >> in haskell
<kerneis>
palomer: have you looked at pa_monad?
<palomer>
so I should combine pa_monad with lwt_syntax ?
<palomer>
sounds dangerous
<palomer>
and slow
<palomer>
actually, wait
<palomer>
lwt doesn't work with the monad stuff
<palomer>
as soon as a thread is created, it will run
<kerneis>
well, the bug tracker says it has been fixed in OCsignen 4 years ago
<kerneis>
I'm even the one who reported the bug :-)
<kerneis>
(or was it another gabriel, I can't remember)
<kerneis>
(hmm, yeah, it was me)
<wmeyer>
lwt syntax extenions is used mostly in for combining threads, either in paraller setting or in sequence. So, for this you need something more than monad
<wmeyer>
good way of doing it, are joinads in F#, which support these operations
<wmeyer>
palomer: you should not combine pa_monad
<wmeyer>
with lwt syntax
<wmeyer>
(you can, if you have other monadic code)