* 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.
<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.
<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
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.
<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