studybot has quit [Read error: Connection reset by peer]
nikki93 has quit [Remote host closed the connection]
rgrinberg has quit [Quit: Leaving.]
studybot has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
q66 has quit [Quit: Leaving]
Guest23479 has quit [Remote host closed the connection]
ygrek has joined #ocaml
ente has quit [Quit: Caught SIGSEGV, exiting...]
coke0 has quit [Ping timeout: 252 seconds]
zzing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
coke0 has joined #ocaml
lordkryss has quit [Quit: Connection closed for inactivity]
rgrinberg has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
divyanshu has joined #ocaml
divyanshu has quit [Client Quit]
ygrek has joined #ocaml
divyanshu has joined #ocaml
brainacid has joined #ocaml
<brainacid>
hi
<brainacid>
im 29/m
<brainacid>
never programmed before
<brainacid>
looking make friends
<brainacid>
never went to college neither
<brainacid>
reading Functional Approach to Programming by Guy Cousineau
as has joined #ocaml
jpdeplaix has quit [Ping timeout: 264 seconds]
jpdeplaix has joined #ocaml
tab1293 has quit [Ping timeout: 240 seconds]
cesar_ has joined #ocaml
cesar_ is now known as Guest8254
divyanshu has quit [Ping timeout: 252 seconds]
NoNNaN has quit [Remote host closed the connection]
as has quit [Quit: Leaving]
Topher has left #ocaml []
iorivur has joined #ocaml
iorivur has quit [Ping timeout: 245 seconds]
rgrinberg has quit [Quit: Leaving.]
iorivur has joined #ocaml
nikki93 has joined #ocaml
bjorkintosh has joined #ocaml
LawrenceNBestial has joined #ocaml
<LawrenceNBestial>
So in OCaml, type constructors too are unary functions on types and a type constructor which takes two types as argument essentially takes a pair of types as argument right?
Guest8254 has quit [Remote host closed the connection]
rand000 has quit [Ping timeout: 245 seconds]
iorivur has joined #ocaml
ollehar has joined #ocaml
Simn has joined #ocaml
studybot has quit [Remote host closed the connection]
iorivur has quit [Ping timeout: 276 seconds]
yacks has quit [Ping timeout: 250 seconds]
ollehar has quit [Ping timeout: 252 seconds]
studybot has joined #ocaml
studybot_ has joined #ocaml
studybot has quit [Ping timeout: 240 seconds]
iorivur has joined #ocaml
ygrek has quit [Ping timeout: 276 seconds]
studybot_ has quit [Read error: Connection reset by peer]
Submarine has quit [Remote host closed the connection]
yacks has joined #ocaml
studybot has joined #ocaml
studybot_ has joined #ocaml
studybot_ has quit [Read error: Connection reset by peer]
ggole has joined #ocaml
studybot has quit [Ping timeout: 276 seconds]
studybot has joined #ocaml
nikki93 has quit [Remote host closed the connection]
divyanshu has quit [Ping timeout: 250 seconds]
divyanshu has joined #ocaml
nikki93 has joined #ocaml
AltGr has joined #ocaml
araujo has quit [Quit: Leaving]
ygrek has joined #ocaml
iorivur has quit [Ping timeout: 252 seconds]
<companion_cube>
LawrenceNBestial: yes, that's it
<companion_cube>
types form a small stack language ;)
<companion_cube>
brainacid: hi
ikaros has joined #ocaml
iorivur has joined #ocaml
nikki93 has quit [Remote host closed the connection]
rand000 has joined #ocaml
<ggole>
Types aren't "curried", though
<ggole>
You always have to fully apply one
<companion_cube>
which is a bit sad (also type constructors should be functions)
<ggole>
You mean "first class" constructors as in type 'c foo = int 'c?
Muzer has quit [Excess Flood]
maattdd has joined #ocaml
Muzer has joined #ocaml
tab1293 has joined #ocaml
tab1293 has quit [Client Quit]
nikki93 has joined #ocaml
<companion_cube>
ggole: no I was thinking about algebraic constructors
<companion_cube>
for instance Some should be a unary function
<nicoo>
ggole: I think he means that if I have `type f = Bar of int | Baz of bool`, I should have `Bar: int -> f` and `Baz: bool -> f`
* nicoo
is too slow this morning
<ggole>
Oh, right
<ggole>
The need for that isn't that common, though
<companion_cube>
I regularly have to write (fun x -> Some x) or (fun x y -> x::y)
<ggole>
You could easily have Option.some/none or List.cons
<companion_cube>
yes, it's in batteries ;)
<companion_cube>
but that would be nice to have support from the language
<ggole>
And that's, what, 95% of the use cases?
<ggole>
I see the attraction though.
<nicoo>
ggole: The part I don't get is that it was that way in Caml Light, and constructors-as-functions got removed in OCaml
<ggole>
Yeah, it'd be interesting to hear the rationale for that.
<rand000>
I'm just thinking.. how would that work with patternmatching?
<companion_cube>
what's the problem?
<companion_cube>
you should only match against atomic values anyway
<ggole>
Just the same as it currently does
<rand000>
companion_cube: if the constructors names were bound to functions?
<companion_cube>
(and constructors in OCaml aren't curried)
<ggole>
You wouldn't be able to use arbitrary functions
<companion_cube>
rand000: I didn't say that
<rand000>
companion_cube: ah ok
<companion_cube>
I said constructors could behave like functions in expressions
<companion_cube>
but still as constructors in patterns
<rand000>
companion_cube: ah (: .. but that was how it was in Caml light?
<companion_cube>
I don't know
<ggole>
One implication is that the syntax should be changed
<rand000>
to mee it would seem a bit like "syntax overloading" .. if you follow me
<ggole>
Otherwise applying a 2-ary constructor would look like Foo (a + b) "zonk", while destructuring one would look like Foo (_, "zonk")
<companion_cube>
ggole: hmm, indeed, there's a problem with n-ary constructors
<companion_cube>
the clean solution is to have curried constructors
<companion_cube>
but, well, compatibility
<ggole>
Bit strange that OCaml has so many application syntaxes
<ggole>
Four, all different O_o
thomasga has joined #ocaml
<nicoo>
ggole: Types, expressions, constructors (in patterns) and functors ?
<ggole>
Yep.
<nicoo>
Propose a fix for Chamelle n°5 :]
<nicoo>
(TBH, having a separate application syntax for functors doesn't bother me ; it would be nice to have the same syntax as in exprs for constructors and types, though)
Kakadu has joined #ocaml
cyborks has joined #ocaml
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ia0>
in haskell, they also use Foo (a + b) "zonk" for pattern matching
<companion_cube>
it's deprecated, isn't it?
<companion_cube>
n+k patterns, I mean
<ggole>
Foo (a :+ b) "zonk" works though
<ia0>
companion_cube: yes, I meant the Foo x y syntax against Foo (x, y)
<companion_cube>
ah, yes
<companion_cube>
haskell is much better for this
<companion_cube>
also, types look better because they're not reversed
<def-lkb>
This provide a nice way to distinguish between Foo of a * b * c and Foo of (a * b * c)… Less confusion with haskell-style
<companion_cube>
and we could write (a, b) rather than (a * b)
iorivur has quit [Ping timeout: 240 seconds]
<def-lkb>
Not sure this is of any benefit. Except you'll need a new syntax for type constructors too
<ggole>
The benefit is that the type syntax matches the construction syntax as it does with other types.
<ggole>
It's a minor aesthetic thing.
<ia0>
I am not sure this is a good thing to mimic terms in types
<ia0>
First, because it would lead to problems with potential dependant types
<ia0>
(which is already the case with promotion in haskell)
<ia0>
Second, because it may be confusing at first (it depends on the person)
<companion_cube>
wouldn't the type of (a, b) be (typeof a, typeof b) even with dependent types?
<ia0>
yes, but how do you make the difference between (int, int) as the pair of two ints (product kind), or as the type of pairs of ints.
<ia0>
(kind star, for the last)
lordkryss has joined #ocaml
<companion_cube>
hmmmm, I'm don't follow :(
<Drup>
companion_cube: ('a,'b) foo vs ('a * 'b) foo
<Drup>
(if i understood correctly)
<companion_cube>
well with curried syntax that wouldn't exist
<companion_cube>
the first one would be foo a b, the second one foo (a, b)
<Drup>
yes
<ggole>
Aargh, once again I get bitten by printing to channels instead of buffers
iorivur has joined #ocaml
<ia0>
companion_cube: but you don't want to currify everything, sometimes you really mean a pair
<companion_cube>
well a pair is (a, b), that's it
<companion_cube>
if you want to partially apply (,) then call (,) int
<ia0>
or it could be also the product type of a and b according to you
<ia0>
it's not about partial application
<companion_cube>
well if a and b are types, (a,b) is a type, isn't it?
<ia0>
yes, but not necessarily of the kind star
<ggole>
I think ia0 is suggesting that in a language in which types and values are bound in the same namespace, you cannot use (,) for two things.
<companion_cube>
ok, dependent types might be more complicated
<Drup>
ia0: there shouldn't be any notion of "pair" at the type level
<Drup>
there is a notion of product and that's all
<Drup>
we aren't in a dependently typed language :)
<ia0>
for now
<Drup>
I hope never
<ia0>
hehe :-)
Thooms has joined #ocaml
<ia0>
we don't know the future
<Drup>
dependently type is like // build system
<companion_cube>
that really wouln't be ocaml anymore
<ia0>
for now, let researchers do their job
<Drup>
trying to retrofit it to a non dependetly type language is bad
<ia0>
and make dependent types easy to use
<Drup>
ia0: believe me, it has to be there from the start
<companion_cube>
ia0: let's use Idris for this kind (no pun intended) of stuff instead
<nicoo>
companion_cube: I prefer the OCaml-style a * b syntax (for types) than the Haskell-style (a,b) which looks like a pair of types, and not the type of pairs
<companion_cube>
ok, why not
<companion_cube>
but currying types (with a prefix syntax) is really better
<companion_cube>
than the stack-ish syntax of ocaml
<nicoo>
companion_cube: Agreed
<Drup>
(currified type is useless without higher kind anyway)
<nicoo>
companion_cube: Mmmmh, it might even be possible to add without breaking backward-compatibility (of course, it breaks forward-compat)
<companion_cube>
Drup: it's just more readable
<nicoo>
Drup: Well, it's more about readability of types & pattern-matchings than about adding HKP.
gargawel has quit [Ping timeout: 240 seconds]
gargawel has joined #ocaml
zarul[afk] has quit [Read error: Connection timed out]
studybot has quit [Remote host closed the connection]
iorivur_ has quit [Ping timeout: 276 seconds]
rand000 has joined #ocaml
thomasga has quit [Quit: Leaving.]
<gasche>
companion_cube: I don't think * is a problem in any case
<gasche>
and I think having a 'list' is better than [a]
<Drup>
(I agree with the [ ] point)
<gasche>
I don't think it is obvious that ('a, 'b) hashtbl is a mistake
<gasche>
it's actually quite nice in the small
<gasche>
though I do agree that keeping the usual application order makes things easier in the long run, to interoperate with other languages in some sense
<gasche>
and that higher-kinded designs do benefit from using the usual function application syntax
ygrek has quit [Ping timeout: 258 seconds]
<gasche>
in short: I agree (hashtbl 'a 'b) would be better, but I also think that's not something that could have been anticipated; among the many things I'd change in the OCaml syntax it's by far not the worse
<ggole>
What would you change first?
<companion_cube>
gasche: yes, but list 'a would be even better
<ousado>
I have just been made aware that haxe releases are built using that
<gasche>
I think that, to many users, stability of Batteries is the main point that makes them users -- instead of using Core that has much more publicity these days
<flux>
interesting
<gasche>
doing an incompatible release or an incompatible fork seems very unwise in that context, if the goal is to retain users
<gasche>
and I don't have the impression that much efforts have been spent making batteries-light backward-compatible; the gut feeling being that it should be able to bend a few things to make that possible
<flux>
I think I would agree
<gasche>
(of course the backward-compatible packaging would not actually reduce executable sizes, but that's not a problem as long as "programming light" is also possible with clear guidelines)
<flux>
I don't really know why I'm not using Core; if even has all kinds of interesting features I sometimes even would sometimes hope
<flux>
probably the biggest motive is that it would need me to read more documentation :)
<Drup>
(for me, it's just a documentation issue)
<Drup>
core's documentation is really bad
johnelse has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
<gasche>
interestingly, for the early-adopters that want to run bleeding-edge code on bleeding-edge js_of_ocaml versions, OCaml 4.02 module aliases will probably allow us to make Batteries js_of_ocaml compatible without much change in the code structure
<flux>
ocaml 4.02 module aliases?
<Drup>
oh ? how ?
<gasche>
(assuming we have say BatInnerList and BatList, the former not depending on anything js_of_ocaml-bad, we can have module aliases of the form BatList = BatInnerList in a batteries_light.ml and just change "open Batteries" into "open Batteries_light" to be js_of_ocaml-good)
<LawrenceNBestial>
companion_cube, right, so what's the difference between a type constructor of 2 arguments and a type constructor simply taking a tuple as argument?
<LawrenceNBestial>
I assume that in some cases you want to have an ADT which just depends on two types.
<gasche>
would be "module List = BatInnerList" but you got the point
<gasche>
LawrenceNBestial: tuple of types don't exist in OCaml currently
<gasche>
but you can emulate record of types with object types if you want the compactness of a single argument that carries various type information
<companion_cube>
gasche: there is still the unix issue
johnelse has joined #ocaml
<gasche>
iirc. there is just one function hidden somewhere that uses Unix for an ugly hack nobody uses anyway, and which we could probably perform in some other way if we really wanted to
<companion_cube>
and I'm a bit offended by what you say about compatibility; sure I changed some things, but the old behaviors are still more or less the same (enum notwistanding) if you link batteries.full
<gasche>
well
<companion_cube>
gasche: no, the current IO system and BatPervasives rely on IO a lot
<gasche>
all I'm saying is
<companion_cube>
on unix*
<companion_cube>
sorry
<gasche>
let's document the compatibility issues
<gasche>
make effort to reduce them
<gasche>
and then make a backward-compatible release *next week* if we can
<companion_cube>
how can it be backward compatible?
<companion_cube>
(and still be independent from unix)
<gasche>
well
<gasche>
if we have BatInnerFoo and BatFoo modules, just don't make the InnerFoo stuff depend on Unix
<gasche>
also, why is it a design constraint that we must be independent from Unix?
<companion_cube>
because js_of_ocaml?
<companion_cube>
or windows?
<gasche>
if the goal is js_of_ocaml, could we, for example, provide .js implementations of the BatIO stuff instead?
<gasche>
hm
<gasche>
doesn't the Unix stuff we use also work on Windows?
<Drup>
gasche: or do the simple solution, instead of the backward silly one
<gasche>
I would be surprised if that wasn't the case
<Drup>
(aka, just don't use Unix for people that don't need it)
<gasche>
of course
<Drup>
currently, in lilis, all my stack is depending of Unix because I use BatMap.
<Drup>
and it's silly.
<adrien_oww>
ousado: thanks for the notice; I had seen the changes from toots but not from waneck
<Drup>
(I would use a stronger world, but didn't want to hurt your delicate sensibility, gasche :p)
<ousado>
adrien_oww: he added a mac branch
<adrien_oww>
Drup: the word you are looking for is "frustrating" :)
<Drup>
retarded, actually
<adrien_oww>
ousado: but the main remaining issues are not handled in the various forks I've seen
<adrien_oww>
ousado: the most annoying one being the difference in pointer sizesnot being handled
<ousado>
adrien_oww: interesting
<gasche>
well
<gasche>
it's easy to make BatMap not depend on Unix in a backward-compatible way
<gasche>
it only depends on BatInnerIO.output
<ousado>
adrien_oww: I'll ask him if he's aware of them
<Drup>
and Enum, doesn't it ?
waneck has joined #ocaml
<gasche>
we could either break the Map->Enum dep or the Enum->IO dep
<companion_cube>
gasche: if you think it's simpler, please go on
<companion_cube>
gasche: Map also depends on IO because of the printer
<gasche>
possibly by making the ugly record definition public in an internal module, as companion_cube suggested
brainacid has quit [Quit: Leaving]
<ousado>
adrien_oww: are those issues on some bug tracker?
<gasche>
that's not the prettiest thing but it's fairly reasonable
<companion_cube>
or even using objects! yay!
<waneck>
hi adrien_oww ! ousado has told me to join while discussing the cross-compilers
<Drup>
This conversation is not interesting, so I'm going to work instead >_>
<adrien_oww>
hi waneck
<gasche>
companion_cube: it seems that I will have to do the work, indeed
<gasche>
I'm a bit sorry it has to be this way, because I have plenty of things to do already
<companion_cube>
gasche: it's going to be a lot of work imho
<waneck>
he told me you're working to enable cross-compilation on OCaml (the right way ;) ). I'd be glad to help with what I can
<adrien_oww>
ousado: I don't think so; I've been overflown by some of them and the process was to integrate patches as possible and the tasklist was simply the remaining patches
<Drup>
all that for the sake of not using what companion_cube, wou-hou
<Drup>
+did
<adrien_oww>
waneck: yeah, I'm trying to get everything integrated
<adrien_oww>
which has been much more work than expected so far
<gasche>
Drup: of course I'm all for reusing the work
<companion_cube>
gasche: anyway, didn;'t you want to re-write Enum from scratch first?
<gasche>
not necessarily first
<adrien_oww>
something about "technical debt" in the build system...
<adrien_oww>
waneck: one issue I noticed was that it's not possible to build a cross-compiler to a 64b machine from a 32b one and vice-versa
<gasche>
Drup: I don't understand why you're so bitter about this
<adrien_oww>
waneck: apart from that, when was your last update against the OCaml SVN?
<gasche>
I welcome companion_cube's work; as I said *from the start*, it is important that it be presented in a form that is maximally backward-compatible
<adrien_oww>
because you might have to do some extensive rebase of your current patches
<gasche>
if I have to do the work myself I will surely start from his branch
<adrien_oww>
well, if they're a bit old that is
<gasche>
right now I'm working on integrating Benoît Vaugon format+gadts patch in time for 4.02
<gasche>
and next week, I'm in holidays
<waneck>
I did jump into the problem with pointer sizes. Since we have two servers, I ended up building all 32-bit on one server, and all 64-bit on another. However it seems to me that ocaml-mingw already deals with that (supposedly by adding -m32)
<adrien_oww>
well, it avoids the issue then
<waneck>
I added the -m32 flag, but didn't really test afterwards
<adrien_oww>
this one will require some work
<waneck>
yeah, probably. Anyway, my last update was from the 4.0.1 release
<companion_cube>
gasche: and I think I told you it couldn't be 100% compatible
<companion_cube>
and also, everyone I talked to was either ignoring Enum or disgusted by it
<gasche>
I fit in both categories :)
<adrien_oww>
waneck: I think you'll get a lot of work to update to 4.02 :D
<adrien_oww>
waneck: and I'm working on merging Makefile.nt files
<adrien_oww>
which is pretty much done for otherlibs/
<companion_cube>
gasche: well then, what is wrong with preparing a 3.0 release that will remove Enum?
<waneck>
Yeah. Maybe ;) . I actually had started the mac cross-compiler with the latest version - but since it was different from ocaml-mingw I couldn't really use both (my mac cross-compiler and the mingw), so I ended up forking ocaml-mingw and starting from scratch
<adrien_oww>
well, part of the difficulty in merging patches is with the bootstrap of the compiler; it's... "tricky"
studybot has joined #ocaml
<adrien_oww>
f you stay away from that, there's not much point in using what has been merged fro 4.02 so far
studybot_ has joined #ocaml
<gasche>
companion_cube: removing Enum breaks code that works today, and that means users reconsidering their choice
<gasche>
in the long run, it can be the good choice
thomasga has joined #ocaml
<gasche>
but if there is an other way medium-term, it's better
<companion_cube>
gasche: that's why it's called 3.0
johnelse has quit [Read error: Connection reset by peer]
<waneck>
So there has been merged some support for cross-compiling at 4.02 ?
<adrien_oww>
yes and no
<companion_cube>
it would break the linking step anyway
<gasche>
(my understanding of what "careful of backward compatibility" implies is not that we can make releases that break a lot of user's code as often as we want, as soon as we bump the major version number)
tani has joined #ocaml
<companion_cube>
of course not
<companion_cube>
but Enum must die
<adrien_oww>
waneck: some things are in but it's mostly configure, exposing the values in ocamlbuild's config, overall improvements of makefiles, ...
<adrien_oww>
the inability to cross-compile to a target of different bitness is something I have absolutely not touched
divyanshu has quit [Quit: Computer has gone to sleep.]
willb1 has joined #ocaml
<adrien_oww>
at least I should try to have the current stuff merged (mostly for otherlibs/ but it's good to do it in several steps)
tani has quit [Ping timeout: 240 seconds]
<gasche>
so eg. the subproblem "compile from linux-64 to linux-32" is well-defined and orthogonal to the Makefile work?
<adrien_oww>
yup
<adrien_oww>
XL (and chambart) mentionned first-class modules to enable chosing
<waneck>
Okay, I'm afraid the Int64/32 issue would require some knowledge of the ocaml internals I still don't have.
<adrien_oww>
but I can't tell how much it goes deep into the internals of the compiler
<gasche>
probably quite deep
<waneck>
still, if we can make it work with -m32 I guess it would be good enough for a first support
<adrien_oww>
I'll try to make a finer-grained list
<gasche>
but hacking on stuff is a good why to learn about the internals ^^
<adrien_oww>
waneck: I've done something which is limited but worked in practice; I don't think it'd work for haxe though and I believer it's better for you to stay with -m32 currently
<waneck>
yeah, but I don't quite have the time to do it atm. ;) . Most of my open-source time is spent working on the haxe compiler ;)
<adrien_oww>
I'll make a list of other things as soon as I can ;-)
<waneck>
adrien_oww, why wouldn't it work for haxe?
tani has joined #ocaml
<adrien_oww>
because it doesn't handle some things in ocamlopt
<adrien_oww>
and I imagine haxe has more chance of running over these issues than the code I cross-compiled :)
<hcarty>
companion_cube: To be clear, I'm looking forward to seeing your work on Batteries released. My concern is that releasing two versions of Batteries in an official way will make both seem obsolete and/or unstable.
<companion_cube>
hcarty: I understand totally
<waneck>
I see. ;) Yeah, I remember I got something working but ran into some corner cases
<companion_cube>
currently it's going to be on a distinct (unofficial) repo
shinnya has joined #ocaml
<waneck>
okay. I'll start hanging out here too then. adrien_oww , can you ping me when you're done with the Makefile.nt changes and I'll try to work on some patches to the ocaml head
<waneck>
The best way to find the issues is to actually bump into them imho ;)
<adrien_oww>
sure :)
<adrien_oww>
thanks!
<waneck>
no problem! thanks also for the great work with OCaml!
johnelse has quit [Read error: Connection reset by peer]
thomasga has joined #ocaml
ygrek has joined #ocaml
saml has joined #ocaml
darkf has quit [Quit: Leaving]
rgrinberg has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
<Drup>
hcarty, gasche : since both of you are there
<Drup>
is my patch for inlining (concat.map) is going to merge one day ? :x
<companion_cube>
hmmm ^^
divyanshu has joined #ocaml
<Drup>
too much verbs in this sentence :(
zpe has quit [Ping timeout: 252 seconds]
arquebus has joined #ocaml
<gasche>
Drup: why not
<gasche>
you should have provided tests for Stream.concat_map
<gasche>
Drup: do you have any idea why your benchmarks show an improvement in performances of Seq while the patch doesn't touch it?
<Drup>
not really. Raw numbers in benchmarks are not very trustworthy. Either you make stuff run at the same moment, or it's meaningless. Especially with different binaries. That's why I provided Seq here, so that it can be used as a baseline
<gasche>
well
<gasche>
in absolute number Seq consistently improves *more* than Enum in your benchmark
<Drup>
gasche: you have read the paper about the influence of padding some stuff in source file for performances, don't you ?
<gasche>
did we really measure a speedup for Enum, or do the particular test setting improve them both by some constant factor?
<gasche>
I have
<gasche>
in this case I would rather bet on the Stream tests trashing the GC and making everything else slower
<Drup>
the benchmark packages trigger GC between the run, afair
<gasche>
I have a bad gut feeling about making existing code more complex (in already complex-enough modules) because of a flawed measurement
<gasche>
but in this case it's indeed not very hard to visually check that the code really is a copy-paste of the concat code, which makes it trustworthy
<gasche>
(assuming there are no human errors that the absence of tests will not catch)
<Drup>
you're welcome to git pull lilis, get all the dependencies and run the benchmark with and without the modify versions
<ggole>
Benchmarking accurately is damn hard :(
<Drup>
it's trivial to do
<gasche>
so the right move is probably to merge the patch, suspecting that it makes little difference in performance, to make you a tiny bit happier
<Drup>
:)
<Drup>
well, either merge it or close it. It's just the fact that it's hanging around unresolved that bother me.
<Drup>
I have the version in lilis for both anyway
avsm has joined #ocaml
<gasche>
Drup: are you positive that you observed a speed difference after the patch?
<gasche>
(I mean not only in this one benchmark)
<Drup>
yes
<Drup>
it's not only the case for those two, by the way
<gasche>
done
<Drup>
manually inlining (concat.map) *always* provide a speedup by *1.2 to *2
<Drup>
(I was a bit surprised too at first)
<Drup>
thx
arquebus has quit [Quit: Konversation terminated!]
* Kakadu
knows from now what can be worse that programming in C
<companion_cube>
programming in C hand-tighted in the dark?
johnelse has joined #ocaml
<Kakadu>
companion_cube: programming in C hand-tighted in the dark on VirtualBox with Windows with Visual C++ 6 (i.e. C89)
<companion_cube>
hmmmmmmmmmmmm
<flux>
c++89 ;)
<Kakadu>
Obviously it doesn't support C99 because VC6 is 16 years old
pyon is now known as pyon-visualbasic
<companion_cube>
because microsoft doesn't like C99
<ggole>
More recent versions don't support C99 either
<companion_cube>
so it decides to stop at C89
<ggole>
They added a few bits recently, or something.
<adrien_oww>
Kakadu: I've been doing Visual Basic in notepad in a VM recently
wwilly has joined #ocaml
<wwilly>
yop
shinnya has quit [Ping timeout: 245 seconds]
divyanshu has quit [Ping timeout: 252 seconds]
pyon-visualbasic has quit [Quit: restart]
divyanshu has joined #ocaml
maattdd has joined #ocaml
pyon-vb6 has joined #ocaml
tani has quit [Ping timeout: 276 seconds]
LawrenceNBestial has left #ocaml []
avsm has quit [Quit: Leaving.]
keen__ has joined #ocaml
keen_ has quit [Ping timeout: 240 seconds]
keen__ has quit [Ping timeout: 240 seconds]
lostcuaz has joined #ocaml
avsm has joined #ocaml
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
keen__ has joined #ocaml
<companion_cube>
gasche: don't worry about concat_map, it's a useful function in its own
lordkryss has quit [Disconnected by services]
tane has joined #ocaml
tani has joined #ocaml
keen___ has joined #ocaml
tane has quit [Ping timeout: 258 seconds]
nikki93 has quit [Remote host closed the connection]
nikki93 has joined #ocaml
keen__ has quit [Ping timeout: 252 seconds]
zpe has joined #ocaml
nikki93 has quit []
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
Hannibal_Smith has joined #ocaml
araujo has joined #ocaml
araujo has quit [Changing host]
araujo has joined #ocaml
maattdd has quit [Ping timeout: 250 seconds]
tlockney_away is now known as tlockney
Guest1278 is now known as tianon
jwatzman|work has joined #ocaml
yacks has quit [Ping timeout: 240 seconds]
keen___ has quit [Ping timeout: 276 seconds]
avsm has quit [Quit: Leaving.]
lostcuaz has joined #ocaml
ta`e has joined #ocaml
keen___ has joined #ocaml
tani has quit [Ping timeout: 258 seconds]
malo has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
Thooms has quit [Quit: WeeChat 0.3.8]
rand000 has joined #ocaml
michel_mno is now known as michel_mno_afk
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
sgnb has quit [Ping timeout: 240 seconds]
Kakadu has quit [Quit: Page closed]
q66 has joined #ocaml
q66 has quit [Changing host]
q66 has joined #ocaml
zzing has joined #ocaml
Thooms has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
rgrinberg has joined #ocaml
q66 has quit [Ping timeout: 252 seconds]
AltGr has left #ocaml []
q66 has joined #ocaml
q66 has quit [Changing host]
q66 has joined #ocaml
thomasga has quit [Quit: Leaving.]
tani has joined #ocaml
ta`e has quit [Ping timeout: 245 seconds]
Kakadu has joined #ocaml
Rota has quit [Ping timeout: 258 seconds]
marcux has joined #ocaml
zzing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Rota has joined #ocaml
maattdd has joined #ocaml
zpe has joined #ocaml
waneck_ has joined #ocaml
thomasga has joined #ocaml
waneck has quit [Ping timeout: 240 seconds]
zpe has quit [Ping timeout: 258 seconds]
coke0 has quit [Ping timeout: 258 seconds]
samebchase has joined #ocaml
NoNNaN has joined #ocaml
zzing has joined #ocaml
zzing has quit [Client Quit]
oriba has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
lostcuaz has quit [Ping timeout: 250 seconds]
lostcuaz has joined #ocaml
lostcuaz has quit [Read error: Connection reset by peer]
lostcuaz has joined #ocaml
Thooms has quit [Ping timeout: 245 seconds]
maattdd has quit [Ping timeout: 252 seconds]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
avsm has joined #ocaml
Thooms has joined #ocaml
thomasga has quit [Quit: Leaving.]
n0v has quit [Ping timeout: 246 seconds]
n0v has joined #ocaml
maattdd has joined #ocaml
divyanshu has quit [Quit: Computer has gone to sleep.]
Hannibal_Smith has quit [Quit: Sto andando via]
steshaw has joined #ocaml
claudiuc_ has joined #ocaml
steshaw has quit [Client Quit]
NoNNaN has quit [Remote host closed the connection]
dodo has joined #ocaml
<dodo>
Hi
<dodo>
if i try Printf.printf "%F" float_of_int(1)/.float_of_int(2);; it gives me a type error
<dodo>
what's wrong ?
<dodo>
float_of_int(1)/.float_of_int(2) is indeed a float
<mrvn>
It helps to paste stuff that actually compiles
<dodo>
bureaux array is over 10 megabytes.
<mrvn>
anyway, for loops always return unit
<dodo>
in filesize.
<mrvn>
then make a smaller sample case
<mrvn>
It also helps to use english variable names and texts.
<dodo>
hey what's wrong with you ?
<mrvn>
just saying.
<dodo>
do you hate french ?
<mrvn>
I don't understand french
<dodo>
i won't translate my code just for the purpose of one guy
<dodo>
you are obviously trolling
<companion_cube>
wat
<companion_cube>
dodo: this is an english-speaking channel, so you shouldn't expect people to know french
<mrvn>
dodo: suite yourself. you are seriously decreasing the pool of people able and willing to help.
<dodo>
you don't need to know french here.
<dodo>
it's just variable and function nom
nicoo has quit [Ping timeout: 255 seconds]
<dodo>
name
<dodo>
you can remplace them to any you want
<mrvn>
good variable names go a long way towards understanding code.
<dodo>
Drup did you found any problems releving from that strange bug ?
<mrvn>
what bug exactly?
ggole has quit []
ollehar has joined #ocaml
<dodo>
the unit return tells exactly than the ;; has been reached
<mrvn>
because the result of a for is unit
<dodo>
so i don't think it's coming from my code
thomasga has joined #ocaml
<mrvn>
That it ends with unit is correct. That's what you wrote. So what is the bug? What did you intend to do?
<dodo>
re read
<dodo>
don't skip the whole talk
<dodo>
=)
<dodo>
or maybe you've joined early
<dodo>
you were here sorry
nicoo has joined #ocaml
<mrvn>
or you got disconnected and your problem never made it to the channel. Because you only mentioned 2 problems, the type error on printf and returning unit.
<dodo>
well let's try switching over the linux version
<Drup>
mrvn: and the hanging
<mrvn>
Drup: which wasn't hanging, only retunring unit it seems
<dodo>
yeah it hangs after the return
<mrvn>
after line 37?
<dodo>
yes
<mrvn>
can't be
<dodo>
it is
<mrvn>
Line 37 defines a function. It doesn't compute anything.
<dodo>
oh really ?
<dodo>
well, thanks captain obvious
<dodo>
anyways, just gonna using linux over vmware
<Drup>
dodo: in general, developing ocaml is far far easier under linux/mac
manizzle has joined #ocaml
<mrvn>
dodo: You should probably forget about "for" and do this recursive. Functional, you know. Array.fold_left comes in handy for this.
<mrvn>
refs are rather slow in ocaml.
<dodo>
you might be absolutely right
<dodo>
but i can't, didn't studied it yet.
<dodo>
i can't use a thing that i've never seen before
<companion_cube>
mrvn: ref come at a cost, but they're still pretty fast, aren't they?
<mrvn>
have you done normal recursion?
<dodo>
no.
<companion_cube>
I don't think the write barrier is so costly
Kakadu has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 240 seconds]
thomasga has joined #ocaml
tani has quit [Quit: Verlassend]
dodo has left #ocaml []
steshaw has joined #ocaml
thomasga has quit [Quit: Leaving.]
avsm has quit [Quit: Leaving.]
Simn has quit [Quit: Leaving]
tlockney is now known as tlockney_away
tlockney_away is now known as tlockney
Thooms has quit [Quit: WeeChat 0.3.8]
rand000 has quit [Ping timeout: 258 seconds]
rand000 has joined #ocaml
oriba has quit [Quit: oriba]
steshaw has quit [Quit: Leaving.]
shinnya has joined #ocaml
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rand000 has quit [Quit: leaving]
maattdd has quit [Ping timeout: 245 seconds]
tautologico has joined #ocaml
Rota has quit [Ping timeout: 258 seconds]
alephlambda has joined #ocaml
WraithM has quit [Ping timeout: 252 seconds]
darkf has joined #ocaml
thomasga has joined #ocaml
<alephlambda>
Hi, I'm a student working with OCaml. I'm using `input_line` to read lines from a file. One of the lines is "hello world\n", with the "\n" being a "\" followed by a "n". This works great for reading in the file, but I want to print out the string with the "\n" being interpreted as a newline. How do I do this?
<alephlambda>
`printf "%s" my_string` didn't seem to work.
<whitequark>
alephlambda: try String.unescaped
adrien_o1w has joined #ocaml
<alephlambda>
whitequark: When reading it in or when printing?
<whitequark>
well, how do you want to store?
<whitequark>
store it
nuki has joined #ocaml
<alephlambda>
whitequark: I think I want to store with the "\n" interpreted since I also have to do substrings. I checked the documentation. Did you mean Scanf.unescaped?
adrien_oww has quit [Ping timeout: 240 seconds]
<whitequark>
er, yes
<alephlambda>
whitequark: Wait, sorry. I want to store it with the "\n" as two characters. This is for a classroom programming language and I was forgetting that how the strings are stored.
<alephlambda>
whitequark: So, I want it when printing.
<tautologico>
you can scan the string after reading and substitute the \n character with characters '\' and 'n'
<alephlambda>
tautologico: True. I'll keep that in mind. That may turn out to be easier down the line.
<alephlambda>
whitequark, tautologico: For now, whitequarks suggestion of `Scanf.unescaped` is producing the desired behavior.
<tautologico>
whitequark: you planning on adding support to ocp-indent to the ocaml sublime package? :)
madroach has quit [Ping timeout: 252 seconds]
<whitequark>
tautologico: um, not really, I indent my code myself
<whitequark>
but I'll happily accept a PR
inr has quit [Ping timeout: 245 seconds]
madroach has joined #ocaml
inr has joined #ocaml
<tautologico>
unfortunately I have no idea about sublime plugin development
NoNNaN has quit [Remote host closed the connection]
nuki has quit [Ping timeout: 252 seconds]
NoNNaN has joined #ocaml
<whitequark>
tautologico: take a look at sublime-ocp-index source, it already has all the basic parts--registering a hotkey, invoking an external program and capturing the output
<whitequark>
you can ask me for details, I'll help
<tautologico>
code completion and type feedback would be nice to have
<whitequark>
type feedback already exists, Alt+a
inr has quit [Ping timeout: 245 seconds]
<whitequark>
er, code completion too? that's the point of sublime-ocp-index
thomasga has quit [Quit: Leaving.]
<tautologico>
alt+a on windows/linux? this doesn't seem to work here on OS X?