thelema has quit [Remote host closed the connection]
thelema has joined #ocaml
gnuvince has quit [Ping timeout: 252 seconds]
Xizor has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
<invariant>
Is there something like Fabric (Python) for OCaml?
paolooo has joined #ocaml
ocp has quit [Ping timeout: 246 seconds]
travisbrady has joined #ocaml
<flux>
it would help if you told what Fabric is :)
travisbrady has quit [Client Quit]
<invariant>
flux, Fabric is a Python (2.5 or higher) library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks. It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting execution.
<flux>
I don't think there is anything like that for ocaml
<Yoric>
So, I have at hand a student interested in getting started with OCaml by writing a parser.
<Yoric>
Which parser generator should I suggest these days?
<flux>
I think Merlin was nice
<flux>
better all around than ocamlyacc
<Yoric>
Anything is better than ocamlyacc :)
<flux>
hmm, it's not merlin the name I think..
<Qrntz>
it's Menhir
<flux>
yes :)
<Qrntz>
you confused me for a bit there
<flux>
yoric, well, I think gnu bison isn't better at writing parser than ocamlyacc :)
* Yoric
wonders if he can place a good pun involving stone age (ocamlyacc, bison, ...) and Stonehedge.
travisbrady has joined #ocaml
<invariant>
Yoric, if you want to interest a student, give them parser combinators.
<invariant>
Yoric, yacc level tools are low-level and only of interest for speed.
<Yoric>
Actually, he's not my student.
<invariant>
Actually, a good project would be to build a compiler from parser combinators to yacc.
<invariant>
That is, for the part of the grammar for which that is actually possible.
<invariant>
Naturally, such analysis would have to be done automatically with some maximum execution time of 30 minutes for example.
InfinityL has joined #ocaml
<Yoric>
Well, tell that to InfinityL :)
<Yoric>
Although I understand that he only wants something simple to get started.
<flux>
parser generators are nice in that they can produce other kind of diagnostics than doesn't compile/does compile/infinite loop
<InfinityL>
ah Yoric....you are here :-)
<invariant>
flux, which is why good software uses both.
<flux>
invariant, uses both? both parser generators and parser combinators?
<invariant>
flux, first a quick input assuming everything is ok, and then when there is a failure, reparse again.
<invariant>
flux, (with the slower approach)
<flux>
invariant, ..at run time
<invariant>
flux, yes
<flux>
invariant, I mean that parser combinators are able to tell about mistakes even before running it
<InfinityL>
ok...i think I need to look at your earlier discussion to understand what you guys are talking about....gimme a sec
<invariant>
flux, most software projects only implement one of the two.
<invariant>
flux, either a slow parser with good error messages or a fast parser with broken error messages.
<InfinityL>
invariant flux: Ummm....don't mind me asking this...but what are parse combinators?
<flux>
invariant, but don't you get close to best of both worlds with lexer+parser generator?
<flux>
invariant, basically you have simple functions and you build the parser out of them
<flux>
oops, infinityl
<flux>
infinityl, for example you have a function for expressing 'is the next character the same as X?'
<flux>
and then a function for expression 'is this followed by rule1 OR rule2?'
<InfinityL>
ohk...
<invariant>
flux, I have never seen someone do that, so I assume it's not practical.
<flux>
invariant, you've never seen anyone use parser generators?
<invariant>
flux, no, use parser generators in such a way that the errors produced are absolutely fantastic.
<InfinityL>
Is there any good place (links or books) I can look at to work on designing a simple compiler (gotta do it by next weekend) for a subset of a language?
<flux>
invariant, I don't think I've ever seen a parser that produced absolutely fastatic errors, full stop.
<InfinityL>
If its too much to do within that time can you point me to how I can build a reursive descent parser using OCaml ?
<invariant>
InfinityL, by next weekend?
<invariant>
InfinityL, is this an assignment for university?
<InfinityL>
invariant: 25th...kind of but not exactly
<Yoric>
InfinityL: I thought you just wanted the parser?
<InfinityL>
I told my prof I didn't like the her assignments that much as they were using java and she told me to suggest something that I was interested to do
<InfinityL>
I thought trying out something in OCaml would be a good idea
<InfinityL>
Yoric: Yeah, actually the parser is sufficient
<InfinityL>
invariant: you seem surprised that it was a uni assignment! :)
<invariant>
InfinityL, I asked whether it was one.
<invariant>
InfinityL, I did not get an answer.
<invariant>
InfinityL, hence, no surprise.
<invariant>
InfinityL, only surprise was that there was no answer.
<InfinityL>
invariant: nope....something I'm interested in doing and showcasing
<invariant>
InfinityL, there is nothing special about parsing.
<invariant>
Sure, you can do a PhD. on it.
<invariant>
But you can also become an F1 race car driver.
<InfinityL>
if you wanna know if I'm gonna get marks for it...yeah! I might!
ftrvxmtrx has quit [Quit: Leaving]
<InfinityL>
invariant: basically we are supposed to implement a recursive descent parser in Java...I missed that lab. So I decided to do it in OCaml instead....if you've got something interesting that I could work on in a week it'd be really helpful :-)(of course other than parsing)
<invariant>
InfinityL, sounds like a good plan to get an F unless you agreed upon this already.
<InfinityL>
:P
<InfinityL>
is it that bad?
<invariant>
InfinityL, if you did not discuss this, it's a very stupid step to make.
<invariant>
InfinityL, if you did, then there is still no reason to expect anyone to care about it.
jamii has joined #ocaml
<InfinityL>
invariant: chuck it then....lets forget about the assignment and try to do something interesting then :-)
<InfinityL>
And don't worry this is just some bonus thingy...not really gonna affect my grade that much ;)
<InfinityL>
invariant flux : Some good place to get started with parse generators please? Sounds fun to try out!
<scp>
with that, the expression "Leaf {elem = a}" yields the error "Error: Some record field labels are undefined: left right"
gnuvince has joined #ocaml
<yezariaely>
ah ok, then the error message is difficult to understand
<yezariaely>
yes, it is an error.
<yezariaely>
prefix your fields somehow. or put them in different modules.
<scp>
x_X that's frustrating
<scp>
thanks
<yezariaely>
yes, it is one of the "problems" ocaml has.
<yezariaely>
Though with prefixing/modulepacking it rarely occurs.
Yoric has quit [Ping timeout: 246 seconds]
<scp>
eh, I run into this in haskell too
<adrien>
scp: that is quite likely to evolve in the coming months but for now, how could the type inference mechanism guess which record type is the right one?
<scp>
the "Leaf" constructor should be a proper hint here
<scp>
I dunno how the type inference algorithm works, but one could imagine a system where the invokation of a function taking an argument of type 't means "what's coming next is a 't"
<scp>
s/invok/invoc
<scp>
it is just a common use case to have a bunch of variations of a sum type to have a common field. For example, to all have a "name" field
larhat has quit [Quit: Leaving.]
<yezariaely>
adrien: it could theoretically be possible to choose the right one by name of the fields + length of the record. OCaml does not support record subtyping, doesn't it?
InfinityL has quit [Quit: Leaving]
<yezariaely>
then still, the types of the fields might be different.
<yezariaely>
The type checker should be capable of that, shouldn't it?
<scp>
or maybe it could check for ambiguity in fieldnames when they types are declared, rather than when they're used
cago has left #ocaml []
Neros has joined #ocaml
ker2x has joined #ocaml
<ker2x>
friendly greetings \o/
<ker2x>
i need lablgtksourceview2.cmxa to compiole frama-c. it wasn't in the .deb package so i compiled lablgtk-2.14.2 but i still doesn't have this .cmxa file. any idea how to create it please ?
<ker2x>
configure: WARNING: lablgtksourceview2.cmxa not found
<ker2x>
configure: error: gui requested but /usr/lib/ocaml/lablgtk2/lablgtksourceview2.cmxa missing.
<Leonidas>
heh, I see the patch enables ocamlopt on raspbian. And there I was hoping to be the first ocaml user on the Pi :)
<Leonidas>
thelema: great, will do.
<orbitz>
How does #use "topfind" actually work?
<orbitz>
Does it serach OCAMLPATH?
<thelema>
orbitz: you can read the topfind file for details
<orbitz>
I'm trying to figure out why #use "topfind" isn't working for me
<thelema>
/usr/local/lib/ocaml/topfind
<Leonidas>
Not to come off as a pessimist, I also have to mention that I quite like the docs and they are quite pretty to look at, so someone did a good job :)
<thelema>
(or wherever your compiler library is)
<orbitz>
thelema: Is that hardcoded into where #use looks or can I modify it?
<thelema>
orbitz: there might be a path for #use... try modifying OCAMLLIB
<orbitz>
hrm OCAMLLIB appears to take 1 dir, not several
<orbitz>
There is OCAMLPATH but I think that is just for ocamlfind