* Yoric[DT]
has mysterious "circular dependencies in OCamlbuild"
* Yoric[DT]
has mysterious "circular dependencies" in OCamlbuild
<flux>
let get_nterm = function Prod ((nterm, body)::_) -> nterm
<Gionne>
yes
<flux>
gives you the first one, if any
<Gionne>
if none?
<bluestorm>
(what's the "body" part for ?)
* Yoric[DT]
doesn't quite understand the objective of the program.
<Yoric[DT]>
Gionne: raises an exception.
<flux>
(otherwise it fails, so that will complain about an incomplete match)
<Yoric[DT]>
(i.e. fails)
<Gionne>
how can i avoid that? --> how can i add the [] case?
<Gionne>
(sorry for my newbieness)
<bluestorm>
are you sure getting the first symbol of the production is what you want ?
<flux>
| Prod ([]) -> add code here
<Gionne>
uh fantastic
<Gionne>
bluestorm, yes, i need to check if it's the same of gram
<bluestorm>
(if your grammar is proper, there should be no empty production, shouldn't it ?)
<Gionne>
yes it should
marmotine has quit [Excess Flood]
marmotine has joined #ocaml
ygrek has joined #ocaml
code17 has quit [Remote closed the connection]
code17 has joined #ocaml
<gildor>
tsuyoshi: ping
<tsuyoshi>
yes?
LeCamarade_ has joined #ocaml
LeCamarade_ has quit [Client Quit]
<gildor>
sorry
<gildor>
about yesterday
<gildor>
with the IO and Thread
<gildor>
I have tested and it was worse
<gildor>
What is strange is that whenever I begin to use Thread
<gildor>
The program take longer
<gildor>
I think that using thread automatically trigger the Gc locking
<gildor>
which in turn is slow
<gildor>
(the Gc get slow)
<gildor>
but thanks for the tip
<tsuyoshi>
oh yeah I don't think threads could really make it any faster
<gildor>
... that is unfortunate, but true
<tsuyoshi>
I was just suggesting that, single-threaded, if you do your own buffering it ought to be faster
<gildor>
it doesn't in fact
<gildor>
own buffering vs caml buffering has the same speed
<tsuyoshi>
oh really? does it go slower?
<tsuyoshi>
oh
<tsuyoshi>
huh.. so what is the bottleneck?
<gildor>
I have tested both, and it really doesn't make a big diffrence
<gildor>
well, I don't know, still looking for it
<gildor>
I suspect that the Gc begin to take a long time when i get to 6M records
<gildor>
i.e. it needs to mark and sweep a lot of data at each major colleciton
* gildor
have lunch
<bluestorm>
gildor: maybe you should considering getting an "ocamlforge.org" domain name
<bluestorm>
(i'm not sure it's that important, but i often mistype "ocamlforge.org" instead of "forge.ocamlcore.org", and i might not be the only one)
Gionne has quit ["Leaving"]
Camarade_Tux has joined #ocaml
bluestorm has quit [Remote closed the connection]
bluestorm has joined #ocaml
LatentJam has joined #ocaml
<bluestorm>
Yoric[DT]: i was considering integrating your comprehension extension in batteries
<bluestorm>
but i think that, given the Batteries module uniformization, we could do something more general
<bluestorm>
the simple way would be to have only one comprehension on Enums, and derive the other from that
<bluestorm>
(in the spirit of your pa_for extension : we would give the module name somewhere and then call Module.enum)
<Yoric[DT]>
That was my idea.
<Yoric[DT]>
That was my idea, too.
<bluestorm>
ok :p
<Yoric[DT]>
Ok, formulation is wrong. I just meant "yes, I agree" :)
<bluestorm>
i'm not sure wether we should also keep the specific syntaxic forms ( eg. [| ... | ... ; ... |] )
<Yoric[DT]>
iirc, that's already more or less what happens in Batteries, though.
<Yoric[DT]>
iirc, that's already more or less what happens in comprehension, though.
<Yoric[DT]>
[| ... | List foo |]
<bluestorm>
hm
<Yoric[DT]>
Of course, now that we have Enum, we can implement this better.
<bluestorm>
is there comprehension code inside batteries already ?
<Yoric[DT]>
[| ... | bar <- List foo |]
<Yoric[DT]>
No, that was just a typo.
<bluestorm>
we could even choose different modules for input and output
<Yoric[DT]>
So you would write something along the lines of List { x | x <- Array foo } or Array { x | x <- Array foo }, etc. ?
<bluestorm>
exactly
<Yoric[DT]>
The idea is interesting but wouldn't that be confusing since there is already a syntax for lists, one for arrays, etc. in OCaml?
<bluestorm>
we could always define [ x | x <- li ] as sugar for List { x | x <- List li } , or anything more optimized (staying inside the List module) with the same behaviour
<Yoric[DT]>
Ok.
<Yoric[DT]>
Gottago, though.
<Yoric[DT]>
You have my blessing :)
* Yoric[DT]
will return in about 1h.
<Yoric[DT]>
Oh, I have 10 minutes.
<bluestorm>
( .. and i thought that "before tackling some ambitious goals like the infix constructors, i should work on easy thing like integration of Yoric's extension for comprehensions" )
<Yoric[DT]>
So are you planning to handle this?
<Yoric[DT]>
I mean, are you planning to start working on this?
<bluestorm>
i am
<Yoric[DT]>
Great.
<bluestorm>
it would be reasonable to focus on getting something working and passing the Alpha 3 requirements first
smimram has quit [Read error: 110 (Connection timed out)]
<gildor>
bluestorm: yes, an ocamlforge.org is possible
<bluestorm>
( i see a good rationale for (include B, C), same as the extended open, but this one seems possibly ambiguous and very ad-hoc )
<gildor>
will do it when I will renew ocamlcore.org
<bluestorm>
( perhaps a DEFINEd macro like MODS(...,...,...) would be more appropriate ? )
<Yoric[DT]>
bluestorm: well, the whole point of this extension is to be able to do
<Yoric[DT]>
[module List = List, Labels]
<Yoric[DT]>
[module IO = IO, BigEndian]
<Yoric[DT]>
and obtain a module [List] (resp. [IO]) where the original functions are replaced by the overlay
<bluestorm>
hm
<bluestorm>
even in user code, hm.
ofaurax has joined #ocaml
<Yoric[DT]>
gildor: we're starting to receive spam on our tracker.
<gildor>
that is unfortunate
<gildor>
you should only allow bug submission by authenticated user
seafood has quit []
<bluestorm>
i find the module List = List, Labels syntax a bit confusing, maybe we could find something highlighting the redefinition idea
<Yoric[DT]>
gildor: I have the impression that I can't change that post-facto.
<gildor>
Yoric[DT]: yes
<gildor>
I think it is not possible
<gildor>
(I have the same problem with Site admin BTS)
<Yoric[DT]>
:/
<gildor>
submit a bug to siteadmin
<gildor>
when I have time i will try to figure out how to solve this problem
<gildor>
(maybe direct access to the DB can solve that)
<Yoric[DT]>
submitted
<gildor>
thanks
<Yoric[DT]>
Well, thank you.
<bluestorm>
Yoric[DT]: would "module List = List with Labels, ExtList" be acceptable ?
<bluestorm>
(i'm still not sure it's future-proof enough, we might want to extend "module-with" in the future)
<Yoric[DT]>
Well, we already have a [open List with stuff], this may be confusing.
<Yoric[DT]>
But yes, that may be acceptable.
<Yoric[DT]>
But is that better than [module List = List, Labels]?
<bluestorm>
hm
<bluestorm>
what i find awkward with "List, Labels" is that if you don't know of the syntax extension, i have the impression it's difficult to guess what it means
<bluestorm>
the syntax should be, to a certain extent, auto-discoverable
<Yoric[DT]>
But is that better than [module List = List include Labels]?
<Yoric[DT]>
Sorry, I meant.
<Yoric[DT]>
What about [module List = List include Labels]?
<bluestorm>
why not
<bluestorm>
i think, if the redefinition of some values is the only intended use of the syntax, we should suggest that throught the syntax (but the reasonable limitation to reuse an ocaml keyword instead of adding one makes that difficult)
<bluestorm>
on the other hand, perhaps there is another use case for such a behaviour that i don't see yet
<bluestorm>
List include Labels is not bad
<Yoric[DT]>
Gottago
<Yoric[DT]>
cheers
<bluestorm>
actually i even considered List.(include Labels) in the pa-do spirit, but users will suppose it's equivalent to something like "open List in include Labels"
<bluestorm>
cheers :]
thelema has quit [Read error: 60 (Operation timed out)]
mishok13 has joined #ocaml
Gionne has joined #ocaml
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
mishok13 has quit [Connection timed out]
<rwmjones>
C is such a dumb-arsed language
* rwmjones
tries to find out why some struct isn't defined according to the compiler, when it plainly is defined in the header file
<rwmjones>
it's probably some macro in some unrelated header file
<rwmjones>
nah, it's coz there's two header files with the same name
<rwmjones>
stupid stupid stupid
<rwmjones>
whoever thought that textual inclusion was a good idea
Yoric[DT] has quit [Read error: 60 (Operation timed out)]
vixey has joined #ocaml
det has quit [Remote closed the connection]
<rwmjones>
crumbs, I do believe I have build a cross-compiler ...
threeve has joined #ocaml
* Camarade_Tux
praises rwmjones
det has joined #ocaml
<kattla>
yay for cross-compiler! :)
det has quit [Remote closed the connection]
thelema has joined #ocaml
det has joined #ocaml
det has quit [Remote closed the connection]
det has joined #ocaml
Camarade_Tux has quit ["Leaving"]
Camarade_Tux has joined #ocaml
pango has quit [Remote closed the connection]
filp has quit ["Bye"]
pango has joined #ocaml
<ertai>
hcarty: pong
jeddhaberstro has joined #ocaml
Yoric[DT] has joined #ocaml
det has quit [Remote closed the connection]
* Yoric[DT]
is back.
det has joined #ocaml
_zack has quit ["Leaving."]
<thelema>
hi Yoric[DT]
<Yoric[DT]>
I'll add the modified syntax for module overriding.
<thelema>
great.
<Yoric[DT]>
Ok, seems to work.
<Yoric[DT]>
committed
<Yoric[DT]>
and pushed
Camarade_Tux has quit ["Leaving"]
mfp has quit [Read error: 110 (Connection timed out)]
mfp has joined #ocaml
itewsh has joined #ocaml
jeddhaberstro has quit []
zerny has joined #ocaml
Camarade_Tux has joined #ocaml
<zerny>
Hi. I have a question w.r.t defining constants in OCaml. I would like to use a constant expression as TYPE_INT in a pattern where TYPE_INT is defined as say 2. Is there a way to do this in OCaml? I have had it working by using the c-preprocessor but I am not found of that solution as it breaks other things. For example, I can't get both the bitstring and cpp processors at the same time it seems.
<thelema>
zerny: by default ocaml "variables" (really just bindings) are constant.
<bluestorm>
zerny: the short answer is "no"
<thelema>
you do have to use a lower-case first letter on your identifiers.
<zerny>
thelema: but that does not work in match x with | TYPE_INT -> ...
<bluestorm>
| ti when ti = type_int -> ... would work
<bluestorm>
perhaps you could switch to a sum type instead of integers ?
<bluestorm>
(what are you trying to do ? do you have a code sample to show ?)
<thelema>
zerny: sounds like you might want a variant type.
<zerny>
bluestorm: parsing a binary file so I can't change the value
<bluestorm>
(i've been considering an extension for non-linear patterns à la Erlang for some time)
<bluestorm>
zerny: you're parsing a flag or something ?
<thelema>
he's using bitstring....
<thelema>
you can't pre-process your source with cpp in your makefile?
<zerny>
bluestorm: well, I am parsing a bytecode file for scheme, so I have a few types and 50 somewhat builtin operations that I need to switch on
<zerny>
thelema: well yes, but how do I get the bitstring preprocessor run on the same file?
<thelema>
make?
<zerny>
thelema: yes
<zerny>
but ocaml only seems to accept a single pp flag
<zerny>
?
<zerny>
thelema: oh, so you mean run cpp standalone and then compile the result with ocaml... sorry I did not think of that before
<thelema>
yes,
<zerny>
thelema: thanks for clearing the trees there
<bluestorm>
(there is a combine-preprocessor somewhere, developped for the withespace thing)
<zerny>
bluestorm: I am not sure I follow?
<bluestorm>
zerny: an utility was developped, "ppcompose", to allow you to chain different preprocessors
<zerny>
bluestorm: oh, thanks. I will have a look at it
<zerny>
another side question. Is there any support/extension for prescriptive types in OCaml?
<zerny>
I would really like to specify the exact bit layout for a few types that will be used by both C and OCaml in my current project.
<thelema>
sorry, only bitstring does anything like that in ocaml.
<zerny>
I admit that it is for some low-level optimizations and I should probably be writing the hole project in C, but I am really tired of C/C++ atm.
<zerny>
thelema: ok
<zerny>
I figured as I could not find anything on the topic. I do recall seeing some mention of it on LtU, but I have been unable to dig it up. Can't recall if it was OCaml either.
<zerny>
:(
<rwmjones>
zerny, what's the problem with using bitstring & cpp at the same time?
<thelema>
zerny: maybe the best way to do what you want in ocaml is with a pair of functions to pack/unpack your structs
<zerny>
rwmjones: well I guess nothing. I have it working now by using cpp to a tmp file and then building as usual from there.
<rwmjones>
yeah, I would expect that it should work
<rwmjones>
zerny, I sort of vaguely read the above, but the problem is you want to used fixed constants because those fixed constants have a meaning in another place (eg. in C code)?
<rwmjones>
zerny, if so, then we do a lot of that in the ocaml-libvirt code
<zerny>
rwmjones: well not exactly. I am using bitstring to parse a bytecode file and depending on the opcode I need to parse different amounts of arguments and so on. So I would have liked a pattern of the form: match bits with | { TYPE_MOVE : 8 ; .... } -> ...
<rwmjones>
ah I see, that's a different thing :-)
<rwmjones>
yeah, cpp is the way to go for that
<zerny>
it is just a bit more readable then the alternative :)
<zerny>
otherwise, bitstring rocks
<zerny>
and also that is not an issue with bitstring
<zerny>
oh, but one thing I found
<zerny>
if you do a { c : 8 : signed } pattern it gives an error
<zerny>
2 sec and I will find the error msg
<zerny>
I get and "Unbound value Bitstring.extract_char_signed" error
<zerny>
since no such function exists
<rwmjones>
zerny, yeah, certain functions aren't implemented (yet) ... I've only implemented the ones that I use myself and that other people have supplied as patches
<rwmjones>
extract_char_signed would be a function that is the same as extract_char_unsigned, but should do sign-extension on the result (eg. char 255 => int -1)
<zerny>
rwmjones: ok. well if I do a proper fix I will send it to you. currently I have a small workaround
<zerny>
rwmjones: yes, exactly
<zerny>
I will give it a stab as soon as I can
<zerny>
thelema, bluestorm, rwmjones: thanks for your help
itewsh has quit ["KTHXBYE"]
smimou_ has quit ["bli"]
* rwmjones
must have built ocaml 50 times today
Camarade_Tux has quit ["Leaving"]
* Yoric[DT]
sympathizes with rwmjones.
|Jedai| has joined #ocaml
<flux>
great, so rwmjones is the guy to turn for when having issues compiling ocaml ;)
alexyk has joined #ocaml
smimou has joined #ocaml
Koordin has joined #ocaml
<Koordin>
hi i have a weird problem ; when i try to uninstall tcl/tk8.4, apt-get uninstalls also ocaml ; and when tcl/tk8.4 is installed, this bring forth conflicts with tcl/tk8.5 and amsn does not work. so how can i do to remove tcl/tk8.4 without removing ocaml ?
<Koordin>
(ubuntu)
<thelema>
sounds like a packaging problem - one solution is to compile ocaml yourself
<Koordin>
thelema: it will not install tcl/tk8.4 if i compile it myself ?
<thelema>
yes. maybe another solution is to get amsn to use tcl/tk8.5, but I can't help with that.
<thelema>
(it sounds like amsn somehow ends up using 8.4
<thelema>
and fails at it.
<Koordin>
yes i have to tell amsn to use 8.5
Jedai has quit [Read error: 110 (Connection timed out)]
<Koordin>
thelema: this was the command to use : wish8.5 /usr/share/amsn/amsn
<Koordin>
thanks for helping me
Camarade_Tux has joined #ocaml
Koordin has quit [Remote closed the connection]
* rwmjones
posts the windows cross-compiler to caml-list ...
* Camarade_Tux
gets ready to test
* Camarade_Tux
is also everything but familiar with rpm builds so he hopes src2pkg will handle that
<rwmjones>
wth is src2pkg?
<Camarade_Tux>
a magic package maker, it can create tgz/rpm/deb packages from about any sources with minimal sweat but I think I'll do it by hand today :)
<Camarade_Tux>
I don't have time to test right now but I have the patch and report tonight or tomorrow morning ;p
jeddhaberstro has joined #ocaml
<hcarty>
ertai: I saw that there is a changelog for OCaml 3.10.3 in CVS - will this get the camlp4 + toplevel fixes?
<hcarty>
bluestorm: Regarding my pa-do + batteries comment a few days ago, I was wondering if there is an interest in making pa-do part of Batteries, either as a dependency or otherwise
<hcarty>
bluestorm: Yoric[DT] said that you are the one to talk with regarding camlp4 extensions in Batteries
tab has quit ["leaving"]
tab has joined #ocaml
love-pingoo has joined #ocaml
Gionne has quit ["Leaving"]
prime2 has joined #ocaml
Snark has quit ["Ex-Chat"]
marmotine has quit [Read error: 60 (Operation timed out)]
<ertai>
hcarty: hum I didn't heard of 3.10.3, but I will ask that
apples` has joined #ocaml
<rwmjones>
yay ..... extlib cross-compiles
itewsh has joined #ocaml
<Yoric[DT]>
rwmjones: yay :)
<Yoric[DT]>
Next step: Batteries Included :)
<olegfink>
does sexplib support utf-8?
<rwmjones>
Yoric[DT], I'm getting a feel for how to build cross-packages first
<thelema>
olegfink: in what way? dumping utf8 strings?
<rwmjones>
plus, I have to build virt-* ...
<olegfink>
in a ask-then-think process, I've just reached the stage at which I remembered ocaml source is latin-1
<thelema>
oleg; yup.
<thelema>
olegfink: although aside from how the characters are displayed, a UTF8 bytestream is also a valid latin-1 bytestream.
jlouis has joined #ocaml
mishok13 has joined #ocaml
<olegfink>
that's how haskell handles it in Prelude's Show, I was wondering if ocaml can do better and competely forgot its latin-1 nature.
pango has quit [Remote closed the connection]
<thelema>
Yoric[DT]: hmm... Reference to undefined global `Concurrent'
<thelema>
but trying to add it to extlib_threads.mllib gives me: Failure:
<thelema>
the file "src/core/extlib/concurrent.cmo" is included in more than one active open package
pango has joined #ocaml
<Yoric[DT]>
I'll take a look.
<palomer>
hrmph
<palomer>
how do I get the last modified date for a file?
<rwmjones>
yay#2 ... done ocaml-csv
<thelema>
palomer: in ocaml?
<rwmjones>
palomer, use Unix.stat
<palomer>
cool
marmotine has joined #ocaml
itewsh has quit ["KTHXBYE"]
<Yoric[DT]>
thelema: testing my fix, if it works correctly, I'll push.
<Yoric[DT]>
thelema: pushing
itewsh has joined #ocaml
<Yoric[DT]>
pushed
itewsh has quit [Remote closed the connection]
<Yoric[DT]>
And good night.
Yoric[DT] has quit ["Ex-Chat"]
mishok13 has quit [Read error: 110 (Connection timed out)]
marmotine has quit [Remote closed the connection]
<rwmjones>
yayyayyay ocaml-xml-light done ...
<palomer>
hrmph
<palomer>
cyclical dependency checking isn't as easy as it sounds
vbmithr has left #ocaml []
* palomer
drops it
<vixey>
yes it is
<vixey>
palomer, you're implementing a module system or compiler or something?