Linktim_ has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
Yoric[DT], ok, see
<Camarade_Tux>
btw, I wanted to ask something about your mozilla plugins slides : what do you mean with 'C++' when speaking of vulnerabilities (I'm no firefox plugin developper)
<Camarade_Tux>
?
<Yoric[DT]>
You can put native (C++) code in an extension.
<Yoric[DT]>
This code has strictly no restraint, no sandbox whatsoever.
<Yoric[DT]>
In particular, this code has access to the in-memory representation of the JavaScript environment.
<Camarade_Tux>
ok, I see, that's indeed pretty dangerous
<Camarade_Tux>
thanks
<Yoric[DT]>
My pleasure.
<thelema>
Yoric[DT]: pong
<Yoric[DT]>
thelema: for the moment, I'm hard-coding batteries.mllib .
<Yoric[DT]>
That should be sufficient for the first release.
<Yoric[DT]>
I'll have ocamlbuild generate it automatically (with topo sort) after we reach our first release.
<thelema>
ok.
<Yoric[DT]>
Right now, I'm trying to fix native linking issues.
<Yoric[DT]>
Then I'll get on to Camlp4.
<Yoric[DT]>
Speaking of which I'll have to ask ertai[NP] a few questions about integrating Camlp4.
<thelema>
he ponged earlier
<Yoric[DT]>
Yeah, I have him on /msg at the moment.
<Yoric[DT]>
Just on a different subject.
<Yoric[DT]>
thelema: on a different subject, I'm going to talk about Batteries in the next OCaml Workshop (in January).
<Yoric[DT]>
I may also try and send a short paper for JFLA.
<Smerdyakov>
You would stoop so low as to submit to a regional publication? :)
<Yoric[DT]>
For a very simple reason: it's co-located with the OCaml Workshop :)
tomh has joined #ocaml
<thelema>
What's there to say about batteries? I'll admit you have lots of fun with the build system, but technically I don't see the big deal.
<Yoric[DT]>
Just for publicity purposes.
<Yoric[DT]>
Batteries is useful only if people actually adopt it.
<Yoric[DT]>
And they're not going to adopt it if they don't know about it.
<thelema>
yes, I appreciate all the work you do in publicizing batteries.
marmotine has joined #ocaml
<thelema>
but what's there to say other than "we've got a bunch of libraries working together in one package."
<Yoric[DT]>
Well, there's the fact that many people don't seem to understand what Batteries is all about.
<Yoric[DT]>
From my current discussion with ertai[NP], it seems that Xavier Leroy, for one, doesn't.
<thelema>
speaking of which, one demand of mine was easy installation.
<thelema>
I agree with keeping cammomile external, but can we auto-install it as part of our build system?
<Yoric[DT]>
That's an interesting question.
<Yoric[DT]>
I would say "no", because that might just play havoc with, say, GODI, apt-get, yum...
<Yoric[DT]>
On the other hand, if symbiosis has any success, all the question may become moot.
<thelema>
if people are building batteries outside of GODI/apt-get/yum... it doesn't matter
<thelema>
symbiosis?
<Yoric[DT]>
Yeah, but I hope that many people will use Batteries inside GODI/apt-get/yum.
<Yoric[DT]>
Symbiosis seems to be a ocamlbuild plug-in which handles download and installation of libraries.
<Smerdyakov>
Why write "apt-get" instead of just "apt"?
<thelema>
in which case the build system doesn't matter.
<Yoric[DT]>
Smerdyakov: fair enough.
<Smerdyakov>
There are other apt tools besides apt-get.
<thelema>
but before batteries gets packaged...
<Yoric[DT]>
thelema: well, it does for people using apt-build (thanks for the save, Smerdyakov:)), or other source-based management package.
<thelema>
of course we might detect if camomile is already installed (which it should be if using a package management tool), and not do anything extra
<Yoric[DT]>
That looks a bit too complex.
<Yoric[DT]>
Frankly, if/when we get to that point, I think we should switch to Symbiosis.
<Yoric[DT]>
Assuming that Symbiosis meets some success, that is.
<thelema>
the simple solution is to require people to get camomile, ocamlnet, cryptokit, JS's core (and all its dependencies) installed?
<thelema>
is JS's core packaged anywhere?
<Yoric[DT]>
Simple for us, yes.
<Yoric[DT]>
It's in GODI.
<thelema>
other than the tarball on their website?
<thelema>
ok.
<thelema>
I don't use GODI
<Yoric[DT]>
It's in Debian.
<Yoric[DT]>
libcore-ocaml
<Yoric[DT]>
It's in Fedora.
<Yoric[DT]>
(also as libcore-ocaml)
<thelema>
ok. I wasn't aware it was packaged (nor that anyone used it)
<Yoric[DT]>
(unrelated to our current conversation)
* thelema
reads
* Yoric[DT]
is currently faced with a linking problem in the native binary.
* Yoric[DT]
has "multiple definitions of [plenty of symbols]."
* thelema
starts benchmarking List
<thelema>
The "Gallium version" is the stdlib one, no?
<Yoric[DT]>
Yep.
itewsh has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
<Yoric[DT]>
thelema: can I put you as "in charge" of that task?
<thelema>
yes.
<thelema>
although I'll admit my conclusions should be taken with a grain of salt.
<Yoric[DT]>
Well, please make it as thorough as you can and publish the results.
<thelema>
of course.
Linktim has quit [Read error: 113 (No route to host)]
* thelema
expects to get lots of corrections to his testing methods after publishing results.
<Yoric[DT]>
That's the whole point :)
<thelema>
:)
Linktim has joined #ocaml
itewsh has quit [Read error: 110 (Connection timed out)]
itewsh has joined #ocaml
<thelema>
Yoric[DT]: I think there's a typo in the makefile - you ocamlbuild src/main/threads/batteries.cma, but you depend on src/main/threaded/batteries.cma for your doc rule.
pango has quit [Remote closed the connection]
<Yoric[DT]>
Which rule?
<thelema>
byte vs. doc
<Yoric[DT]>
I don't see it.
<thelema>
in byte you have /threads/
<thelema>
in doc, you depend on /threaded/
<thelema>
L101 vs L50
<thelema>
oops, not 101, maybe 99
<Yoric[DT]>
Are you sure it's the latest Makefile?
<Yoric[DT]>
Oh, ok
<Yoric[DT]>
Now, I get it
<thelema>
no, I could have messed up my merging. hold on.
<Yoric[DT]>
No, no, you're right.
<Yoric[DT]>
Fixed.
<thelema>
should batteries.mllib end in "Batteries\nBatteries\n"?
threeve has joined #ocaml
<thelema>
well, removing the second Batteries didn't fix the problem of "reference to undefined global 'BitSet'"
<Yoric[DT]>
Actually, I don't see the point of making it an array.
<olegfink>
and it makes perfect sense, as there's much more iteration that random access for argv
<olegfink>
and it's usually not very long
<Yoric[DT]>
s/the point/any point/
<olegfink>
plus who on earth wants argv to be mutable?
<thelema>
sometimes fun things come from setting argv(0)
<olegfink>
this question just raised from some discussion on ##java about code efficieny, I wanted to throw in a nice sample in ocaml: List.iter print_newline (List.sort compare Sys.argv) (this was the task), when I remembered that argv is a list and Array.sort is ... -> void
<Yoric[DT]>
Fun as in "Hello Batman, I'm Joker."
<olegfink>
er, s/void/unit/
<olegfink>
neither can I understand why things like print_newline don't return their argument, so many functions of type unit looks like no fun in a funcional language for me
* Yoric[DT]
agrees.
* thelema
disagrees - returning unit is a good thing
<thelema>
if you want to do something with the argument to print_newline, put it somewhere.
<olegfink>
that's because ocaml doesn't have haskell-like composition out of the box (maybe Batteries has it?)
<olegfink>
if it had, something like String.length . print_newline . "hi world" might look nice
<Yoric[DT]>
Simple function composition ?
<Yoric[DT]>
We have |- and -|
<Yoric[DT]>
Which map, iirc, to $ and .
<Yoric[DT]>
Or to the opposite.
<olegfink>
aha, that's it.
<olegfink>
nice, one more vote to add batteries to core then.
hkBst has quit [Read error: 104 (Connection reset by peer)]
Associat0r has quit []
<olegfink>
thelema: print_newline being string -> unit makes little sense as type map
<Yoric[DT]>
olegfink: or the opposite :)
<olegfink>
for haskell, they do with their monadic stuff. for ocaml, I'd prefer that the type of print_newline would state that it doesn't do anything interesting to the string - so string -> string
<olegfink>
Yoric[DT]: ?
<Yoric[DT]>
Adding Core to Batteries :)
<olegfink>
by core I meant what ships with ocaml
<Yoric[DT]>
Ah, ok.
<thelema>
I want my warnings when I don't use the return value of a function
<Yoric[DT]>
Vocabulary needs to be standardized.
<Yoric[DT]>
olegfink: for information, we call "base lib" what ships with ocaml.
<thelema>
Yoric[DT]: Gallium-lib?
<Yoric[DT]>
Well, except today, we call it Gallium-lib, but I assume that tomorrow, we'll resume calling it "base lib" :)
<Yoric[DT]>
We call Core the library defined by Jane Street.
<olegfink>
...and after merging batteries to base lib, the next step is adding ocaml support to ACM programming contest
<Yoric[DT]>
And we don't call anything "Standard Library", because everyone wants their library to be standard.
<olegfink>
heh, nice state of things for a not-so-young language :-)
<Yoric[DT]>
:)
<olegfink>
i see the main problem (with me) is that ocaml is considered the real world language, while haskell is for all those people who want to toy with crazy stuff. But for me, ocaml is purely FUNctional language, so I want some practically worthless niceties
<Yoric[DT]>
My problem is that Haskell is expected to be a toy language, but they're the ones with the real-world libraries.
rwmjones_ has joined #ocaml
marmotine has quit ["mv marmotine Laurie"]
<olegfink>
ocaml's library support is somewhat C-like, while haskell has some more modern things. Or at least I tried to built much more ocaml modules than haskell libraries
<olegfink>
oh, and speaking more on-topic, is there anything like declarative files for ocaml?
<olegfink>
(I'm afraid that's my own term)
<Yoric[DT]>
Declarative files ?
<olegfink>
something like file in = [ n = int; l = int list [n] ]
<thelema>
olegfink: like header files in C to give types?
<Yoric[DT]>
olegfink: I don't quite understand what that should mean.
<thelema>
olegfink: rwmjones madr something like that with his bitstrings library
<thelema>
*made
<olegfink>
which would define a file with an integer n and then n integers, accesible to me in bindings 'n' and 'l' respectively
<olegfink>
ah
<Yoric[DT]>
What are these?
<Yoric[DT]>
Rows?
<Yoric[DT]>
Oh, ok, you're mapping the contents of an existing file to variables, is that it?
<olegfink>
yes.
<Yoric[DT]>
Well, I don't think there's anything like this.
<olegfink>
preferably in a lazy manner
<Yoric[DT]>
You could add some syntactic sugar on top of a parser to obtain this, I guess.
<olegfink>
yeah, I even wrote something, was just chechking if there's something more clever.
<olegfink>
I got this idea from ACM contest, all their files are defined like this, so it would be nice if I could just write what the task says and don't care about actual I/O
Palace_Chan has joined #ocaml
<olegfink>
thelema: ah, bitmatch is very close to what I wanted, thanks
<olegfink>
but in fact my thing really calls for lazy data structures :/
<thelema>
You're welcome to make bitmatch lazy.
<Yoric[DT]>
The second release of Batteries will offer a parser combinator library.
<Yoric[DT]>
I guess that may be a nice place to hack, too.
<thelema>
and there's some other parser combinator libraries out there - google "core foundatin"
<thelema>
*foundation
<Yoric[DT]>
thelema: I didn't know about that one.