<thelema>
intended to use package manager (linux distro or godi) to install
<thelema>
I'm still doing it the old-fashioned way too, so...
<Gionne>
tried with synaptic but had a lot of uninstalled packages
<thelema>
like what?
<mohbana>
how much knowledge of ocaml do i need to know to convert http://ant.berlios.de/ into scala. I'm sort of doing it just to see how the resulting code will look like.
<mohbana>
i should mention i've done haskell before
<Gionne>
i am configuring batteries
<Gionne>
package type-conf not found ;(
<Gionne>
maybe the repository universe?
<thelema>
Gionne: ocamlfind list
<Gionne>
in synaptic?
<Gionne>
apt-get?
<thelema>
in bash: $ ocamlfind list
<Gionne>
ok
<mohbana>
why do i have to explicitily declare lamba functions such as; (function n -> n^"append"
<thelema>
do you get anything?
<Gionne>
yes
<Gionne>
a lot of packages
<thelema>
but no type-conv package
<Gionne>
no type-conv
<thelema>
Gionne: so you haven't installed type-conv
<Gionne>
it seems so
<thelema>
mohbana: how would you like to write that?
<thelema>
To do unicode input right, I need to fork IO to have uchars and utf8 strings
<thelema>
or I have to encode to UTF and then write the byte stream...
jeddhaberstro has joined #ocaml
<thelema>
shall I make uinput and uoutput functions that work in terms of unicode chars/strings?
* thelema
has the feeling he skipped some steps in his stream of thought
<thelema>
Yoric[DT]: ??
<Camarade_Tux>
hi det :p
<Yoric[DT]>
I don't get it.
<det>
Camarade_Tux, I added extract to my bindings this morning and cleaned it up a little, if you are interested
<thelema>
ok. What should read () return for a unicode stream?
<thelema>
Yoric[DT]: ^
<Yoric[DT]>
thelema: good question :)
<mohbana>
what's the insight into terminating with ;;?
<det>
Camarade_Tux, do you use SzAr_Extract ?
<Yoric[DT]>
thelema: how does it work with netchannels?
* thelema
csn't get netchannels to compile
* thelema
tries again with source tarball instead of svn
<Camarade_Tux>
det, yes
<Camarade_Tux>
I had no time to work on that on my part =/
<thelema>
mohbana: ;; ends a toplevel phrase -- it's the token that makes the REPL swing into action
<det>
Camarade_Tux, I just do mostly the same thing as as SzAr_Extract (copied most of the code), and extract directly into an Ocaml string, to avoid copying
<det>
also, I was getting a memory leak when using SzAr_Extract, for some reason
<Camarade_Tux>
det, string ? =/
<det>
Camarade_Tux, what is wrong with string ?
<Camarade_Tux>
and iirc there's a different free for SzAr_Extract
<Camarade_Tux>
det, well, it's limited to 16MB on 32bit
<thelema>
Yoric[DT]: I guess I'm realizing I'll have to encode-decode to go from latin1 to utf bytestream, and I want to expose the intermediate layer of Unicode chars.
<det>
ohh
<det>
that is a problem
<Yoric[DT]>
thelema: in netchannels, there's input_char and input_line.
<det>
I guess I didnt notice because 64 bit
<Yoric[DT]>
thelema: in netchannels, there's input_char and input_byte, I meant.
<Yoric[DT]>
Mmmhh....
<Camarade_Tux>
det, one thing you can do is taking a Unix.file_descr as parameter and write to/from that (maybe using fdopen(), depending on your requirement)
<Yoric[DT]>
thelema: Ok, reading further, in netchannels, for Unicode, input_char/input_byte simply has no meaning.
<Camarade_Tux>
det, or you can probably use what is in Batteries, I had no time to truly check that though
<Yoric[DT]>
So yes, I'm afraid you should probably encode-decode, if it's feasible.
<Yoric[DT]>
Camarade_Tux: what's the objective?
<det>
Camarade_Tux, I am happy with my current interface: Sevenzip.open_readable takes read/seek/close closures
<thelema>
Yoric[DT]: should I expose the intermediate layer?
<Yoric[DT]>
How would you expose it?
<thelema>
as a uchar.t/utf8.string-based IO layer
<Camarade_Tux>
Yoric[DT], input/output compatible with Batterie's IO, I don't know how it looks likes from C though (or even ocaml in fact)
<det>
and Sevenzip.open_in is a convenience function that uses open_readable
<Yoric[DT]>
thelema: I think you shouldn't expose it.
<det>
Camarade_Tux, for batteries compatibility, I think you will need an interface like mine
<thelema>
Yoric[DT]: i.e. create_uin : read:(unit -> UChar.t) -> input:(UTF8.t -> int -> int -> int) -> ...
<Yoric[DT]>
After all, I guess that's the kind of thing that may change.
<Yoric[DT]>
Ah, that.
<Yoric[DT]>
Mmmhh....
<mohbana>
how much knowledge of ocaml do i need to know to convert http://ant.berlios.de/ into scala. I'm sort of doing it just to see how the resulting code will look like. I've used haskell before
<Camarade_Tux>
det, about the interface, in fact Batteries does not have a standard for multi-files archives so it's still a pending question ;)
<Yoric[DT]>
Camarade_Tux: feel free to suggest one :)
<det>
Camarade_Tux, but it has a standard for input and output channels
<det>
Camarade_Tux, which is what I am talking about
<Yoric[DT]>
mohbana: to answer your previous question, ;; is seldom necessary.
<Yoric[DT]>
It's essentially used to tell the REPL that you're done typing.
<Camarade_Tux>
Yoric[DT], yeah, I need to get a hold on zack when he's here and I have time, which hasn't happened yet =/
<thelema>
Yoric[DT]: is ;; ever necessary?
<thelema>
Yoric[DT]: outside the REPL
<Yoric[DT]>
thelema: well, you can write slightly shorter code with ;;
<det>
Camarade_Tux, You'll never be open to open an arbitrary Batteries in_channel, because an in_channel is just a record of closures
<Yoric[DT]>
(sometimes)
<Yoric[DT]>
det: do you mean [input]?
<Camarade_Tux>
det, yep, I have some time now so I'll see how to use them :)
<det>
Yoric[DT], probably
<Yoric[DT]>
Well, anyway, I had decided not to work today.
<Yoric[DT]>
So I'll stick to answering thelema's question and then I'll carry on with the cleaning of the house :)
<det>
Yoric[DT], yes, I do
<Yoric[DT]>
ok
<thelema>
Yoric[DT]: re: create_uin?
<Yoric[DT]>
thelema: this sounds like an interesting new constructor, yes.
<det>
Camarade_Tux, I can post my code somewhere if you want an example of using 7zip functions + closures
<Yoric[DT]>
thelema: my only possible issue with this is that we already have [open_in] and [wrap_in].
<det>
Also, I found out about caml_register_global_root, which simplifies playing nice with the GC
<Yoric[DT]>
So I'm wondering if you should add [open_uin] and [wrap_uin] or just [wrap_uin] or something smarter.
<det>
Yoric[DT], Have you guys considered using objects instead of record of closures to let libraries expose a batteries compatible interface without depending on batteries ?
<thelema>
[wrap_in] == [from_in_channel]?
<Yoric[DT]>
det: for IO?
<det>
Yoric[DT], for all similar interfaces
<det>
inputs/enums/etc
<Yoric[DT]>
det: well, we've discussed it for IO, not for the rest.
<Yoric[DT]>
I tend to believe that it would make things actually more complex.
<det>
Why ?
<Yoric[DT]>
mmmhh....
<Camarade_Tux>
det, your code is much closer than mine, mine is a bit more complete but that's only because I spend less time on being clean ;)
<det>
Camarade_Tux, I changed mine a lot this morning
<Yoric[DT]>
det: or do you mean keeping the same API but making the abstract type a concrete class?
<thelema>
Yoric[DT]: thanks for the feedback.
<Yoric[DT]>
s/class/object type/
<Yoric[DT]>
thelema: I don't understand your last question.
<Yoric[DT]>
There's a function [wrap_in] in IO (and in InnerIO).
<det>
Yoric[DT], I would like type input to be a class type, so I could use it in my sevenzip library without depending on batteries
<Camarade_Tux>
det, btw, do you know how to use blockIndex, outBuffer, outBufferSize (the cache variables) ?
<det>
Camarade_Tux, yes
<Yoric[DT]>
det: thing is, we're evil scheming bastards.
<Yoric[DT]>
We want you to depend on Batteries.
<Yoric[DT]>
We want the whole world to depend on Batteries.
<det>
This is a problem for you, I think
<Yoric[DT]>
Heck, we're Microsoft.
<det>
It centralizes everything too much
<det>
puts too much of a burden on you
<det>
using objects instead of closures for records lets batteries interfaces become more standard
pumpkin has left #ocaml []
<det>
I won't make my Sevenzip library depend on batteries, so in order for it to be able to work with batteries inputs, it will need an adapter
<Camarade_Tux>
the other possibility is writing some code for batteries and some for gallium, it could be done with some #ifdef
<Camarade_Tux>
that shouldn't be too long, just a few lines
<det>
Camarade_Tux, did you need help with those variables, or were you offering me help ?
<det>
It would be nice if I could just support the input interface by using: input#read, etc
<Yoric[DT]>
det: for input, we also provide classes, mind you.
<Camarade_Tux>
det, I was rather asking, I think they're just a cache of what has already been expanded but I'm not sure
<Yoric[DT]>
det: then there's a one-liner converter from classes to our usual interface.
<det>
Camarade_Tux, I think it is only relevant for 7zip solid archives
<Yoric[DT]>
det: would that be sufficient for you?
<det>
Camarade_Tux, but you're performance will suffer if you dont use them
<Yoric[DT]>
(same thing for output)
<Yoric[DT]>
Now, we could generalize this for enumerations, etc.
<Camarade_Tux>
det, I guess so, unless you find it funny to extract the same file several times =P
<det>
Yoric[DT], that leaves me wondering, why not just use the classes in the first place
<det>
Yoric[DT], they serve the same purpose but are easier to use
<Yoric[DT]>
det: easier?
<Yoric[DT]>
classes/
<Yoric[DT]>
classes?
itewsh has joined #ocaml
<Yoric[DT]>
In OCaml?
<det>
Yoric[DT], than records of closures? Yes.
<Yoric[DT]>
We probably don't know the same beginners :)
<Yoric[DT]>
The user never sees these records of closures.
<Yoric[DT]>
Heck, to extend the library, you don't even need to see these records of closures.
<Yoric[DT]>
So I hardly see any difficulty there.
Demitar has joined #ocaml
<det>
To implement an enum, you need to be able to create the right type of records
<det>
So you do need to see them
<Yoric[DT]>
How so?
<Yoric[DT]>
There's just a constructor.
<det>
Same thing
<det>
Objects are nicer because of structural typing
<Yoric[DT]>
In that case, the type is purely abstract, so makes for easier error messages.
<Yoric[DT]>
s/easier/simpler/
<Yoric[DT]>
I certainly don't want to impose classes on beginners.
<Yoric[DT]>
Since enumerations are omnipresent, beginners will be exposed to them.
<det>
I am not advocating doing away with Enum.xxx in favor of enum#xxx
<Yoric[DT]>
So what are you advocating?
<Yoric[DT]>
Doing away with Enum.create?
<det>
yes
<thelema>
det: why don't you want to depend on batteries?
<Yoric[DT]>
det: what's wrong with Enum.create?
<det>
Yoric[DT], because you need to depend on batteries to compile your library
<Yoric[DT]>
You'd rather have any function that returns an object on the correct type?
<det>
Yoric[DT], and you cant exist withotu batteries
<Yoric[DT]>
Well, as mentioned above, that's our objective:)
<thelema>
drat, gotta go
<Yoric[DT]>
thelema: cheers
<det>
I'd rather "Enum.xxx enum" used enum#next instead of enum.Enum.xxx
<Yoric[DT]>
Still, I understand your point.
<det>
The user never needs to be exposed to the fact that they are objects, rather than abstract
<Yoric[DT]>
I just don't understand your latest sentence :)
<Yoric[DT]>
Let me suggest something.
<Yoric[DT]>
Would you be willing to try and reimplement a few functions of Enum with objects and check performance?
<Yoric[DT]>
(and readability of error messages)
<det>
ok
<Yoric[DT]>
If there's no performance hit and if error messages are not too confusing, I'm willing to switch.
<det>
I think I have done some benchmarks before
<det>
similar
<Yoric[DT]>
Well, could you post them somewhere?
<det>
since record of closures is an unknown function call
<det>
I will make a comparison for the purpose of enums
<Yoric[DT]>
Well, I assume there will be no performance hit.
<Yoric[DT]>
But someone needs to check that.
<Yoric[DT]>
In addition, if this proves successful for Enum, we might do the same for IO.
<Yoric[DT]>
(well, essentially, switch to Netchannels + a few additional definitions)
<Yoric[DT]>
s/definitions/specifications/
<Yoric[DT]>
The only possible performance hit is method dispatch, as they are implemented with maps, iirc.
<det>
Also, I think objects have some advantages as well. Closure construction is linear in the number of "methods" and object size as well.
<det>
Does ocaml have a sizeof primitive ?
* Yoric[DT]
doesn't quite see the advantage.
<Yoric[DT]>
No.
<Yoric[DT]>
There's a technique for evaluating size but I don't know it and I don't know if it works with objects.
<flux>
I guess the biggest disadvantages of objects are that they can lead to more strange type errors (structural mismatch with an inferred type) and that some people are against them, apparently on religious grounds ;-)
<flux>
and, there is the performance issue as well..
<flux>
of course, it's not significantly slower than a closure-object, but not all the functions operating on an object need to be closures
<det>
I'll do a quick method dispatch vs closure application benchmark
<det>
flux, I think they do need to be closures
<flux>
in the case of Enum, yes
<det>
flux, I'm not advocating using #method for everything, just the "base enum" interface
<flux>
but there may be functions that aren't closures
<det>
so, you'd have the same non-closures for objects as closures
<det>
filter would still be a function, not a method
<Camarade_Tux>
if we're on IO, it's not sure it will matter (unless you use RAM somewhere)
<flux>
just yesterday I found out that 30% of processing incoming messages was spent parsing them
<flux>
now, it may be a coincidence, but the parser was an object with methods such as eof, next, etc.. ;-)
<det>
Of course, if you truly did want to depend on Batteries, object can give the advantage of using inheritance and overriding default methods with more efficient ones (think foldr on arrays, vs the default implement of reverse and foldl)
<Camarade_Tux>
but if you're only using them to call, that shouldn't make a big difference (let's compress with PAQ8 !)
<det>
flux, The real question is if records of closures are any better
<flux>
but, consider this: class a = object method dosomething enum = enum#next end
<flux>
one might expect that just to, well, work
<flux>
but it won't compile without type annotations
<flux>
so the point is that closures can be simpler type-wise than objects
<Yoric[DT]>
mohbana: very quick look: doesn't look too easy.
<flux>
perhaps the problems won't be seen by newbies, if they don't use objects
<Yoric[DT]>
Well, we can keep create_in and just make it return an object.
<Yoric[DT]>
On this point, testing is needed.
<Yoric[DT]>
s/point/whole question/
jeddhaberstro_ has joined #ocaml
<det>
closure dispatch takes 62% as long as method dispatch on my computer doing the simplest possible thing
<Yoric[DT]>
That's a bad point for objects.
<det>
Yes.
<det>
still, a loop of 10 million is a fraction of a second
<det>
I mean, 100 million
<det>
I wonder if that will change any in a non-toy example
<Yoric[DT]>
Well, finding a convincing test is your job :)
marmotine has quit [Remote closed the connection]
jeddhaberstro has quit [Read error: 110 (Connection timed out)]
<flux>
det, well, if it's the difference between scanning a file, say, 40M/s or 60M/s..
<flux>
(less relevant if it's 400M/s or 600M/s, though ;-))
thelema has quit [Read error: 104 (Connection reset by peer)]
<itewsh>
I've a question : How can I compute a power two of integer with a built in function ? (( **) is float->float->float=<fun> , I need a int->int->int=<fun> ...)
thelema has joined #ocaml
rwmjones has quit [Read error: 60 (Operation timed out)]
rwmjones has joined #ocaml
rwmjones_ has joined #ocaml
ygrek has quit [Remote closed the connection]
<Camarade_Tux>
itewsh, 'let square i = i * i' ? =)
<itewsh>
Camarade_Tux: yes, it's what I did ...
filp has quit ["Bye"]
<mfp>
det: if your benchmark involves something anything like for i = 1 to iterations; obj#meth end, it's the best case for method dispatching since the method is cached after the first lookup. In practice, the class of obj will differ between calls, forcing a method lookup and making this all significantly slower.
Palace_Chan has joined #ocaml
<mfp>
*for i = 1 to iterations do ... done wtf
<mfp>
method lookup is done using binary search over the method table
<Palace_Chan>
im trying to understand what this funciton does so i tried right beneath it calling it (in toplevel) with an example but it gives me a syntax error what is wrong ?
<mfp>
in the case of closures, you can do without any of this, leaving an indirect branch that shouldn't cost much more than a dozen cycles or so --- probably much less than the method lookup (it's a somewhat hard to measure though)
<thelema>
Palace_Chan: because of the;
<thelema>
Palace_Chan: if you want a ; in your if/then/else, you need () or begin/end
<mfp>
while this would not matter at all for something like #input, it'd probably represent too much overhead for e.g. #read_byte
<Palace_Chan>
like, if x > 0 then begin bla; bla; bla; d end else ... ?
<thelema>
Palace_Chan: yes
<Palace_Chan>
if i want that for loop to complete and tehn return fl at the end do i need a ; after done ?
<thelema>
yes.
itewsh has quit ["KTHXBYE"]
johnnowak has quit []
Palace_Chan has quit [Client Quit]
svref has joined #ocaml
<svref>
unison (an ocaml-based package in ubuntu) complains "no bytecode file specified". I think the unison package is broken, but what do y'all think?
<svref>
(and yes I checked the invocation of the unison command, the syntax is correct and identical to other machines where the command works)