<Kerris4>
"OCaml Meeting 2009 has been announced. It will be held on February 4, 2009, in Grenoble, France."
<Yoric[DT]>
Yep.
jknick has quit ["leaving"]
rwmjones_ has quit [Remote closed the connection]
thelema has quit [Read error: 110 (Connection timed out)]
sporkmonger has quit []
ygrek has joined #ocaml
threeve has joined #ocaml
foo__ has joined #ocaml
sporkmonger has joined #ocaml
munga has joined #ocaml
<foo__>
I am getting frustrated with tuareg mode. Is there a workaround not to kill and launch interactive mode every time I want to eval buffer? If I only eval the buffer things start to be a little wild, sometimes functions are in old versions etc. Is there something like load-file from any other emacs mode?
<flux>
well, I imagine it would be relatively easy to write a function that kills the eval buffer, creates a new one and the evaluates the current buffer?
<foo__>
I am trying to do it right now but I don't know elisp good enough
<foo__>
but beacuse there isn't one and no one cares you must have some other way to work with interactive mode
<_zack>
Yoric[DT]: I was going to add --with-godi, but I see you have also fiddled with configure.ac
<_zack>
do you need something for this release?
<Yoric[DT]>
_zack: yeah, I'd like someone to strangle the authors of autotools.
<_zack>
common feeling :)
<_zack>
anyhow, note that configure.ac does not end up in released tarball
<Yoric[DT]>
I've been on this since yesterday.
<Yoric[DT]>
It does not?
<_zack>
no, because you don't want the user to have installed autoconf
<_zack>
you, as the author, only release ./configure
<Yoric[DT]>
That, for sure.
<_zack>
can I implement --with-godi? then in the release note you can just tell "if you want to use GODI, just pass that flag to ./configure"
foo__ has quit ["Ex-Chat"]
<Yoric[DT]>
But there's no harm in having configure.ac, too.
<Yoric[DT]>
Is there?
<det>
foo__, Have you tried Eclipse + OcaIDE ?
<Yoric[DT]>
Well, if you insist :)
<_zack>
well, usually it is not there, but I agree that there is no harm
<_zack>
Yoric[DT]: :)
* _zack
dig into configure.ac
<Yoric[DT]>
Does anyone know how I can do a simple replacement with sed?
<flux>
sed 's/simple/replacement/g'
<flux>
?
<Yoric[DT]>
That is replacement without regular expressions.
<Yoric[DT]>
In that case, I need
<flux>
simple: quote the data ;)
<Yoric[DT]>
sed 's/A/$(B)/g'
<Yoric[DT]>
where B is given by the user and may contain arbitrary characters.
<flux>
I don't know of such way
<flux>
perl maybe?
<Yoric[DT]>
I'd write this with OCaml Batteries Included, but I can't do that here.
<flux>
plain ocaml then?
<Yoric[DT]>
Yep.
<_zack>
Yoric[DT]: done, brief list of changes
<_zack>
- if --with-godi is passed you get a @HAS_GODI@ variable set to yes in Makefile.in
<_zack>
(or wherever is subject to AC_CONFIG_FILES substitution
<_zack>
I've re-enabled --with-docroot (I need it into Debian), if passed it overrides --with-godi
<_zack>
I'm not sure if the value of DEFAULT_DOCDIR in the GODI case is the correct one though
<_zack>
you have to check that
<Yoric[DT]>
It seems correct.
<_zack>
ok, I'm just scared by the fact that it is a relative path
<_zack>
Yoric[DT]: if you need something else just shout, I'm sorry to have you waste time dueto an implementative choice of mine :) (good old damned autoconf)
<Yoric[DT]>
Well, sorry to have us waste time due to autoconf.
* Yoric[DT]
starts to believe in dumping autoconf before going to version 2.
<_zack>
as you wish, to me is not that a waste of time because in the end I've learned to tame the beast, but if it is for all you other I understand the choice
<Yoric[DT]>
Well, we have lots of time until version 2.
thelema has joined #ocaml
snhmib has joined #ocaml
Smerdyakov has joined #ocaml
<Yoric[DT]>
_zack: as you may see, I've reverted generation of config.ml to the Makefile.
<Yoric[DT]>
That was necessary to get everything expanded properly.
<Yoric[DT]>
(and it's in accordance to the documentation of autotools)
<_zack>
what was not expanded?
<_zack>
(and yes, I didn't notice that, sorry)
<_zack>
uhm, my Makefile.in is not aware of the fact that you are generating config.ml using it :)
<thelema>
Yoric[DT]: any chance of making [make instdoc] -> [make install-doc]
<Yoric[DT]>
Well, mine is.
<Yoric[DT]>
thelema: I can do that.
<_zack>
Yoric[DT]: no push?
<Yoric[DT]>
Not yet.
<_zack>
ah, then the question stands: what wasn't expanded?
<Yoric[DT]>
thelema: done
<Yoric[DT]>
_zack: DOCDIR
<_zack>
it should be expanded
<Yoric[DT]>
It ended up with 'let documentation_root = "${prefix}/... "'
<Yoric[DT]>
Well, not according to the documentation of autotools.
<_zack>
ah, I fear a clash with a built-in variable
<thelema>
Yoric[DT]: merci
<Yoric[DT]>
thelema: un plaisir
<_zack>
just rename DOCDIR to DOCROOT or something
<Yoric[DT]>
_zack: According to them, this kind of stuff should be generated by the Makefile.
<_zack>
anyhow, here I see no ${prefix} in documentation_root
<_zack>
strange
<_zack>
anyhow, the DOCDIR variable I defined was not meant to be the legacy one, but our own variable, and it can be definetly expanded at configure time
<Yoric[DT]>
That was when I changed DEFAULT_DOCDIR to comply with the the autotools's variable.
<Yoric[DT]>
(docdir)
<Yoric[DT]>
Oh, that's legacy?
<_zack>
I don't think so, but if you go for DOCROOT it will work for sure
<Yoric[DT]>
Well, too late, I guess.
<_zack>
ok...
<Yoric[DT]>
Do you think I should revert?
<_zack>
I don't know the current state of your configure.ac
<_zack>
but anyhow just find something which work
<_zack>
we will clean up after alpha2
<_zack>
just beware that I've pushed the change of --with-godi
<_zack>
(as announced above)
<_zack>
FWIW, in the version I've pushed, DOCDIR is expanded properly without any ${prefix}, at least not here
<Yoric[DT]>
Ok, I'm starting to get confused.
<_zack>
OK, RSET, I've a proposal
<Yoric[DT]>
Yes ?
<_zack>
I can just commit ./configure to git (and remote its entry from .gitignore)
<_zack>
this way you need not to invoke autoconf in general, and just use the last ./configure I've generated
<Yoric[DT]>
Let me think a second.
<_zack>
rationale: I know the ./configure I've does work
<Yoric[DT]>
Well, yes, but does it work with GODI?
<Yoric[DT]>
I've just realized that my latest GODI package shouldn't work.
<_zack>
you just have to tell me which values need to end up in config.ml/Makefile
<_zack>
actually, you can check by yourself, just running ./configure
<_zack>
well, ./configure --with-godi
<Yoric[DT]>
Ok, but that needs for me to find out more about GODI configuration.
<Yoric[DT]>
Ok, but that needs for me to find out more about GODI packaging, that is.
<_zack>
ah, that I cannot save it from :)
<_zack>
s/it/you/
<Yoric[DT]>
Until now, I was working by applying a patch to Makefile.
<_zack>
ah, urgh, /me didn't know that
<Yoric[DT]>
If everything has moved to configure.ac, I need to find out how to pass options to ./configure.
<_zack>
or, you can tell me what the patch did, and I'll figure out how to mimic it from configure.ac
<_zack>
(just to save some headaches, if possible)
<Yoric[DT]>
Well, I'm starting to get dizzy from too much fighting against autotools.
<Yoric[DT]>
But essentially, it does the following
<Yoric[DT]>
* add a dependency of [install-doc] (formerly [instdoc]) in target [all]
<Yoric[DT]>
* change the default docdir
<Yoric[DT]>
(that's probably it)
<_zack>
ok, then:
<_zack>
1) can be done in Makefile.in, with an ifeq(@HAS_GODI@,yes)
<Yoric[DT]>
(which is what I do)
<_zack>
2) I don't see why it is needed, if godi users are required to pass --with-godi, then the docdir will be ok in Makefile already (by substitution from Makefile.in)
<Yoric[DT]>
Yeah, but I still don't know how to pass --with-godi.
<Yoric[DT]>
That was the whole problem.
<Yoric[DT]>
It's certainly not possible with godiva.
<_zack>
it is already implemented in the change I pushed 10 minutes ago
<Yoric[DT]>
No, I don't know how to pass --with-godi *from GODI*.
<_zack>
if you pull (conflicts permitting) you alreayd have a ./configure accepting --with-godi
<_zack>
aaaaaaaaaahhh
<Yoric[DT]>
I know it does.
<_zack>
is there anyway to recognize ./configure is being called form GODI?
<_zack>
an environment variable, anything
<_zack>
if there is, I can look for it in configure and autodetect the --with-godi flag
<Yoric[DT]>
That's the problem, I don't think there's any.
<Yoric[DT]>
I'll check further.
<_zack>
at worst we can have the GODI DOCDIR as the default default (pun), and everybody else is required to use --with-docdir
<Yoric[DT]>
:)
<Yoric[DT]>
Well, actually, there's a simple solution.
<Yoric[DT]>
Embed a patch to configure.
<Yoric[DT]>
(in the GODI package, that is)
<Yoric[DT]>
Something which will trigger --with-godi.
<_zack>
it is enough as simply as adding HAS_GODI=yes after the first line of ./configure
<Yoric[DT]>
ok
<_zack>
unless, ... wait a sec, let me check
<_zack>
nope, that doesn't work, I'll figure out an easy alternative
<Yoric[DT]>
Ok, I think I've found how to do that.
<Yoric[DT]>
I mean passing an argument to configure.
<_zack>
ah, cool
<_zack>
still, let me make a fix to configure.ac
<_zack>
then you can revert your changes to configure.ac and rely on HAS_GODI=yes in Makefile.in (rather than on INSTALLATION)
<_zack>
Yoric[DT]: what should be the default docroot when GODI is *not* enabled? your configure.ac used DOCROOT, but it is undefined there
jeddhaberstro has joined #ocaml
<_zack>
(that's the only missing bit)
palomer has quit ["Leaving"]
<Yoric[DT]>
The way I've found to pass an argument to configure is annoying, though.
<Yoric[DT]>
So if you have a way which relies only on arguments inside the Makefile, I'd prefer.
<Yoric[DT]>
Why shouldn't the default docroot be the default directory supplied by autotools ?
<Yoric[DT]>
I don't understand that.
<_zack>
ah ok, that's fine
<munga>
how to I tell ocamlbuild to ignore one directory (containintg c++ files and .so) in my source tree ?
<Yoric[DT]>
Don't [include] it?
<munga>
?
<_zack>
Yoric[DT]: I've just pushed the other fixes, I'll look for how to patch easily configure
<Yoric[DT]>
munga: did you add a tag to include that directory?
<Yoric[DT]>
_zack: ok.
<munga>
I think it complains just because there are .so that are result of a separate compilation process.
* Yoric[DT]
will take a break.
* Yoric[DT]
is too irritated by autotools.
<munga>
Yoric[DT]: no, there are no tags that are related to that directory...
<Yoric[DT]>
ok
<_zack>
Yoric[DT]: is it possible to easily pass arguments to "make" with GODI?
<Yoric[DT]>
_zack: well, it's possible to easily patch Makefile.in .
<_zack>
Yoric[DT]: right, so the solution you want is filling DOCDIR with a Makefile.in
<_zack>
"with a patch to Makefile.in" sorry
<Yoric[DT]>
Ah, ok.
<Yoric[DT]>
Yes.
<_zack>
deal? :-)
<Yoric[DT]>
That and the Makefile.in target.
<Yoric[DT]>
(to add [install-doc] in [all])
<Yoric[DT]>
Yeah, deal :)
<_zack>
Makefile.in target can be that or the ifeq, as you prefer
<_zack>
the ifeq is cleaner IMO
<Yoric[DT]>
Than what?
<_zack>
than patching Makefile.in also to add the target
<Yoric[DT]>
Oh.
<munga>
... from the command line is -X ... is there a directive in _tags to do the same thing ?
<Yoric[DT]>
There's a tag [not_hygienic] which may help you.
<Yoric[DT]>
Or [precious].
<Yoric[DT]>
_zack: good with me.
<Yoric[DT]>
_zack: should I wait for a push?
<_zack>
Yoric[DT]: I've already pushed, but Makefile.in still relies on INSTALLATION, give me another sec to port it to HAS_GODI
<Yoric[DT]>
ok
<_zack>
Yoric[DT]: pushed, actually, even DOCDIR is under HAS_GODI, so it is enough to set HAS_GODI = yes with your patch
<Yoric[DT]>
ok
<Yoric[DT]>
Thanks.
* Yoric[DT]
has network problems.
<Yoric[DT]>
Test in progress, results in about 20 minutes.
* Yoric[DT]
is taking that time to read about lambdas in C++.
<Yoric[DT]>
The result is... humorous.
<munga>
not_hygienic did the trick
<munga>
thanks :)
sporkmonger_ has joined #ocaml
sporkmonger_ has quit [Client Quit]
sporkmonger_ has joined #ocaml
<Yoric[DT]>
np
<Yoric[DT]>
Test failed, fixing, trying again...
sporkmonger has quit [Read error: 110 (Connection timed out)]
damg has joined #ocaml
willb has joined #ocaml
velco has quit [Remote closed the connection]
velco has joined #ocaml
tomh has joined #ocaml
jeddhaberstro has quit []
damg has quit [Remote closed the connection]
pango has quit [Remote closed the connection]
pango has joined #ocaml
<Yoric[DT]>
Finally...
<Yoric[DT]>
It worked!
<_zack>
\o/
<Camarade_Tux>
congrats ;)
<Yoric[DT]>
Now, I'll need to blog about it.
* Yoric[DT]
suddenly feels tired.
jlouis has joined #ocaml
<Camarade_Tux>
I surrender, types with -rectypes are too annoying
<flux>
:)
<flux>
camarade_tux, what did you try to use them for?
<Camarade_Tux>
(especially when you're looking at code you haven't touched in months)
<flux>
camarade_tux, wanted to avoid intermediate constructors in recursive types?
<flux>
(hmm, I guess that's the only use?-))
<Camarade_Tux>
flux, I was using my patricia tree in another program
<Kerris4>
ahahaha I'm trying to do the exercises in Essentials of Programming Languages but in OCaml
<Camarade_Tux>
and it is using rectypes
<flux>
camarade_tux, hence everything you do must be rectypes?
<Camarade_Tux>
flux, yep, it propagates
<Camarade_Tux>
and the bad part is I can't remember why one type was like it was (* (string * 'a) where 'a was enough*)
<flux>
I suppose rectypes is mostly useful for demo purposes..
<Camarade_Tux>
and trees ;)
<flux>
maybe it was more useful if it wasn't contagious
<Camarade_Tux>
hmmm, actually it may be alright :)
<Camarade_Tux>
the error I'm having is on a different line this time :)
<Camarade_Tux>
it's still unreadable of course but that's an improvement still
<Kerris4>
could anyone please give me a brief rundown of tail recursion versus, er, not (tail recursion)?
<Kerris4>
as far as I know tail recursions are iterative loops written differently
filp has quit ["Bye"]
<Camarade_Tux>
well there are different things but at least this : "A tail-recursive function uses constant stack space, while a non-tail-recursive function uses stack space proportional to the length of its list argument, which can be a problem with very long lists."
<Camarade_Tux>
(now, really gone)
<Kerris4>
thanks Camarade_Tux :)
<Camarade_Tux>
but that's just a quick beginning, I just don't have time for more :p
<Yoric[DT]>
Are there any GODI users around here?
<Yoric[DT]>
mfp: ping
<Camarade_Tux>
Yoric[DT], for a few minutes
<Yoric[DT]>
Camarade_Tux: not long enough.
<Camarade_Tux>
(I just launched the new batteries)
<Camarade_Tux>
ok
<Yoric[DT]>
(installation lasts 15+ minutes...)
<Camarade_Tux>
Yoric[DT], hehe : gzip: /ocaml/build/distfiles//batteries-20081110.tgz: unexpected end of file
<Yoric[DT]>
Yeah, there was an upload problem.
<Yoric[DT]>
Re-uploading now...
<_zack>
Yoric[DT]: thanks for the release, good job!
<Yoric[DT]>
Not quite done yet, obviously.
<Camarade_Tux>
and the recursive type is fixed (but I'm so late)
<_zack>
well, we already have 3 downloads ;)
<Yoric[DT]>
Mrf.
<Yoric[DT]>
Something is wrong.
<Yoric[DT]>
checksum fails
<Yoric[DT]>
Grmph.
<Yoric[DT]>
Still fails.
<Yoric[DT]>
Well, let's re-upload everything.
flux has quit [Read error: 104 (Connection reset by peer)]
flux has joined #ocaml
<Yoric[DT]>
I don't get it.
<Yoric[DT]>
I just don't get it.
<Yoric[DT]>
Probably some cache on GODI's server.
flx has joined #ocaml
<hcarty>
Yoric[DT]: Is the source fetched from a mirror that hasn't updated yet?
<Yoric[DT]>
The problem is during mirror update.
<Yoric[DT]>
(which is a mandatory step)
<Yoric[DT]>
Nope.
<Yoric[DT]>
Not better.
<Yoric[DT]>
Ah...
<Kerris4>
could somebody please give me a hand with using pattern matching?
<Kerris0>
Camarade_Tux: working through the exercises of the first chapter of Essentials of Programming Languages to familiarize myself with pattern matching and recursion with OCaml
<Kerris0>
it's like using a cleaver to apply butter in this instance, I guess
hkBst has joined #ocaml
seafood has joined #ocaml
<Camarade_Tux>
I would have said it's nonsensical, but anyway, what is the problem in eclipse ?
<Kerris0>
It compiles on save, but when I select the text, right click and select 'Load in Toplevel', attempting to execute, say, duple 5 6;; from the toplevel gives me a Unbound value duple error message
<Kerris0>
the code works if I type it into the toplevel and append ;; to the end
sporkmonger_ is now known as sporkmonger
<Camarade_Tux>
and if you append ";;" at the end of the definition of duple, *in ocamlde* ?
<Kerris0>
Camarade_Tux: loading the code after appending ";;" to it in the text area still doesn't work
<Kerris0>
thanks anyway, I can live with this
<Camarade_Tux>
ok
* Camarade_Tux
just found again the code for the Obfuscated Code Contest were to be send to Pierre Weis
itewsh has quit ["KTHXBYE"]
<Kerris0>
I can justify sticking to the toplevel for now because I'm a beginner :V
<mbacarella>
here let me save you some aggravation
<Camarade_Tux>
or ledit, but ledit needs some configuration first
<Kerris0>
thanks mbacarella :)
<Kerris0>
and thanks Camarade_Tux, this will come in handy when my machine arrives in 2 weeks :)
<Camarade_Tux>
I must admit ledit vs. rlwrap is political ;)
<mbacarella>
ledit?
<mbacarella>
rlwrap was just already installed here
<flux>
rlwrap is better ;)
<flux>
(I switched)
Raevel has quit ["leaving"]
<Camarade_Tux>
line edit, by Daniel De Rauglaudre, it's written in ocaml (relies on camlp5) and achieves the same thing once configured
<mbacarella>
i can get rlwrap to segfault sometimes
<Camarade_Tux>
flux, really ? what made you switch ?
<flux>
camarade_tux, like ctrl-r?
<flux>
well, readline is quite a complete readline-implementation..
<flux>
ledit didn't work with some software, rlwrap seems to. it hasn't crashed for me yet, but it's written in C, so..
<Camarade_Tux>
flux, I haven't used the toplevel since the new version of ledit came out and therefore have not configured ledit but I'm sure it can be configured for everything
<Camarade_Tux>
and I too had problems with one or two programs with ledit (godi_console for instance iirc) but as long as works with ocaml, I'm happy with it
<flux>
well, atleast ctrl-t works nowadays
<flux>
^W doesn't, but if you say that it can be configured, I suppose it would work too
<flux>
the manual page mentions nothing of rebindings keys
<flux>
(ledit 1.11)
<Yoric[DT]>
Camarade_Tux: I will :)
<Camarade_Tux>
Asmadeus, biiiiiiiiip, I can't remember, can you confirm ^w, ^r, and so on can be configured in ledit ? :)
<flux>
M-t doesn't work, C-t does
<Camarade_Tux>
Yoric[DT], I'll maybe set you up an ssh access on 64 bit so you can test with godi or anything you want (I'm already doing that for Nightstrike : "<Nightstrike> I'm using the whole gcc farm right now, which is 38 cpu cores" ;p )
<Yoric[DT]>
Camarade_Tux: that's nice, thanks.
<Camarade_Tux>
flux, well, Asmadeus spent a lot more time on customizing ledit than I did (mostly because I'm a vim guy and he's an emacs one) so I can't tell you more
<Yoric[DT]>
grrrr....
<flux>
camarade_tux, in any case, the political reasons to prefer rlwrap don't affect me ;)
<flux>
uh, to prefer ledit over rlwrap
<Yoric[DT]>
Checksum problem again...
<flux>
yoric[dt], what do you use for uploading?
<Yoric[DT]>
The GODI administration tool.
<Yoric[DT]>
I believe it has issues with two successive files having the same name but different checksums.
<Camarade_Tux>
flux, rlwrap uses readline and it's because of readline's license that the corresponding capabilities are not available in 'ocaml' ;)
<flux>
camarade_tux, yes, but if ocaml were to switch to use, say, libedit, I'd probably forget about rlrwap
<Camarade_Tux>
but you're right, that's only political, nothing more (not like vim vs. the world which is just because vim is simply superior ...)
<flux>
(iirc libedit was the name of a bsd-licensed libreadline-clone)
<Camarade_Tux>
flux, just checked, right
<Yoric[DT]>
If anyone wishes to implement a toplevel with built-in libedit, we're interested.
<mbacarella>
hmmm
<flux>
yoric[dt], wouldn't that mean batteries would have its own ocaml? or were you thinking pushing to upstream?
<Camarade_Tux>
I'm trying to find the discussion that happened on the mailing-list about readline-capabilities
<Yoric[DT]>
flux: actually, there's a hook to allow this in the toplevel.
<Yoric[DT]>
So we don't need our own ocaml.
<flux>
yoric[dt], oh, that's nice
<flux>
so a function to call in place of simple input_line?
<flux>
I suppose a decent first step would be to provide bindings for libedit, although ocaml toplevel would hardly require everything libread has
<flux>
writing an interface to that all seems like a big task..
<Yoric[DT]>
val read_interactive_input : (string -> string -> int -> int * bool) ref
<flux>
camarade_tux, one issue comes to mind: the example refers to FILE*'s stdin, stdout, stderr..
<mbacarella>
wouldn't the ocaml toplevel only need a glue-library to provide, say, otel_init(), otel_get_line(), otel_add_line(), and otel_fini() ?
<Camarade_Tux>
Yoric[DT], there you go, extracted and compiling (I'll leave my computer for a few minutes but that should be the time for ocamldoc to complete)
* mfp
building
<mbacarella>
$ locate histedit.h
<mbacarella>
/usr/include/histedit.h
<mbacarella>
crap
<Camarade_Tux>
flux, it is available on windows as far as I can tell
<mbacarella>
damn that sample code even compiles and runs
<Camarade_Tux>
Yoric[DT], ok, thanks, I'll try that on tomorrow morning
<Yoric[DT]>
Great :)
<Yoric[DT]>
What do you intend to do?
<Camarade_Tux>
7zip/lzma bindings, they're ready, except they need a better interface
<Yoric[DT]>
great
<Yoric[DT]>
You should get in touch with _zack, if you haven't done so yet.
<Yoric[DT]>
He's our manager for (de)compression.
<Yoric[DT]>
We also have a (temporary) common API.
<Yoric[DT]>
For this purpose, you should read the documentation of module Compress.
<Camarade_Tux>
ok, I'll take a look at the api and see with _zack :)
<Camarade_Tux>
hmmm, do I have enough free ram to start a windows vm ?
<Camarade_Tux>
oh, yeah, of course, I don't have 800MB in a tmpfs because of windows updates...
itewsh has joined #ocaml
filp has joined #ocaml
<mbacarella>
ok seriously ocaml toplevel to libedit looks really easy to me
<mbacarella>
what's the catch?
jeddhaberstro has joined #ocaml
<flux>
there's no catch. now, go do it :)
<flux>
(but if you do find a catch, please do tell)
<mbacarella>
ahaha
<mfp>
Yoric[DT]: worked
<Yoric[DT]>
\o/
<Yoric[DT]>
Camarade_Tux: what about you?
<mbacarella>
maybe i can convince my employer to let me work on it during work hours
<flux>
good luck with that
<Camarade_Tux>
Yoric[DT], just completed and working :)
<Camarade_Tux>
\o/
<Yoric[DT]>
\o/ again
<Yoric[DT]>
releasing
<Yoric[DT]>
released
<Camarade_Tux>
ncurses compiling, I love slackware, when something doesn't build for windows, I can take the slackware build scripts, add --host=mingw32 to the configure invocation and everything works :)
* Yoric[DT]
will now take a long break.
<flux>
yes, good night ;)
<Yoric[DT]>
Tomorrow, I have to finish a paper which has been postponed too long because of Batteries.
<flux>
what's the paper about? you might've mentioned, but..
<Yoric[DT]>
(and, well, because I'm not motivated by research at the moment, thanks to my oh-so-motivating team)
<Yoric[DT]>
flux: exception monad
<Yoric[DT]>
(and I've next one in the series starting, with an attempt at types-and-effects in OCaml without monads)
<flux>
yoric[dt], how's that going?
<Yoric[DT]>
Camlp4 and needing to rewrite every single library.
<Kerris0>
how should I go about testing if a variable is an int?
<Yoric[DT]>
Essentially :)
<flux>
yoric[dt], so, piece of cake!
<Yoric[DT]>
Kerris0 you don't.
<Yoric[DT]>
Still, time for a break.
<Yoric[DT]>
Cheers.
<flux>
yoric[dt], well, job well done, you deserve some break ;)
<flux>
(not forgetting the rest of the people involved in batteries, krhm ;))
<Yoric[DT]>
Oh, forgot to announce on the OCaml mailing-list.
<Camarade_Tux>
Kerris0, you can't test the type of a variable at runtime if that's what you're asking for
<Camarade_Tux>
and, building for windows is not as easy as I first thought but it shouldn't be long either
<Kerris0>
crumbs, this is a new paradigm all right :D
<flux>
kerris0, the first time you try to check if a value is an integer, it becomes one ;)
<Camarade_Tux>
Kerris0, well, your variable has only one type anyway ;)
<flux>
even if that type is "anytype"
<Camarade_Tux>
hehe, [Godi-list] Checksum mismatch while building godi-batteries
filp has quit ["Bye"]
seafood has quit []
<Yoric[DT]>
Camarade_Tux: gasp.
<Yoric[DT]>
Who?
<Yoric[DT]>
What?
<Kerris0>
er, this may seem bizarre to you guys, but does this follow the OCaml school of though? http://pastebin.com/m13a43674
<Camarade_Tux>
Yoric[DT], answered ;)
<Kerris0>
s/though/thought/
<Yoric[DT]>
Kerris0: well, it's always going to return true, if that's the question.
<Kerris0>
ugh, it throws an exception rather than return false if I put in a float, that's not good :(
* Yoric[DT]
will now take that break.
<flux>
kerris0, you would write it with 'function' instead
<flux>
kerris0, let rec isInt = function 0 -> true | n when .. etc
<Kerris0>
thanks flux, I'll rewrite it now
mbishop has joined #ocaml
<flux>
also, although this is may be a more subjective, I've always used lower_case_identifiers_with__'s in O'Caml
<Camarade_Tux>
Kerris0, 'type entier_ou_flottant = I of int | F of float'
<Camarade_Tux>
that's the most common way to mix different types
<Camarade_Tux>
anyway, off for a while as I said
<Kerris0>
thanks Camarade_Tux
dabd has joined #ocaml
<dabd>
hi, I'm trying to build janest-core using godi but I get an error. Googling for the solution I found that I need to downgrade bin-prot. How to do that?