flux changed the topic of #ocaml to: Yes, inria.fr is back up! | Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.0beta1 available from http://caml.inria.fr/pub/distrib/ocaml-3.11/ | Or grab OCaml 3.10.2 from http://caml.inria.fr/ocaml/release.html
Fullma has joined #ocaml
apples` has joined #ocaml
bluestorm has quit [Remote closed the connection]
code17 has quit ["Leaving."]
alexyk has quit []
alexyk has joined #ocaml
Fullma` has joined #ocaml
Fullma has quit [Nick collision from services.]
Fullma` is now known as Fullma
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
LatentJam has quit [Client Quit]
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
Camarade_Tux has quit [Client Quit]
Camarade_Tux has joined #ocaml
Guest92775 has joined #ocaml
Guest92775 has quit [Client Quit]
Camarade_Tux has quit ["Leaving"]
Guest94762 is now known as purple
purple is now known as Guest71770
seafood has quit []
struktured has quit [Read error: 110 (Connection timed out)]
Amorphous has quit [Read error: 110 (Connection timed out)]
davidm123 has joined #ocaml
Amorphous has joined #ocaml
zerny has quit [Remote closed the connection]
struktured has joined #ocaml
prime2 has quit ["leaving"]
Associat0r has quit []
struktured has quit [Read error: 60 (Operation timed out)]
alexyk has left #ocaml []
tar_ has joined #ocaml
MelanomaSky has joined #ocaml
davidm123 has quit ["ChatZilla 0.9.83 [Firefox 3.0.4/2008102920]"]
sporkmonger has quit []
sporkmonger has joined #ocaml
jeddhaberstro has quit []
threeve has quit []
mib_opwy65m9 has quit ["http://www.mibbit.com ajax IRC Client"]
<palomer> well...
<palomer> it's ready for release
seafood has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
sporkmonger has quit []
_zack has joined #ocaml
ygrek has joined #ocaml
<MelanomaSky> Is '$' a special character in OCaml?
<flux> well, it depends
<flux> it is usually avoided, because it's used in camlp4
<flux> but technically if you don't use campl4, you can use $ as an operator
<MelanomaSky> flux: Heh what about in the name for a "%token" declaration in an ocaml-yacc file? :x
<MelanomaSky> As in "%token CHR$"
<flux> hmm.. did that end up being an ocaml identifier? if so, it won't work
<flux> you cannot have an identifier with both operator and non-operator characters in it
<palomer> flux, you a graduate student?
<flux> (and $ is an operator character)
<flux> palomer, if that means a student in a university, then yes
<MelanomaSky> flux: Ahaa.. thanks, I guess I was asking if it was something like that.
<MelanomaSky> btw, what operator is it?
<flux> it's not defined
<flux> you could define it like let ($) a b = a b
<MelanomaSky> Ah okay. But it is reserved I guess specially as 'an operator' ? As opposed to being able to be used as an identifier..
<flux> yes
<palomer> make it right associative and you get the haskell operator!
ygrek has quit [Remote closed the connection]
Snark has joined #ocaml
_zack has quit ["Leaving."]
_zack has joined #ocaml
apples` has quit [Read error: 104 (Connection reset by peer)]
filp has joined #ocaml
apples` has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
ygrek has joined #ocaml
hkBst has joined #ocaml
pango has quit ["Terminated with extreme prejudice - dircproxy 1.0.5"]
apples` has quit ["Leaving"]
pango has joined #ocaml
filp has quit [Read error: 110 (Connection timed out)]
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
_zack has quit ["Leaving."]
filp has joined #ocaml
pango has quit [Remote closed the connection]
Gionne has joined #ocaml
pango has joined #ocaml
code17 has joined #ocaml
hordf has joined #ocaml
filp has quit [Read error: 110 (Connection timed out)]
hordf has quit [Read error: 113 (No route to host)]
<munga> I'm working on a binding wrapper for a c library. Can you point me to a use example of ocamlbuild to compile c bindings ?
_urlwolf_ has joined #ocaml
<munga> never mind. I found the doco on the wiki.
marmotine has joined #ocaml
seafood has quit []
Camarade_Tux has joined #ocaml
_urlwolf has quit [Read error: 110 (Connection timed out)]
ulfdoz has joined #ocaml
LatentJam has joined #ocaml
zerny has joined #ocaml
Gionne has quit ["Leaving"]
vixey has joined #ocaml
bzzbzz has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
marmotine has quit [No route to host]
<rwmjones> 'noon
<rwmjones> anyone familiar with the Format module? would like to comment on whether the following program is correct:
<rwmjones> on Linux it prints
<rwmjones> contents of buffer = "This is a string"
<rwmjones> but on Windows it prints
<rwmjones> contents of buffer = ""
<rwmjones> & I'm wondering if it's a bug in the program or in my cross-compiler
<Camarade_Tux> have you tried running it directly on windows, with regular ocaml on windows ?
<rwmjones> no my windows box is fscked at the moment, so I'm running it in wine
<rwmjones> it does seem like a compiler bug though. All the docs I can see for Format indicate i'm using the module right.
<Camarade_Tux> my virtual machine is starting ;)
<rwmjones> actually I could try the regular compiler under wine ...
<rwmjones> yeah, that works, so it's a bug in the cross-compiler :-(
<Yoric[DT]> :/
<Camarade_Tux> works correctly for me too
* rwmjones has a spark of inspiration ... perhaps the bug is in the Buffer module
<Yoric[DT]> You needed to reimplement buffer?
* Yoric[DT] seems to remember that Buffer is implemented in OCaml.
dabd has joined #ocaml
bluestorm has joined #ocaml
<bluestorm> Yoric[DT]: are you in an accepting state ?
<Yoric[DT]> Yeah.
* Yoric[DT] was about to try and implement "better finalize".
<bluestorm> and i have some surface syntax questions
<bluestorm> hm
<bluestorm> first : i'm not sure anymore that foo <- List bar stuff is useful
<bluestorm> as we could use foo <- List.enum foo instead without any sugar
<bluestorm> a bit longer, but less special syntax cruft to remember
<Yoric[DT]> Well, List.enum foo is more generic but [List bar] will let us perform optimizations at a later stage.
<Yoric[DT]> To avoid going through Enum when we're converting a list to a list.
<bluestorm> hm
* rwmjones thought this assembler warning wasn't going to be entirely benign:
<rwmjones> /tmp/camlasm0ea8fb.s:5594: Warning: 9223372036854775807 shortened to 4294967295
<rwmjones> and indeed that is the cause of the problem
<bluestorm> Yoric[DT]: if we still want special surface syntax for list, array and lazylist comprehensions, we could put the optimizations there instead
<Yoric[DT]> bluestorm: won't that make it harder to write the special surface syntax for list, array and lazylist?
<bluestorm> the problem with the optimisation inside the generic syntax is that we could either optimize for some "known" modules such as List/Array, or optimize for every module, but then we have to assume that every module used has eg. fold_right and concat
Camarade_Tux has quit ["Leaving"]
<Yoric[DT]> fold_right?
<bluestorm> neither solutions being particularly elegant (in absence of a standardized interface for containers we could propose)
<bluestorm> fold_right is used as an optimisation in the List case
<Yoric[DT]> For which purpose?
<bluestorm> hm
<bluestorm> the equivalent of my filter_map iirc
Camarade_Tux has joined #ocaml
<bluestorm> the "fold_right" example is not very important, the point is that if we want to "stay inside the module" we will have to expect the module to have some arbitrary functions
<bluestorm> it's (generally) a correct assumption for List Array and such, but if we want to optimize Foo [? ... | bar <- Foo baz ] , see ?
<Yoric[DT]> Well, we have [map_filter] already, which I guess we could impose.
<Yoric[DT]> I'd say it's slightly more general (in terms of supporting more data structures) than [fold_left]/[fold_right].
<Yoric[DT]> I understand that.
<Yoric[DT]> And I have no problem with this.
<bluestorm> ok
<Yoric[DT]> At worst, we'll need to define a standard interface for comprehension-compatible data structures.
<Yoric[DT]> Since standard interfaces are your job anyway :)
<bluestorm> (regarding your "harder to write" question i can still generalize some function afterwards)
<bluestorm> hm
<bluestorm> and do you have a bright idea regarding the surface syntax ?
<bluestorm> i've settled for [? ... | ... ] , wich is not very satisfying
<Yoric[DT]> The generic one?
<bluestorm> but [ ... | .. ] feels too much like a list, and i think { ... } ought to be record-only syntax
<bluestorm> yes
<Yoric[DT]> mmmhhh....
<Yoric[DT]> What about [< ... | ... >]?
<bluestorm> i've had a look at wikipedia, Nemerle use $[ ... ] , Haskell is list-only and python/C#/F# use keywords instead (for .. in ...)
<Yoric[DT]> I know it may be shocking but, well, we're creating a new Enum and Enum is the replacement for Stream.
<Yoric[DT]> I don't like $[...] too much, in addition to which it's bound to cause problems with Camlp4.
<bluestorm> of course, and nobody cares about Nemerle anyway
<bluestorm> i was just comforted to see another asymetric choice :p
<Yoric[DT]> And [for...in...] only solves the problem of "|" and "<-", not the outer syntax.
<Yoric[DT]> :)
<Yoric[DT]> I'd go for [< ... | ... >] .
<bluestorm> and [: ... | ... :] for revised ?
<Yoric[DT]> Yeah.
<Yoric[DT]> Unless that causes problems with `.
<bluestorm> hm, that may cause problems
<bluestorm> (do you indent to replace [< ... >] with enums everywhere ?)
<Yoric[DT]> At some point, yes.
<Yoric[DT]> After all, Enum is a more powerful version of Stream.
<bluestorm> hm
<bluestorm> why not
<bluestorm> hm
<bluestorm> Yoric[DT]: with strict structures, is there not a risk that changing Enum.filter with Foo.filter during optimisations could change the behavior (regarding side effects) ?
<Yoric[DT]> Do you have an example?
<bluestorm> hm
<bluestorm> Foo [? x | x <- Foo bar | pred1 x && (print_endline "pred1"; true); pred2 x && (print_endline "pred2"; true) ]
<bluestorm> "| pred1" -> "; pred1"
<Yoric[DT]> What exactly is the issue here?
<bluestorm> i expect enum to test pred1 then pred2 for all elements in order, and a strict structure to test pred1 on all elements first, then pred2
<Yoric[DT]> Mmmhhh...
<Yoric[DT]> Is that a big issue?
<Yoric[DT]> If it is, we could combine filters automatically.
<bluestorm> well i envisaged that possibility, and thought that the user may want the choice between f; g and f && g
<Yoric[DT]> Do you think so?
<bluestorm> hm.
<bluestorm> we could just say "side effect behaviours are undefined"
<bluestorm> that's probably the most sensible choice anyway
<Yoric[DT]> I think so.
dabd has quit [Client Quit]
<Yoric[DT]> Under which circumstances would the user choose ; rather than &&?
<Yoric[DT]> Actually, what the heck does ";" mean?
<Yoric[DT]> Is there a difference with the usual ";"?
<bluestorm> hm
Gionne has joined #ocaml
<bluestorm> ; as a comprehension_item separator is different
<Yoric[DT]> Oh, I hadn't seen your substitution :)
<Yoric[DT]> ok
<Yoric[DT]> Yes, I'd say that side effects should be undefined.
<bluestorm> (we should ensure, though, that each predicate will be tested at most once)
<bluestorm> btw
<bluestorm> Enum lacks Enum.enum and Enum.of_enum :]
<bluestorm> (away for a couple of minutes)
<Yoric[DT]> Care to add it? :)
<bluestorm> well i'll try my first git commit ever on non-vital parts first
<Yoric[DT]> ok
<thelema> Yoric[DT]: your changes didn't fix the 'Concurrent' bug.
<Yoric[DT]> Didn't they?
<Yoric[DT]> Gasp.
<Gionne> i do i return a Ast.Prodset type (line 36)? can i? http://pastebin.ca/1257671
<Yoric[DT]> When do you meet that bug?
* thelema pushes an example that fails
* Yoric[DT] pulls
<thelema> just [make examples] - the parallelsort program should fail compilation
<Yoric[DT]> Er... at the moment, it's [Rope.replace_chars] which fails.
<bluestorm> Gionne: what's the issue ?
<thelema> oops. :(
<thelema> sorry, fix pushed.
<bluestorm> Gionne: { Ast.Gram ( Ast.Symbol($2), Ast.Prodset [($4)] ) } => { Ast.Gram ( Ast.Symbol($2), $4 ) }
<bluestorm> line 31
* Yoric[DT] rebuilds.
<bluestorm> (do you really want those Symbol and Body keyword everywhere ? wouldn't and symbol = string be lighter ?)
<Gionne> i really don't know
<Yoric[DT]> thelema: wfm
<Gionne> i need to return types
<thelema> really...
* Yoric[DT] checks if he may have forgotten to commit something.
<Yoric[DT]> Ah, no.
<Yoric[DT]> Weird.
<Gionne> in main: the type gram
<Yoric[DT]> Ok, depends on how I build it.
<Gionne> in rest: the type prodset
<Gionne> in prodset: the type prodset
<Yoric[DT]> thelema: if I build it without threads, it seems to work.
<thelema> if you build what without threads?
<Gionne> in prod: the type prod
<Gionne> how do i do that?
<Yoric[DT]> thelema: the example
* Yoric[DT] wonders how the example can build without threads.
<thelema> me too.
<Yoric[DT]> Oh, no, that was me actually building the wrong sample :/
bzzbzz has joined #ocaml
<thelema> heh.
<thelema> n/p
<Yoric[DT]> mmmhhh...
<Yoric[DT]> That's weird
code17 has quit [Remote closed the connection]
marmotine has joined #ocaml
<Gionne> prodset: prod { [$1] }
<Gionne> | prod prodset{ [$1 :: $2] }
<Gionne> i need a type prodset here
<bluestorm> Gionne: http://pastebin.ca/1257691
<bluestorm> prodset will produce a prod list, wich is simpler than a prodset and fit to your grammar better
<Yoric[DT]> thelema: Concurrent is actually the first item of extlib.mlpack .
<Yoric[DT]> Why it's not included is a mystery to me...
<Gionne> uhm
<Gionne> but prodset is a prod list
<Gionne> thanx for now bluestorm
<bluestorm> Gionne: you could even use http://pastebin.ca/1257696
code17 has joined #ocaml
<Gionne> i'm trying
<bluestorm> (untested code)
<bluestorm> (btw., your error reporting sucks : printing something on stdin and returning a dummy value is just wrong)
<Gionne> the printf is just a testing help. i'm totally newbie and i really don't know what to do. is my final exam at university :(
<bluestorm> :p
<bluestorm> i've almost never used ocamlyacc, there must be a yacc-specific error-reporting function, but you should at least consider using basic OCaml exceptions such as { failwith "invalid blah" }
<bluestorm> (you wouldn't have to build the dummy value, as failwith's type is (string -> 'a) )
<Yoric[DT]> Gionne: you mean today is your final exam?
<Gionne> the learning curve is really steep
<Gionne> not today
<Gionne> when i'll be finished
<Yoric[DT]> Yeah, ocamlyacc is not the best way to start OCaml.
<Yoric[DT]> ah, ok
<Gionne> i have to make a parser that analizes a grammar in input and tells if it's LL(1)
<bluestorm> (i suppose he learned ocaml before using ocamlyacc, orelse he would probably use an other yacc clone)
<Gionne> not so easy, my first ocaml program
<Gionne> usually i use imperative languages like c, c++ or java
<Gionne> ocaml is a "bit different"
<Gionne> :)
thelema has quit [Read error: 110 (Connection timed out)]
<bluestorm> hm, and you can't use plain yacc for your exam ?
<Gionne> i don't know what it is
<Yoric[DT]> Or OCaml's Genlex?
<bluestorm> (i believe ocamlyacc is superior to yacc/bison due to the elegance of OCaml algebraic datatypes, but if you don't know OCaml ... :p )
thelema_ has joined #ocaml
<Gionne> the teacher suggested to use ocamllex/ocamlyacc
<Gionne> then ocaml to write the rest of the functions
<Yoric[DT]> Well, for writing the rest of the functions, OCaml is undoubtedly both better and easier.
<Yoric[DT]> It's just that ocamllex/ocamlyacc is not the easiest way of starting OCaml.
<Yoric[DT]> ("better and easier" than C/C++/Java, that is)
<Yoric[DT]> Personal suggestion: start by writing the other functions and only then start learning ocamllex/ocamlyacc.
<Gionne> mmm
<Gionne> but i was able to make it working
<Gionne> without using types
<Gionne> then i added types because i thought that calculating the "first" function would be easier with higher level types than "string"
<Yoric[DT]> Usually, not using types is a bad idea :)
<Gionne> but now i have some problems in make it working
<Gionne> so i should always make my own types?
<bluestorm> Gionne: if you can read french, I have an url from a homework assignment describing what you're trying to do, with types provided (but no lex/yacc part though)
* Yoric[DT] should take a look at your code before proceeding.
<Gionne> :(
<Gionne> don't know french
<Gionne> but i'll try the same
<bluestorm> Yoric[DT]: considering the "unary and/or infix constructors", do you have an opinion on the lexical definitions ?
<bluestorm> haskell has generalized infix constructors, and they use "any infix operator beginning with ':' "
<bluestorm> but they don't have generalized unary constructors
<Yoric[DT]> Prefixing infix constructors with : sounds fair to me.
<Yoric[DT]> thelema_: pushing fix.
thelema_ is now known as thelema
<thelema> Yoric[DT]: it looks like both of us need to get better at using [git stash]
<Yoric[DT]> I'm not quite sure about unary constructors, though.
<Yoric[DT]> thelema: stash?
<Yoric[DT]> What's that?
<Yoric[DT]> bluestorm: how would you write the lazy list with only one element, btw?
<thelema> when you're in the middle of something, but want to make a small change elsewhere, you stash your current work, make the other change, check it in, and then pull your previous code out of the stash.
<Yoric[DT]> Interesting.
<bluestorm> Yoric[DT]: x :^ unary_constructor ?
<thelema> Yoric[DT]: good job fixing the Concurrent problem.
<Yoric[DT]> thanks
<Yoric[DT]> bluestorm: not quite as nice as the usual list
<Yoric[DT]> bluestorm: not quite as nice as the usual list syntax
<bluestorm> true
<bluestorm> i'm beginning to think that binary infix constructors are nearly useless except in the various list case
<bluestorm> cases
<Yoric[DT]> So maybe we just write an ad-hoc syntax extension just for lazy lists?
<bluestorm> so that maybe we should keep the ad-hoc syntaxic sugar
<Yoric[DT]> :)
<bluestorm> (should we add another extension for "mutable list" later, there are a finite and quite small number of possibilities)
<Yoric[DT]> ok
<bluestorm> we could stick to the "prefixed wich :" convention and use :^ instead of your ^:^ for consing, though
<Yoric[DT]> Either :^ or ::^, as you think is best.
<Yoric[DT]> But yeah, that's nicer than ^:^ anyway.
<bluestorm> :^ has the advantage of being shorter :p
<Yoric[DT]> :)
<Yoric[DT]> Other symbols are ok with me, too, btw.
<Yoric[DT]> I mean, I have nothing against, say, :%.
<vixey> what does Osakasi use?
<Yoric[DT]> $
<Yoric[DT]> Which wreaks havoc with Camlp4.
<vixey> Okasaki*
<bluestorm> but he uses $ as a generic lazy marker, is there a list-specific syntax ?
<Yoric[DT]> Can't remember.
<Yoric[DT]> I think there is, but I'm not sure.
<thelema> to add [enum] and [of_enum] to Set, I need to make an extSet in extlib?
<Yoric[DT]> There's one already.
<Yoric[DT]> And it has [enum] and [of_enum].
* thelema feels silly
<thelema> then what purpose for batlib_Baselib_Set?
<Yoric[DT]> Did I forget to remove it?
<Yoric[DT]> Ok, removed :)
_urlwolf_ has quit [Read error: 110 (Connection timed out)]
<thelema> Yoric[DT]: the claim that ExtSet.Set.enum returns an increasing order enum -- is yours, no?
<thelema> it looks like you're doing a pre-order traversal, which doesn't give sorted order.
jeddhaberstro has joined #ocaml
<Yoric[DT]> thelema: iirc, I'm using the same order used for [iter] and the documentation of [iter] guarantees this increase.
<thelema> hmmm...
<thelema> nope, you're not.
<thelema> [iter] does: iter f l; f v; iter f r
<thelema> note the recursive call first.
<thelema> enum does: Queue.push l queue; Queue.push r queue; e
<thelema> the first enum returned is the root of the tree.
<Yoric[DT]> erf, you're right
* Yoric[DT] knew he should have gone for the simple strategy without attempting to optimize things with Queue.
<thelema> should we have an [enum_decreasing] and [enum_increasing]?
<thelema> your current code seems the most efficient way to enumerate a set.
<Yoric[DT]> Well, we could have [enum] and [backwards], as in other data structures.
Gionne has quit ["Leaving"]
<thelema> oh yeah, [backwards]
<thelema> and just drop the pre-order traversal.
<Yoric[DT]> The current enumeration would become [backwards], I guess.
<thelema> no.
<Yoric[DT]> No?
<Yoric[DT]> Erf, you're right, no.
pango has quit [Remote closed the connection]
<thelema> are you implementing, or shall I?
<Yoric[DT]> I am.
<thelema> ok. I'll go back to cf-lib integration
<Yoric[DT]> Ok, this seems implemented.
<Yoric[DT]> cf-lib?
<thelema> yes, part of that ocnae thing. Has some great data structures for heap/queue
<Yoric[DT]> ok
<thelema> also, some TAI support that'll come in useful. (Temps Atomique International)
<thelema> oh yes, and an amazing dequeue.
<Yoric[DT]> er... ok
<Yoric[DT]> We'll need to find the right place to put that :)
<thelema> O(1) on every operation.
<Yoric[DT]> Does this aim alpha 3 or something further away?
pango has joined #ocaml
<thelema> cf-lib is already packaged for findlib - it should be pretty easy to get this code in by alpha 3
<Yoric[DT]> ok
<Yoric[DT]> pushed
* thelema wishes Yoric[DT] hasn't reformatted parallelsort.ml
<Yoric[DT]> Sorry.
<Yoric[DT]> I also fixed a tiny mistake along the way, though :)
<thelema> the fact that main never got ran isn't a problem - that version didn't really sort anyway.
<Yoric[DT]> Ok, ok, so I never did fix anything.
<Yoric[DT]> My bad.
<thelema> it just split up the array, sorted the subparts and then output the subparts.
<thelema> your version is *slightly* better than mine, but both falling way short.
<thelema> yes, I can see that being pretty boring.
<thelema> nice syntax for it, though.
<Yoric[DT]> thanks
<Yoric[DT]> My version of what?
<Yoric[DT]> Of parallelsort?
<thelema> module List = List include Labels
<Yoric[DT]> And what was your version?
<thelema> of parallelsort?
<Yoric[DT]> I think we have a communication issue :)
<Yoric[DT]> <thelema> your version is *slightly* better than mine, but both falling way short.
<Yoric[DT]> => my version of what?
<thelema> your version of parallelsort is slightly better.
<thelema> <topic change>
<Yoric[DT]> Ah, ok.
<thelema> nice syntax for Labels
<Yoric[DT]> By the way, I may have a volunteer for the syntax extension wrt unicode.
<Yoric[DT]> (the author of estring)
<thelema> excellent.
<mfp> Yoric[DT]: had forgotten about this... the Batteries + OMake HOWTO -> http://www.eigenclass.org/sp.cgi/view/rxpfak
<Yoric[DT]> thanks
<mfp> should probably go under doc/batteries/USAGE
Jedai has joined #ocaml
<mfp> (wanted to check that it actually worked first, and getting 3.11 + GODI + Batteries to work took a while)
<thelema> mfp: there's a fixed version of type-conv?
<mfp> I patched it myself
<thelema> aha.
<bluestorm> (it took me a while to figure what "rxpfak" could possibly mean)
<mfp> if you're using godi, you have to save the patch as GODIDIR/build/godi/godi-type-conv/patches/patch-00-pa_type_conv
<thelema> mfp: that's it? just drop the ?'s
<mfp> and then update GODIDIR/build/godi/godi-type-conv/distinfo
<mfp> yes
* thelema doesn't use godi.
<mfp> that's it, I think --- I couldn't find any other meaning for <:ctyp< ? >> when reading Camlp4OCamlRevisedParser.ml
pango has quit [Remote closed the connection]
<mfp> and it makes sense if you consider this code: let coll drv der_sis = <:str_item< $der_sis$; $generate tp drv$ >> in List.fold_right coll drvs <:str_item< ? >>
<mfp> <:str_item< >> is a valid, empty, struct item
* thelema doesn't speak camlp4
<Yoric[DT]> mfp: I'm integrating this into the documentation, thanks.
<mfp> np
pango has joined #ocaml
<bluestorm> mfp: btw, i've uploaded the latest pa_where version (to match the in-batteries version) , http://bluestorm.info/camlp4/pa_where/pa_where.ml.html
<Yoric[DT]> Documentation updated.
* mfp saves pa_where.ml.html for reference + see how it's changed with diff
|Jedai| has quit [Read error: 110 (Connection timed out)]
* thelema has the feeling that batteries should have only one copy of Set.OrderedType -- in interfaces.ml, perhaps?
<bluestorm> Yoric[DT]: i'm having metaphysical questions about comprehensions
<bluestorm> mostly motivated, I should say, by the uglyness of your pa_comprehension.ml code :-'
<bluestorm> i'm even considering dropping a specific comprehension syntax in favor of a monad comprehension (do/perform ...) that would play well with Enum
<Yoric[DT]> bluestorm: ugly yourself :)
<Yoric[DT]> thelema: I agree with that feeling. It's bluestorm's job to decide where to put this :)
<Yoric[DT]> bluestorm: er...
<Yoric[DT]> I have thought about monad-style comprehension with Enum, but that seems a quite different thing, doesn't it?
<bluestorm> well wouldn't (perform p <-- 2--1000; guard (prime p); p) and [< p | p <- (2--1000); prime p >] be equivalent ?
<Yoric[DT]> possibly
<thelema> Yoric[DT]: uh oh. documentation doesn't build because of syntax error on [module Array = Array.Cap include ExceptionLess]
<Yoric[DT]> gasp
<Yoric[DT]> mmmhh....
* Yoric[DT] will try and find a solution to this.
<Yoric[DT]> Is this urgent?
<thelema> no.
<thelema> if you like I'll throw it on the bug tracker
<Yoric[DT]> Yes, please.
_urlwolf_ has joined #ocaml
<bluestorm> Yoric[DT]: it's quite a miracle your comprehension extension didn't conflict with the Camlp4OcamlParserParser version (wich is enabled by default in camlp4o iirc)
<Yoric[DT]> Possibly.
<bluestorm> seems camlp4 is able to survive when the same grammar entries are created twice
* Yoric[DT] never pretended that this syntax extension was a model of proper coding.
<Yoric[DT]> actually, iirc, that was my first syntax extension
<bluestorm> :p
<bluestorm> well i wouldn't pretend i can do much better, but the amout of code pasted from the camlp4 sources is a bit suffocating
<bluestorm> i'm gonna try to link to their module instead, but i'm afraid we may have to keep it inlined
pango has quit [Remote closed the connection]
pango has joined #ocaml
<Yoric[DT]> good luck :)
<thelema> hmmm...
<thelema> The files /home/thelema/bin/ocamlcvs//lib/ocaml/site-lib/batteries/batteries_help.cmo
<thelema> and /home/thelema/bin/ocamlcvs//lib/ocaml/site-lib/batteries_nothreads/batteries.cma
<thelema> disagree over interface Extlib
<Yoric[DT]> Normally, I've fixed this.
<Yoric[DT]> You should try and run "autoconf && ./configure" to regenerate the Makefile.
<thelema> could be because I'm running bocaml out of the source tree?
ofaurax has joined #ocaml
<thelema> n/m, fixed by regen of Makefile
<thelema> Yoric[DT]: you fixed the 1--10 bug?
<Yoric[DT]> Yep.
<Yoric[DT]> Normally.
<Yoric[DT]> Why, do you still have it?
<thelema> no, I just wanted to close the bug
<Yoric[DT]> ok
<Yoric[DT]> I should still handle MapLabels, StringLabels and UnixLabels.
* Yoric[DT] is tired.
* Yoric[DT] will take a break of re-de-re-labelizing stuff.
<Yoric[DT]> (on these words, we have reached 832 downloads, which is quite nice)
<thelema> not enough. But we're still in alpha, so...
<Yoric[DT]> Well, for an alpha version, I'd say it's nice.
<sscj> Batteries is in archlinux's AUR now http://aur.archlinux.org/packages.php?ID=21560
<thelema> sscj: do we thank you for this?
threeve has joined #ocaml
<sscj> yes :>
<thelema> I wonder how many distros have cf-lib packaged...
<thelema> if we add it as a dependency, it'll have to get packaged.
<thelema> (google ocnae to find cf-lib)
<Yoric[DT]> sscj: thanks :)
<Yoric[DT]> thelema: GODI doesn't seem to have it.
<thelema> really? :(
<palomer> if I use batteries' ropes, and I call length on a string twice in a row, will it twice as long as calling length once?
mr_uggla has joined #ocaml
<Yoric[DT]> thelema: if push comes to shove, I guess I can package it.
* palomer is off
<Yoric[DT]> palomer: yes, it's twice a long.
<Yoric[DT]> palomer: yes, it's twice as long.
<mfp> palomer: with the exception that the 1st call might incur into ~N/256 (N = len in UTF-8 chars) L2 misses, the 2nd probably none
Kerris4 has quit [Read error: 104 (Connection reset by peer)]
Kerris4 has joined #ocaml
<mfp> (iow., in practice the 2nd call might be over an order of magnitude faster)
<mfp> (for long ropes)
jlouis has quit [Read error: 60 (Operation timed out)]
<thelema> palomer: length is a pretty efficient function for ropes - the worst case is that it has to destructure and add the toplevel node.
<thelema> let rec length = function
<thelema> Empty -> 0
<thelema> | Leaf (l,_) -> l
<thelema> | Concat(_,cl,_,cr,_) -> cl + cr
* thelema realizes that [rec] isn't needed
<bluestorm> Yoric[DT]: if i understand correctly, there is a problem with the Ocaml[Revised]ParserParser code : we won't be able to use it without inlining it
<bluestorm> (maybe we could suggest some changes to ertai but that wouldn't help us right now anyway)
<bluestorm> on the other hand i managed to remove the Camlp4ListComprehension's inline code (but it adds a dependency instead)
<bluestorm> this way i have [? .. ] (enums) and [ .. ] (lists) in ~100 lines of code, with reasonable code duplication
<bluestorm> i think i'll keep that and add your [| ... |] and [^ ^] forms, and then see for [< ... >] later
<bluestorm> dinner time
<Yoric[DT]> ok
<Yoric[DT]> Bon appétit.
* mfp had forgotten rope's types included the length
asabil has joined #ocaml
<thelema> determining a utf-8 string's length in chars isn't easy.
<thelema> I was tempted to keep length info at the UTF8.t level
Fullma` has joined #ocaml
tar_ has quit ["byebye"]
Fullma` has quit [Client Quit]
Axle has joined #ocaml
alexyk has joined #ocaml
<palomer> thelema, but isn't it O(n)?
Camarade_Tux has quit ["Leaving"]
<palomer> length is O(1) ?
<Smerdyakov> [String.length] is.
<palomer> I meant batteries' ropes implementation
Camarade_Tux has joined #ocaml
<Yoric[DT]> yep
<Yoric[DT]> It's O(1)
<Yoric[DT]> (actually, it's just a pattern-match + possibly an addition)
Fullma has quit [Success]
<thelema> palomer: Rope.length is O(1). UTF8.length is O(n). String.length is O(1)
<palomer> cool!
* palomer hugs ropes
<Yoric[DT]> Next step: getting a nice syntax for ropes.
<Yoric[DT]> thelema: we should add concatenation operators.
<Yoric[DT]> Any preference?
<palomer> String.concat !
<palomer> there's no function I use more
* Yoric[DT] was thinking about concatenation operators *for ropes*.
<flux> palomer, not even List.map?
<flux> I suppose palomer meant just that, but I guess Rope.concat exists already?
<mfp> any decision on pa_do?
* Yoric[DT] mentioned *operators*.
<mfp> it'd allow Rope.(a ^ b) ...
<Yoric[DT]> Well, I'm for pa_do, but since bluestorm is in charge of Camlp4, I'm waiting for him to give his approval.
_urlwolf__ has joined #ocaml
<thelema> Rope.(^) sounds good to me.
<bluestorm> Yoric[DT]: i'm ok for pa_do inclusion
<Yoric[DT]> Yeah
<Yoric[DT]> hcarty: ping
<palomer> flux, ok, I use List.map and cat_some and filter more
<Yoric[DT]> cat_some?
<bluestorm> and hcarty is probably as knowledgeable as me about camlp4 so he shouldn't wait for me to go on on such things
<Yoric[DT]> Well, he's not part of the project [yet].
<bluestorm> besides, pa-do concernes more than camlp4 only, as a reasonable integration of pa_do would probably impact the libraries much deeper
alexyk has quit []
<Yoric[DT]> Yep.
<palomer> let catSome lst = map from_some (filter is_some lst)
<palomer> I usually do something like catSome (List.map f lst)
<bluestorm> let catSome lst = List.of_enum (Enum.filter_map lst)
ofaurax has quit ["Leaving"]
<palomer> bluestorm, is this more efficient?
<palomer> or is it how you do it?
Axle has quit [Read error: 60 (Operation timed out)]
<bluestorm> probably not, but you could keep the enum instead of coming back to a list
<palomer> so what are your favourite combinators?
<palomer> I also use map_left, map_right and flatten alot
<palomer> (not to mention map_left_right)
alexyk has joined #ocaml
Camarade_Tux has quit ["Leaving"]
_urlwolf_ has quit [Read error: 110 (Connection timed out)]
Camarade_Tux has joined #ocaml
<thelema> palomer: I don't find myself chaining list transformations often
apples` has joined #ocaml
asabil_ has joined #ocaml
asabil has quit [Read error: 110 (Connection timed out)]
det has quit [Remote closed the connection]
det has joined #ocaml
Snark has quit ["Ex-Chat"]
tomh- has joined #ocaml
tomh- is now known as tomh
jlouis has joined #ocaml
asabil has joined #ocaml
asabil_ has quit [Read error: 110 (Connection timed out)]
threeve has quit []
mbishop has quit [Remote closed the connection]
<hcarty> Yoric[DT]: pong
<Yoric[DT]> hcarty: hi
<Yoric[DT]> I won't have much time to discuss this but our Camlp4 manager has approved pa-do :)
mbishop has joined #ocaml
<Yoric[DT]> Now, we need to discuss exactly how to integrate this in Batteries.
<Yoric[DT]> Could you join the Batteries mailing-list and launch the subject?
<hcarty> Yoric[DT]: Sure. I'm happy to help where I'm able.
<Yoric[DT]> You just signed with your blood :)
Camarade_Tux has quit ["Leaving"]
Demitar has joined #ocaml
<hcarty> Yoric[DT]: Everybody makes mistakes...
* palomer signs with a crayola crayon
seafood has joined #ocaml
Camarade_Tux has joined #ocaml
<Yoric[DT]> Well, anyway, could you post a summary of what we should take into consideration to integrate pa-do and Batteries?
<bluestorm> hcarty: i'm sorry i didn't answer you faster
<Yoric[DT]> i.e. what should go into which module, etc.
* Yoric[DT] now has to go.
zerny has quit [Remote closed the connection]
Yoric[DT] has quit ["Ex-Chat"]
<hcarty> bluestorm: Not at all a problem. I've been busy with school/research.
<hcarty> I have not really thought about how pa-do should be integrated in to Batteries. So far, I've just extended the META file to be finer grained.
LatentJam has quit [Remote closed the connection]
ygrek has quit [Remote closed the connection]
<bluestorm> well i suppose the obvious thing is to think about the "phantom modules" Int and Float wich exist in batteries
<bluestorm> we (... you) can change easily batteries to interact better with pa-do when it's worth it, and perhaps the pa-do folks would be interested in changing some things if we propose valuable evolutions :]
<hcarty> bluestorm: Should I join batteries-devel?
<bluestorm> if you're interested, yes
<bluestorm> be aware that Yoric is very quick to use the "assigned to" form in the project managar : it is dangerous to show too much enthusiasm for a specific task in front of him
<det> :-)
<hcarty> :-)
<thelema> if you don't want to do a job, you can un-assign it just as easily as he can assign it.
<thelema> bluestorm: another phantom module: extlib/interfaces.ml
asabil has quit [Read error: 60 (Operation timed out)]
<bluestorm> thelema: you mean we should add more into it ?
<bluestorm> hm
<bluestorm> "type container" is wrong, container should have a parameter
<thelema> interfaces? probably not. I need to push my change that puts OrderedType in there.
asabil has joined #ocaml
hkBst has quit [Read error: 54 (Connection reset by peer)]
<gildor> thelema, bluestorm: I have update your feature request tracker on forge.ocamlcore.org
<gildor> tranfer all item to the new tracker and pure unwanted message
<gildor> pure/purge
threeve has joined #ocaml
<thelema> gildor: thanks, I'll see if I can do.
<gildor> thelema: what can you do ?
bluestorm has quit [Remote closed the connection]
<thelema> oh, I thought that "transfer all item" was an instruction.
<gildor> nope, i do it myself from the DB interface
<gildor> just to tell you that you should not by suprised that everything was move around
<thelema> ok.
<gildor> moved
<gildor> spammer are really the plague of internet
<thelema> if only we had good spammers - all the spam we received was nonsensical
<thelema> what is the protection on the new tracker?
<gildor> you must be authenticated to submit a new item
marmotine has quit ["mv marmotine Laurie"]
<thelema> great.
<thelema> item includes notes?
<thelema> err, comments on existing todos
<gildor> yes, i think so (but you need to test)
<thelema> only old feature request tracker is on project page: https://forge.ocamlcore.org/projects/batteries/
<palomer> do you guys recommend google code or ocaml forge?
<thelema> the new one seems completely invisible (i.e. gone) for unauthenticated users
<thelema> palomer: give ocaml forge a shot - they have great admins. :)
<gildor> palomer: ocaml forge is a better place to give your OCaml library more visibility
<gildor> palomer: it will help you improve your interaction with other ocaml dev.
<thelema> ocaml people will notice releases of your code when they go ... well, I guess people go to the ocamlforge main page.
<gildor> thelema: I don't know for the fact that there is only old tracker on the page
<gildor> thelema: maybe this is a cronjob or maybe this an administration settings
* thelema hopes it's a cronjob.
<thelema> If it's not fixed by tomorrow, I'll have to remember to submit a bug.
<thelema> I can't find a setting in administration
<gildor> no i think Yoric just get want too much anonymous status
<gildor> he set the "non public status"
* gildor making appears the new feature tracker
* gildor is done
<gildor> thelema: update batteries homepage, the tracker is now public
<thelema> thanks.
code17 has quit [Remote closed the connection]
Camarade_Tux has quit ["Leaving"]
dabd has joined #ocaml
vixey has quit ["Ex-Chat"]