Associat0r has quit [Remote closed the connection]
marteo has joined #ocaml
slash_ has quit [Client Quit]
Lomono has joined #ocaml
Lomono has left #ocaml []
marteo has quit [Remote closed the connection]
Amorphous has quit [wolfe.freenode.net irc.freenode.net]
peddie has quit [wolfe.freenode.net irc.freenode.net]
M| has quit [wolfe.freenode.net irc.freenode.net]
acatout has quit [wolfe.freenode.net irc.freenode.net]
Amorphous has joined #ocaml
peddie has joined #ocaml
M| has joined #ocaml
acatout has joined #ocaml
tmaedaZ is now known as tmaeda
onigiri has quit []
thrasibule has joined #ocaml
blackdog_ has quit [Remote closed the connection]
thrasibule has quit [Read error: 110 (Connection timed out)]
ski_ has quit ["Lost terminal"]
ski_ has joined #ocaml
Mr_Awesome_ has joined #ocaml
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
f_[x] has joined #ocaml
Yoric[DT] has joined #ocaml
onigiri has joined #ocaml
peddie has quit [Read error: 110 (Connection timed out)]
_zack has joined #ocaml
bluestorm has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
onigiri has quit []
Yoric[DT] has joined #ocaml
Narrenschiff has joined #ocaml
Yoric[DT] has quit [Read error: 60 (Operation timed out)]
julm_ has joined #ocaml
julm has quit [Nick collision from services.]
julm_ is now known as julm
marteo has joined #ocaml
f_[x] has quit [Read error: 110 (Connection timed out)]
Camarade1Tux has joined #ocaml
Camarade_Tux has quit [Read error: 113 (No route to host)]
BiDOrD has joined #ocaml
Camarade1Tux has quit ["leaving"]
Camarade_Tux has joined #ocaml
Camarade_Tux has quit [Client Quit]
Camarade_Tux has joined #ocaml
LeCamarade|Away is now known as LeCamarade
julm_ has joined #ocaml
julm has quit [Nick collision from services.]
julm_ is now known as julm
f_[x] has joined #ocaml
tmaeda is now known as tmaedaZ
hkBst has joined #ocaml
<Camarade_Tux>
I'm now only looking for someone with sexplib on windows
<Camarade_Tux>
to compile a single 100-loc file
Narrenschiff has quit [Read error: 110 (Connection timed out)]
f_[x] has quit [Read error: 110 (Connection timed out)]
Yoric[DT] has joined #ocaml
Yoric[DT] has quit [Read error: 145 (Connection timed out)]
thrasibule has joined #ocaml
_andre has joined #ocaml
<bluestorm>
I suspect a bug in the Graphics module : when using wait_next_event [Poll; Key_pressed], it seems that keypresses are not removed from the queue
<bluestorm>
here is a sample code http://pastebin.be/20671 (it's not from me, but from the user reporting the bug)
<bluestorm>
I'm using godi 3.11.1 on GNU/Linux, and when running the app and briefly pressing "1", the terminal continues to print "1 0 1 0 1 0" forever, and doesn't respond to "2" anymore
<bluestorm>
do you observe the same behaviour ? is it a bug ? According to the Graphics documentation "Keypresses are queued, and dequeued one by one when the Key_pressed event is specified."
<bluestorm>
( here is a workaround i proposed to explictely dequeue the event : http://pastebin.be/20672 )
<bluestorm>
( and of course using key_pressed / read_key instead )
<flux>
what is Graphics.key? is it new in 3.11?
<flux>
anyway, I think he should use Graphics.read_key?
<flux>
oh, never mind, I can't compile it that way :)
<flux>
ah, ok, now I'm maybe figuring out how it works
<bluestorm>
Graphics.key is only the key field of the Graphics.status record
<flux>
it looks like the code should work
<bluestorm>
except it "doesn't" on my computer, wich I suspect is a bug
<bluestorm>
(that's what I thought too)
<bluestorm>
if someone were using 3.10, I'd be interested in a test : if the first code works correctly (prints "1" once, then "0"s again and eventually "2" when pressing the key), it means a bug was introduced in 3.11
<flux>
it failed in 3.10 too
<flux>
adding a superfluous .read_key () makes it work however
<bluestorm>
yes that's essentially the "ignore ..." trick I provided
<flux>
oh you did, I didn't notice the link
thrasibule has quit [Read error: 110 (Connection timed out)]
tmaedaZ is now known as tmaeda
julm has quit [Remote closed the connection]
Yoric[DT] has joined #ocaml
bluestorm has quit [Remote closed the connection]
_zack1 has joined #ocaml
f_[x] has joined #ocaml
_zack has quit [Read error: 113 (No route to host)]
bombshelter13_ has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
BiDOrD has quit [Remote closed the connection]
bluestorm has joined #ocaml
Yoric_ has joined #ocaml
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
Lomono has joined #ocaml
Lomono has left #ocaml []
bjorkintosh has joined #ocaml
<bjorkintosh>
how fast is ocaml?
<bjorkintosh>
compiled code and what not?
<flux>
it's decent
<flux>
fast enough so you don't need to worry about it
<flux>
you may look into programming language shootout benchmarks. don't look just at the numbers, take a peek at the source too.
<flux>
(I'm referring to the one at shootout.alioth.debian.org)
<orbitz>
it differs dependign on what yo uare solving too
<xevz>
flux: O'Caml is fairly fast when looking at the numbers too... :)
<flux>
xevz, yes. actually the point I was trying to make that often when something else is faster, it's wayy more ugly too ;)
<thelema>
it's fast, but the compiler produces code that does what you tell it to, not what you want, so don't expect too many magic optimizations
<xevz>
flux: Ah. :)
<flux>
but technically ocaml compiler isn't optimizing beyond the basic optimizations. it's just has a pretty decent code generator.
<thelema>
it's fast because the basic operations are fast, not because the compiler rewrites your code into a faster version.
<Yoric_>
bjorkintosh: which brings us back to the question: what do you intend to to with OCaml?
Yoric_ is now known as Yoric
f_[x] has quit [Read error: 110 (Connection timed out)]
<flux>
thelema, sync ;)
<bjorkintosh>
lots, Yoric.
<orbitz>
bjorkintosh: what are yo ucurrently writing in?
<thelema>
bjorkintosh: welcome
<bjorkintosh>
orbitz, english, at the moment :)
<thelema>
bjorkintosh: computer language?
<flux>
bjorkintosh, if you're thinking if you can use ocaml for task Z, it is quite likely you can. I use it for almost everything.
<Yoric>
Btw, Batteries can now perform simple Http downloads.
ski_ has quit ["Lost terminal"]
<Yoric>
(well, push, get and post)
<flux>
yoric, which library does it use to accomplish that?
<orbitz>
Yoric: worst case one could pulla Twisted approach where thread communication si worked into an event loop so anything that hasn't been worked into event loop yet can be shot off in a thread and communicate back
<orbitz>
Yoric: OPA?
<Yoric>
The language I'm currently developing.
<orbitz>
okay, so kidn of like Erlang in that sense?
<Yoric>
I'm not familiar with an event loop in Erlang. Do you mean the mailbox or just something I don't know?
<Yoric>
(I'm not proficient in Erlang, far from it)
<bluestorm>
thelema: have you considered Stefano's suggestion to make aaa a strict subset of batteries, that would be extended by optional dependencies ?
<orbitz>
Yoric: I mean the mail box
<Yoric>
thelema: bluestorm: that would be quite nice.
ched_ has joined #ocaml
<Yoric>
orbitz: somewhat.
<bluestorm>
agreed
<Yoric>
Just typed.
<orbitz>
Yoric: that's what's msising from Erlang IMO anyways :)
<thelema>
bluestorm: yes, I would be happy to have aaa as core, but I don't like optional dependencies, as you get many possible batteries - the point of standardization is to have fewer configurations.
Ched has quit [Read error: 60 (Operation timed out)]
<Yoric>
orbitz: Well, you'll be welcome to try OPA as soon as there's a public version available :)
<orbitz>
Yoric: any code samples of it around?
<bjorkintosh>
Yoric, have you read appel's book on compiler implementation in ml?
<Camarade_Tux>
I think ocamlbuild just fails on cygwin
* Camarade_Tux
wonders why it didn't show the dynlink error the first time :p
<Yoric>
bjorkintosh: I have quickly browsed through it but no, I haven't read it.
<Yoric>
orbitz: nothing public so far.
<Yoric>
The syntax is probably going to change a few times before the first release.
<orbitz>
Yoric: sweet, keep me up to date
<Yoric>
Willdo :)
<orbitz>
was the issue of how much it stinks to do math wtih Int64 and Num library ever get resolevd?
<hcarty>
thelema: Will any aaa-dependent code also work with Batteries?
<Yoric>
How does it stink?
<thelema>
hcarty: that's the plan.
<orbitz>
Yoric: meeting, brb
<thelema>
It's important to be able to upgrade to "car batteries" if aaa isn't enough.
<hcarty>
Llama batteries to Camel batteries.
<thelema>
remote control batteries -> automotive batteries (maybe deep cycle marine batteries)
<Yoric>
hcarty: :)
<orbitz>
Yoric: i thought there was a summer of code project so you coudl take somethign liek Uint64 and have it take over the basic arithmetic functions for a bit of code
<Yoric>
Yes.
<Yoric>
That's done.
<orbitz>
wheeee
<Yoric>
It's called [pa_do].
<Yoric>
Eventually, we'll probably include it in Car Batteries.
<orbitz>
not part of standard?
<Yoric>
Well, if I understand correctly, thelema is currently renaming current Batteries into "Car Batteries", to differentiate it from "AAA Batteries".
_zack1 has quit ["Leaving."]
<Camarade_Tux>
I remember what I have against camlp4 on windows, it always seems to fail with "reference to undefine global `Dynlink'"
<Yoric>
Well, it also does under Linux.
<Camarade_Tux>
true I've also had it on linux but I'm too scared to try touching anything :D
<Camarade_Tux>
on windows that is
<Camarade_Tux>
is flexlink used for bytecode dynlink too?
<hcarty>
I think the current "Car" Batteries should retain the title "Batteries"
<hcarty>
Without the extra goodies (syntax in particular), the library loses much of its flair.
<hcarty>
orbitz: pa_do is a wonderful tool, definitely worth checking out.
<orbitz>
hcarty: i plan on it!
<orbitz>
I've got soem stuff that i need to do with it
<Camarade_Tux>
right now I'm trying to compile my package manager which should make things easier on windows
<Camarade_Tux>
but I have to say windows traumatized me
<Yoric>
Camarade_Tux: a GODI for Windows?
<Camarade_Tux>
Yoric: no, it's a binary package manager, not a source one
<Yoric>
ok
<Camarade_Tux>
ocaml is not the only target but it's definitely one of the most important, that's another reason it's not source
julm has joined #ocaml
<orbitz>
is there any documentation on guaranteed range of numeric types or a function to get the maximum value?
<Camarade_Tux>
you have max_int for instance (in Pervasives)
Yoric has quit [Read error: 145 (Connection timed out)]
<hcarty>
If I continue to develop it and/or someone else wants to take part then I'll move it over to the forge.
<hcarty>
You can't clone from that repo as I don't have the permissions setup properly yet. But you can download snapshots and browse the source.
<hcarty>
And suggestions for a better name are welcome.
willb has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
willb has joined #ocaml
LeCamarade is now known as LeCamarade|Away
_zack has joined #ocaml
blackdog_ has joined #ocaml
Yoric[DT] has joined #ocaml
<thelema>
hcarty: the reason for "car" batteries is so that just plain "batteries" can refer to the project, and each of the two options has an easy name.
<thelema>
I worry that many people will only want to adopt aaa batteries, but for those who can use car batteries, great.
<thelema>
if you want easier compilation for users of your code, requiring car batteries isn't the best idea at the moment.
<hcarty>
thelema: That's my concern as well (no one uses the full Batteries). What are the issues with Batteries that aaa addresses?
onigiri has joined #ocaml
<thelema>
mainly installability, but also car batteries is pretty much a magic box, with little transparency on how it works.
<thelema>
aaa should require little commitment to the batteries system in order to use it.
<hcarty>
"little commitment" - such as?
<orbitz>
like no event loop one has to design their application around
<thelema>
yes, the event loop wouldn't go into aaa
<orbitz>
thelema: i would imagine no socket stuff either?
<hcarty>
orbitz: I don't know that a library should be based on what _might_ happen in the future for another library...
<thelema>
but I'm thinking of things like how car batteries commits to camlp4. I'm considering pulling the IO system from aaa
<hcarty>
thelema: So more extlib than batteries?
<thelema>
extlib plus some external libraries
<thelema>
and a lot more builtins
<thelema>
aaa will still have camomile for unicode
<thelema>
but as portable code as possible
<hcarty>
Does the IO system bring in external dependencies?
onigiri_ has joined #ocaml
<hcarty>
Are there unportable/platform-dependent pieces of Batteries now?
<thelema>
no, it just requires some commitment to the batteries way.
<thelema>
sexplib is not easy to get working on windows
<bluestorm>
is the reason to scrap camlp4 the need for a simple build system ?
<orbitz>
from my own limited ocaml expereicnes it would be nice to have a more fleshed out stdlib, one that will work anywhere, with simpel stuff in it
<bluestorm>
I mean, camlp4+ocamlfind is relatively painless thse days
<hcarty>
If you remove the IO system, it seems like it will be quite difficult to maintain upwards compatibility with full Batteries.
<thelema>
hcarty: true, I'm only considering it.
<hcarty>
Yes, the myocamlbuild.ml that comes with Batteries does most of the work for you, if not all of it.
<thelema>
bluestorm: at least partly.
<thelema>
myocamlbuild is not a good solution.
<hcarty>
thelema: Why is that?
* thelema
wants to be able to do [ocamlfind ocamlc -package aaa foo.ml] to compile a simple project with batteries
<hcarty>
orbitz: That is/was the goal of extlib.
<bluestorm>
is ocamlfind ocamlc -package aaa -syntax camlp4o foo.ml so much difficult ?
<thelema>
hcarty: it doesn't extend well - myocamlbuild doesn't compose between requirements
<bluestorm>
hcarty: except getting some code included in Extlib is harder than hell
<hcarty>
Could the Batteries wrappers provide an automatic use of a myocamlbuild.ml, without needing to bring it in externally?
<bluestorm>
hcarty: thelema wants a "transparent" build env.
<thelema>
bluestorm: it's much more than that to use all the extensions in batteries, plus cluttering the ocamlfind namespace with all the subprojects
<hcarty>
bluestorm: This is true. But for getting started, or a simple project, what's there is often "enough"
<bluestorm>
much more than that ?
<hcarty>
I honestly think that batteries-specific tools for a transparent build environment would be suitable.
<bluestorm>
hcarty: apparently thelema doesn't :]
<hcarty>
bluestorm: Fair enough :-)
<thelema>
what if you want batteries plus some other library with its own myocamlbuild
<thelema>
merging myocamlbuild files is ... not easy
<bluestorm>
hm
<thelema>
the first time, at least
<hcarty>
Well, the Batteries myocamlbuild.ml is pretty generic overall.
<thelema>
for example, aurochs_lib has its own myocamlbuild, so it's difficult to use with batteries
<hcarty>
There are certainly Batteries-specific pieces in there, but a lot of it is making ocamlfind and camlp4 support easier.
<bluestorm>
add your new module(s), extend the dispatch statement, and that's it
<thelema>
yes, and it needs to be broken into separate pieces, with ocamlbuild accessing a more central library of myocamlbuild rulefiles
<bluestorm>
I think it is possible with 3.11, wich has native dynlinking
<hcarty>
thelema: That is certainly true. Properly modular myocamlbuild.ml support and a related ocamlfind support would be wonderful.
<hcarty>
s/a related/related/
* thelema
is all for a /usr/local/lib/myocamlbuild.d/
sramsay has joined #ocaml
<hcarty>
I just don't want Batteries to lose appeal before it ever gets started because there are multiple independently operated, divergent versions. The OCaml stdlib++ landscape is already rather difficult to take in :-)
<thelema>
I don't want it to lose appeal because noone can get it installed to use it.
<thelema>
two versions, with clear "you need this for the car version" messages allows for people to have the code, be able to use it and want more
<thelema>
and have a reason to put in the extra effort to get more features.
onigiri has quit [Read error: 110 (Connection timed out)]
onigiri_ is now known as onigiri
<thelema>
kinda a teaser version, that's easy to get working.
<hcarty>
Would it be enough to make sexplib, etc. optional compile-time dependencies for Batteries?
<hcarty>
If that's the major hurdle for Windows.
<hcarty>
Of course, I haven't used the sexplib support in Batteries, or how it is used throughout the code base, so I don't know if that is even remotely reasonable to attempt.
<thelema>
that's the major hurdle for some people - some people won't use camlp4
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
<thelema>
I don't want the combinatorial explosion of versions having lots of different dependencies - just two versions - lite and full - seems sufficient
<hcarty>
The camlp4 requirement can already be avoided, correct?
<hcarty>
camlp4 is only enabled by default if you use the Batteries myocamlbuild.ml and use_batteries
<thelema>
only through aaa batteries
<hcarty>
If you juse use pkg_batteries (or ocamlfind ocamlc -package batteries ...) no camlp4 is involved.
<thelema>
it's difficult in the current batteries to use it w/o camlp4 because its build system auto-includes
<thelema>
hmm, maybe.
f_[x] has joined #ocaml
<hcarty>
"let f x = 1 |> print_int" in foo.ml, compiled with "ocamlfind ocamlopt -package batteries -linkpkg foo.ml" fails because none of the camlp4 is used in this case.
<thelema>
but then you have to rewrite all your source files to say [use Batteries] at the top
<hcarty>
But you would have to do that with aaa or any other non-camlp4-Batteries code.
<thelema>
there's no camlp4 that would apply to that. |> is a function.
* thelema
thinks having [open Batteries] should be required
<hcarty>
It does apply, because with camlp4 the "open Batteries;; open Standard;;" is implicit.
<hcarty>
Or, with the full Batteries camlp4 suite.
* thelema
included Standard inside Batteries for aaa, so only [open Batteries] is needed
<hcarty>
If I add "open Batteries open Standard" to the start of foo.ml then it compiles without issue, because the library is linked but no camlp4 is applied to foo.ml
<hcarty>
That could be changed in Batteries as well.
<hcarty>
(including Standard in Batteries)
<hcarty>
That doesn't alleviate the Batteries-compile-time requirement of sexplib, etc. But I would think that it is easier to change that in the Batteries code base than it is to maintain a separate branch of code.
<hcarty>
It is already up to the author of Batteries-using code if they want any camlp4 use in their project.
<hcarty>
They may not be able to (currently) avoid linking with camlp4.cma, but there is no need for preprocessing.
<hcarty>
bluestorm: On a different front, that is a very nicely put-together myocamlbuild.ml in macaque
marteo has quit [Read error: 60 (Operation timed out)]
<bluestorm>
hcarty: the idea is certainly not mine, I reused the structure of Batteries myocamlbuild, wich I suppose is mostly from Yoric
slash_ has joined #ocaml
_zack has quit ["Leaving."]
marteo has joined #ocaml
Yoric[DT] has joined #ocaml
onigiri has quit []
<hcarty>
bluestorm: Fair point. I think Yoric[DT] is behind most, if not all, of the Batteries myocamlbuild.
Alpounet has joined #ocaml
ulfdoz has joined #ocaml
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
rpg has joined #ocaml
rpg is now known as Guest25110
<Guest25110>
Hey when i run ocaml in xterm and i press backspace it shows a ^H instead of erasing. How do i go about fixing that ?
<bluestorm>
Guest25110: rlwrap
<bluestorm>
install rlwrap, "rlwrap ocaml" for launching the toplevel
<Guest25110>
theres no special xterm feature ?
<bluestorm>
probably not
<Guest25110>
cool
<Guest25110>
rlwrap sounds good
<Guest25110>
thank you
Guest25110 has quit [Client Quit]
<sgnb>
ledit is dying...
<Camarade_Tux>
orbitz: if you find ocaml ints small, you can use the Int64 module (/me with a 3-hour lag :) )
Yoric[DT] has joined #ocaml
<Camarade_Tux>
sgnb: ledit-2.01 should be available in godi but only 1.16 is and in fact the last one of the 1.xx version is 1.17 with some added features
<Camarade_Tux>
I think it wouldn't take a lot to get a much better ledit (needs some config)
<Camarade_Tux>
also, aaa would have another use: possibly smaller binaries
marteo has quit [Read error: 110 (Connection timed out)]
marteo has joined #ocaml
<Yoric[DT]>
I wonder if AAA is the right path towards smaller binaries.
<Yoric[DT]>
Perhaps compilation options would be more applicable.
<Yoric[DT]>
On the other hand, AAA may pave the way for this.
<Camarade_Tux>
I only saw the smaller binaries as a side-effect, not a main feature ;)
<Yoric[DT]>
sure
r0bby has quit [Connection timed out]
* Yoric[DT]
looks at Grand Central Dispatch.
* Yoric[DT]
would love to have something like this in OCaml.
<flux>
does batteries still have one big module?
<flux>
also, is IO in batt. so big, if one is considering not including it in aaa?
<flux>
(btw, lots of text in the last 5 hours..)
<Yoric[DT]>
Batteries still has one big module due to namespacing issues.
<flux>
and that causes the size problems?
<Yoric[DT]>
Only part of it.
<Yoric[DT]>
Only part of them.
<flux>
..which had potential to be solved by a more advanced compiler..
<Yoric[DT]>
All the Ext* modules (i.e. more than 3/4 of the code) cause the exact same problem.
<Yoric[DT]>
Mmmmhh....
<Yoric[DT]>
Although possibly less strongly.
<flux>
a very smart linker could do it
<flux>
it would need the dependency information on all symbols to work, though..
<Camarade_Tux>
I've read the ars technica article on snow something (well, parts of it) and grand central sure seems quite nice :)
<Yoric[DT]>
Actually, since we don't have a real hierarchy anymore, we could rework the package and some of the camlp4 macros to split transparently.
<hcarty>
Yoric[DT]: Allowing for multiple ocamlfind targets? Or are you thinking of something different?
<Yoric[DT]>
I'm writing something for the mailing-list right now.
<hcarty>
Sounds good
f_[x] has quit [Read error: 145 (Connection timed out)]
Yoric[DT] has quit [Read error: 104 (Connection reset by peer)]
Yoric[DT] has joined #ocaml
jimmyb2187 has left #ocaml []
<Camarade_Tux>
bah, I can't get my code to compile on windows using ocamlbuild, it's failing because of camlp4 and "undefined reference to dynlink" even though I have pkg_dynlink in _tags or -package dynlink when using ocamlfind (ocamldep)
<Camarade_Tux>
I'm slowly rediscovering all the little niceties of compiling on windows :)
<Alpounet>
windows is a shame for "serious" programming.
<Camarade_Tux>
code on some unix/linux, compile on windows ><
<Camarade_Tux>
or just cross-compile
<Alpounet>
yeah...
<Alpounet>
damned, gmail's down
<Camarade_Tux>
yeah, noticed that =/
<Camarade_Tux>
just in case you're wondering, gmail is down worlwide (3 confirmations in France, one in Germany, one in Canada, one in the US [directly connected to a backbone])
<Alpounet>
count an additional one in France
bombshelter13_ has quit [Remote closed the connection]
_andre has quit ["leaving"]
<Camarade_Tux>
the first gmail outage I saw made me realize I definitely to back up my mails (I have about 3GB, mostly text!)
<Alpounet>
nearly the same for me !
<Alpounet>
and I should backup too...
<Camarade_Tux>
but I think imap/pop on gmail only works for mails you sent/received after you enable imap/pop
<Camarade_Tux>
which means that the first mail you received probably wouldn't be available
julm_ has joined #ocaml
Alpounet has quit [Read error: 60 (Operation timed out)]
Alpounet has joined #ocaml
<Alpounet>
back sorry
ulfdoz has quit [Read error: 145 (Connection timed out)]
<hcarty>
Camarade_Tux: They should all be available by IMAP at least. I can view my earliest (pre-IMAP) messages that way.
<hcarty>
I don't do it as often as I should, but I've been using offlineimap to backup my Gmail account.
<Camarade_Tux>
hcarty: ok, good news :)
<Camarade_Tux>
now I need something that can get about 2.5GB of text reliably, if only I could compress it, it'd be like 100MB
<hcarty>
Camarade_Tux: I definitely recommend giving offlineimap a try. If you just pull the "All Mail" IMAP folder it will backup all of your mail. You won't have the tags, but the messages will be there.
<Alpounet>
yeah
<hcarty>
Or you can pull everything, get some possible duplicates, and maintain tags through the IMAP folders.
<Alpounet>
searching them is enough, in that case.
<Camarade_Tux>
as long as I can search through my mails, it's good :)
<hcarty>
The IMAP interface seems to be working for Gmail. I can connect with mutt.
<Alpounet>
haha, gmail's back here !
<hcarty>
And, thankfully, if you ask for a server-side search it's still very fast.
<hcarty>
Nothing here yet for the web interface.
<Alpounet>
hmm
<Alpounet>
it went as quick as it came
<Camarade_Tux>
hehe, not available anymore :P
<Camarade_Tux>
hcarty: gmail's search is less powerful than google's however
<hcarty>
If the IMAP service is up then it shouldn't, hopefully, lose any incoming mail.
<Camarade_Tux>
for instance, it searches for accents literraly
<hcarty>
Camarade_Tux: How so? (not disagreeing - curious)
<hcarty>
Ah
<hcarty>
Interesting
<Camarade_Tux>
that's one example but I think there are others, basically it doesn't do that approximative search google.com does
<hcarty>
Interesting. I wonder if sup does that.
<hcarty>
Camarade_Tux: Regarding the Windows problem - is dynlink.cma added too late in the command line? Maybe it needs to be added to camlp4's META file.
<Camarade_Tux>
argh, it reminds me of a patricia tree I wrote some time ago and I tested it on a version of the bible which was about 5MB. If I have 2.5GB of mails, it means I have roughly 500 bibles and wrote more than 50 bibles...
<Camarade_Tux>
hcarty: order occured to me but I didn't try changing camlp4's META, gonna check/try
<Camarade_Tux>
actually I've been building the command-line by hand, it's... painful :P
<bluestorm>
heh
<bluestorm>
when starting OCaml, I've coded on Windows Millenium, compiling by command line (cmd.exe not the current fluffly stuff) for months
<Camarade_Tux>
ouch, I wonder how you're still alive ;)
r0bby has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
julm_ has quit [Remote closed the connection]
<Camarade_Tux>
camlp4's META doesn't seem to mention dynlink but I'm not sure I can fix that today, I've tried to add dynlink to a few places in camlp4's META but that doesn't seem to solve it
* Camarade_Tux
goes back building his command-line by hand
julm has joined #ocaml
<hcarty>
Camarade_Tux: Adding the line 'requires += "dynlink"' should do it
<hcarty>
Or something similar to that
<hcarty>
The META file for camlp4 that ships with GODI is massive.
<Camarade_Tux>
hcarty: that's basically what I tried
<hcarty>
Camarade_Tux: Best of luck then
<hcarty>
I wish for your speedy recovery :-)
<Camarade_Tux>
that's maybe the reason I don't have to require/link/use/pkg dynlink on windows
<Camarade_Tux>
:)
<Camarade_Tux>
s/windows/linux/
<Alpounet>
gmail seems to be definitely back./
r0bby has quit [Connection reset by peer]
<Camarade_Tux>
Alpounet: yep \o/
julm has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
Camarade_Tux: I can email you the GODI camlp4 META file if it would help.
<Camarade_Tux>
hcarty: no, it's ok, I have access to it thanks to ssh goodness :)
<Camarade_Tux>
woot, I managed to compile my app :)
<Alpounet>
gg :-p
<Camarade_Tux>
the command-line is "only" 480 chars long (no ocamlfind), gonna try ocamlfind
<Camarade_Tux>
Alpounet: hehe :P
<Camarade_Tux>
I seriously hope I won't have to do that ever again (and that program didn't need separate compilation)
<Camarade_Tux>
I'm trying to compile with: [ ocamlfind opt -syntax camlp4o -package 'dynlink, camlp4, unix, pcre, sexplib, sexplib.syntax' -linkpkg types.ml yaxmpkg.ml ] but I stil get the "same undefined reference to dynlink" error
<Camarade_Tux>
unless someone has an idea, I'll call this a night ;)
<bluestorm>
hm
<bluestorm>
'camlp4o dynlink.cma' ?
* sgnb
doubts it works
<sgnb>
sanest thing would be to fix camlp4's META, IHMO
<Camarade_Tux>
no matter the os, I can never get the ocamlfind camlp4 arguments right
<Camarade_Tux>
sgnb: sure but I can't fix it before knowing how :P
<sgnb>
adding it to requires is not enough?
<Camarade_Tux>
*seems* not
<Camarade_Tux>
bluestorm: same problem (you meant to use: -syntax 'camlp4o dynlink.cma', right?)
<bluestorm>
yes
<bluestorm>
or possibly -syntax camlp4o -pp 'camlp4o dynlink.cma'
<bluestorm>
I meant that possibly the linking issue was a camlp4-time issue instead of a compile-time one
<bluestorm>
(when camlp4 get invoked with plugins, it could ask for dynlink somehow in that crazy 3.11 setting I understand nothing of)
<sgnb>
when you give *.cma argument to camlp4*, it will load it dynamically
<sgnb>
it seems pretty obvious to me that 'camlp4o dynlink.cma' cannot work (but please prove me wrong)
<Camarade_Tux>
bluestorm: -pp ' .........' did the trick, and no need for -syntax camlp4o in such case, but I'd rather keep it anyway
<Camarade_Tux>
sgnb: yeah, camp4o dynlink.cma wasn't working as wished but it was worth the try :p
<sgnb>
Camarade_Tux: your problem is solved?
<Camarade_Tux>
sgnb: I can compile what I want to but I'd still enjoy a simpler compile command (it's still pretty long)
<sgnb>
could you send/paste a minimal example?
r0bby has joined #ocaml
<Camarade_Tux>
I'm currently minimizing it ;)
julm has joined #ocaml
<Camarade_Tux>
think I won't get it smaller without solving the underlying issue