<naufraghi>
File "cat.ml", line 9, characters 0-4:
<naufraghi>
Error: Unbound value iter
<naufraghi>
omake all && omake install completed succesfully
derdon has joined #ocaml
<Alpounet>
I guess it needs batteries to be linked to or at least loaded together with cat.ml
Mr_Awesome has quit [Read error: Connection reset by peer]
<thelema>
Alpounet: it's not been updated to work with currentr batteries. old batteries had some build system magic to add in the [open batteries] part
<Alpounet>
yeah I remember
<Camarade_Tux>
but that wouldn't work anyway if you only ran 'ocaml foo.ml' without any argument, right?
<thelema>
true
Mr_Awesome has joined #ocaml
<naufraghi>
and? if someone can guide me, I can add some info to run them and post a patch
<thelema>
naufraghi: 1) add "open Batteries" to the top
<naufraghi>
thelema: done, but: Syntax error
<thelema>
2) compile with ocamlbuild using the instructions in the FAQ
<naufraghi>
is not better to have Batteries and Batteries_mt and not the opposite as now?
<naufraghi>
ocamlfind ocamlc -package batteries,threads -linkpkg -thread cat.ml was OK!
<thelema>
yes it is better. We will switch to that in v2.0, but I'm committed to using semver for versioning, and breaking backwards compatibility is not allowed without a major version bump
<naufraghi>
(at least, no error)
<thelema>
should be fine. I usually use ocamlbuild to compile my projects - it takes care of the ocamlfind stuff for me.
joewilliams_away is now known as joewilliams
<naufraghi>
ok, happy to know it's a restrain and not a choice :)
<naufraghi>
yes, but I'll put this line in the comment in the examples
<naufraghi>
so they will work even for a novice like me :)
<naufraghi>
built but... no output
<thelema>
you have to give it arguments
<naufraghi>
ye yes
<thelema>
self-imposed restriction.
<thelema>
./cat cat.ml
<naufraghi>
./a.out shuffle.ml ... nothing
itewsh has joined #ocaml
<naufraghi>
uh? perhaps the magic "args" is empty
th5 has quit [Quit: th5]
<naufraghi>
thanks thelema, will try again tomorrw!
caligula__ has joined #ocaml
caligula_ has quit [Ping timeout: 252 seconds]
<Camarade_Tux>
can I advise everyone not to use mingw.org and use mingw-w64 instead (they have 32bit toolchains): I can't say mingw-w64 is perfect but at least they fix bugs and don't put completely broken binaries on their website (have fun with bsdtar chocking on \r\n linefeeds... [ fixed in bsdtar's svn btw ])
travisbrady has joined #ocaml
Yoric has quit [Quit: Yoric]
_zack has quit [Quit: Leaving.]
yakischloba has joined #ocaml
avsm has quit [Ping timeout: 260 seconds]
naufraghi has quit [Read error: Connection reset by peer]
naufraghi has joined #ocaml
yakischloba has quit [Quit: Leaving.]
<eldragon>
Camarade_Tux, all under virtualization, linux 64-bit on host and windows xp 32-bit sp2 HVM on guest, forever!
sysop_fb has quit [Read error: Connection reset by peer]
Submarine has quit [Ping timeout: 265 seconds]
joewilliams is now known as joewilliams_away
joewilliams_away is now known as joewilliams
ice_four_phone has quit [Quit: ice_four_phone]
naufraghi has quit [Quit: naufraghi]
deavidsedice has left #ocaml []
deavid has joined #ocaml
maattd has joined #ocaml
maattd has quit [Excess Flood]
maattd has joined #ocaml
maattd has quit [Excess Flood]
maattd has joined #ocaml
albacker has quit [Ping timeout: 260 seconds]
yakischloba has joined #ocaml
albacker has joined #ocaml
ttamttam has joined #ocaml
joewilliams is now known as joewilliams_away
ReachingFarr1 has joined #ocaml
ReachingFarr has quit [Quit: Leaving.]
ReachingFarr1 has left #ocaml []
ReachingFarr has joined #ocaml
<ReachingFarr>
Does anyone know how to tell a parser generator (ocaml-yacc or menhir) to ignore a token and keep going as if it wasn't there? In some cases of my grammar newlines matter, and in others they don't. In this last case I would like the generator to simply throw out any newlines it finds and keep going.
<derdon>
strange grammar
<ReachingFarr>
Well, I wanted to allow the breaking up of long expressions over multiple lines. So if you do (expr) it will use the parentheses instead of the newline to denote the boundaries of the expression.
<mrvn>
Some grammars allow optional symbols. For others you need to write rules with and without newline.
<mrvn>
Maybe do this in the tokenizer. When you see a ( you stop emiting newline tokens till you find a )
Drk-Sd has joined #ocaml
ofaurax_ has joined #ocaml
<mrvn>
Similar to what you do for multiline strings or comments
<ReachingFarr>
mrvn: Ohh, I like that idea.
<flux>
btw, are there robust ways to alter the behavior of tokenizer from the parser?
<ReachingFarr>
mrvn: Thanks. That should solve the problem.
<flux>
because I'm always wondering (when considering doing that) that I don't know how much the parser has received tokens from the tokenizer
<flux>
can I be certain in cases when there should be no backtracking involved?
<mrvn>
flux: depending on the parser that will be many, 1 or 0.
<mrvn>
Isn't it 1 for yacc?
ttamttam has quit [Quit: Leaving.]
<mrvn>
Parser without lookahead are verry rare I think.
<flux>
so if I have rule foo -> (* alter behavior of tokenizer *), it might be that the next symbol is already read in, but the next likely isn't?
<flux>
what I'd like to do would be to tell the parser that 'restart here'. I suppose it might be possible to explicitly restart the parser at certain points..
<mrvn>
flux: possibly garantied.
<flux>
hm, except I would need to know how many tokens it has eaten
<flux>
perhaps the tokenizer could have a 'rewind'-capability
<mrvn>
It depens on the type of grammar and parser. Most common I beliebe is the type that needs one token lookahead.
<flux>
so "I get got token Foo which has unique auxiliary value 42, rewind to that"
<flux>
mrvn, but it doesn't seem very robust to me to rely on that kind of behavior
<flux>
it's very implicit behavior, and possibly very easily broken
<mrvn>
Changing the parser midstream isn't really considered in the existing tools.
<flux>
but, sometimes the decisions to do those kind of tricks you suggested to solve reachingfarr aren't feasible to implement based on the information the tokenizer receives from the stream
_andre has quit [Quit: *puff*]
<mrvn>
I think your best bet would be to use a purely functional parser/tokenizer. Every time you get a token it gives you back a token and a new tokenizer. When you want to rewind you just use the old tokenizer.
<flux>
yes, new kinds of tools could solve this. but I like to use existing tools :).
<mrvn>
But you might still run into problems because the token you get on look ahead might differ from the one you get due to the rewind and then the wrong rule might be picked.
<mrvn>
I think you couldn't use lookahead methods for this but would have to try and roll back.
<flux>
hmm.. I wonder if you would.. if the changed tokenizer would only affect that parsing branch..
{newbie} has joined #ocaml
<mrvn>
flux: it is purely functional. You can just throw anything away and restart with an old tokenizer again.
<mrvn>
You could do comments by fining the '(*' token and then use a tokenizer that returns everything till the '*)' as one token.
ofaurax_ has left #ocaml []
<mrvn>
I have a little optimizing problem. Say you have 12 harddisk of different sizes and you want to build a software raid5 out of it that has the maximum of space with highest (and most even) redundancy.
mbishop has quit [Ping timeout: 240 seconds]
<mrvn>
I have an algorithm that gives me a solution for that by sorting the disks by size and then putting them one next to each other in a box as wide as the largest disk: http://chocos/segments.png
<mrvn>
I'm looking for something that also reduces the number of segments it needs.
<mrvn>
The second block is an example that uses less segments for the same size.
mbishop has joined #ocaml
<mrvn>
I'm wondering if there is something better than exhaustive search.
<ReachingFarr>
So how do I emit a LPAREN token then go into the new lexer function?
<mrvn>
ReachingFarr: you don't go into a new lexer function. The one lexer function already must do this.
<mrvn>
ReachingFarr: If newlines should only be ignored after some LPARENs then you have lost.
<ReachingFarr>
No, they should be ignored after all LPARENS.
<mrvn>
then write your lexer like that
<ReachingFarr>
Haha, I am. I have an additional lexer function like you would have for handling nested comments.
<ReachingFarr>
This one just eats the newlines.
joewilliams_away is now known as joewilliams
<ReachingFarr>
I just need to emit the LPAREN and then transition into the new function. But if I make my action { LPAREN; main_no_newline lexbuf } that is going to evaluate only to the token returned by { main_no_newline lexbuf }, correct?
<mrvn>
flux: some years back I played with this and thought about calling it context sensitive lexing but it really isn't supported with common tools.
<mrvn>
{ num_parens++; LPAREN } and { num_parens--; RPAREN } and the lexer does if num_parens = 0 then main_with_newline else main_no_newline
<mrvn>
at least that would be my starting point
<mrvn>
or have a newline rules that emits no token if num_parens > 0
<ReachingFarr>
OK, different approach than I'm used to but I like it.
<mrvn>
'\n' -> { incr line_number; lexer lexbuf }
<mrvn>
'\n' -> { incr line_number; if num_parens = 0 then NEWLINE else lexer lexbuf } I mean
_unK has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
yakischloba has quit [Quit: Leaving.]
Submarine has joined #ocaml
pimmhogeling has quit [Ping timeout: 265 seconds]
<det>
sounds like you are making a pythonic syntax parser
ygrek has quit [Ping timeout: 245 seconds]
<det>
ReachingFarr, Are you using ocamllex ?
<ReachingFarr>
det: Yes
itewsh has quit [Quit: There are only 10 kinds of people: those who understand binary and those who don't]
<det>
are you inserting indent and dedent tokens ?