<Leonidas>
Async Pipe is a really verbose way to simulate lazy lists
<Drup>
Leonidas: and a very bad way, especially since Lazylist is in Core
<Drup>
or maybe not
<Drup>
weird, I remember it
<Drup>
well, there is Core_kernel.Sequence (which is different from companion_cube's sequence)
<Leonidas>
Drup: I was very confused, since I couldn't find it
vanila has quit [Quit: Leaving]
<Leonidas>
but I'm not using the newest docs
<Drup>
(actually, it's pretty similar)
<Leonidas>
yes, looks good
<Drup>
I find sequence nicer
bytbox has quit [Ping timeout: 245 seconds]
<Leonidas>
I'm already using Core in that program, might as well.
<Drup>
using core doesn't prevent using the rest of the world
<Leonidas>
yes, but introducing another dependency when the library I am using provides a decent enough implementation on its own is rather pointless :-)
<Leonidas>
rewrote the code with Sequence, much saner, nice
govg has quit [Quit: leaving]
psy_ has quit [Ping timeout: 265 seconds]
<struktured>
Leonidas: nice! can I see that?
reem has joined #ocaml
antkong has joined #ocaml
<Leonidas>
struktured: what exactly?
<struktured>
Leonidas: the aformentioned rewrite w/sequence, if you can link to source?
<Leonidas>
let's see how many coreutils there are in total :-)
<dmbaturin>
(number of BSD forks in existence) + epsilon
<Leonidas>
ocaml nproc would be print_endline "1" ;)
<dmbaturin>
Speaking of which, is there a good explanation of the runtime lock anywhere?
<dmbaturin>
What exactly gets giant locked and what does not.
Simn has quit [Quit: Leaving]
<struktured>
Leonidas: I couldn't get async parallel working on multiple servers :(
<whitequark>
the lock must be held while ocaml code is executing. it is force-released when thread switching by SIGVTALRM. it is also released around unix calls, allowing the threads to switch as well
cateches has joined #ocaml
<cateches>
can anyone here help with cohttp issues?
<Leonidas>
struktured: this would've been local :-)
<cateches>
and I run run `curl -X POST -d 'foo bar' http://localhost:8080` and it posts, but as soon as I try to hit it with ab, I get apr_socket_recv: Connection refused (61)
<cateches>
100% of the time
<struktured>
Leonidas: that I got working which did get me psyched up for a bit
<cateches>
and then a minute later, the whole process dies with a huge stacktrace
<cateches>
nvm, I think this is an ab bug
<cateches>
I don't get this issue with wrk
cateches has quit [Quit: Page closed]
travisbrady has joined #ocaml
yomimono has quit [Ping timeout: 246 seconds]
antkong has quit [Quit: antkong]
thomasga has quit [Quit: Leaving.]
MrScout has quit [Ping timeout: 250 seconds]
captain_furious has quit [Ping timeout: 244 seconds]
<jpdeplaix>
whitequark: is it normal that the private linkage semantics when linked has changed in 3.6 ?
ghostpl_ has quit [Remote host closed the connection]
<jpdeplaix>
if I have one module with only private functions and globals, they are not added anymore to the other module when linked with it
reem has joined #ocaml
travisbrady has quit [Quit: travisbrady]
reem has quit [Remote host closed the connection]
huza has joined #ocaml
jao has quit [Ping timeout: 252 seconds]
Thooms has quit [Quit: WeeChat 1.0.1]
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bytbox has joined #ocaml
yaewa has quit [Quit: Leaving...]
moei has joined #ocaml
travisbrady has joined #ocaml
darkf has joined #ocaml
lordkryss has quit [Quit: Connection closed for inactivity]
<whitequark>
ask on #llvm i think
<whitequark>
it's certainly possible
deMoivre has joined #ocaml
hilquias has joined #ocaml
<deMoivre>
The first three lines of my function are:
<deMoivre>
let rec mandelbrot (sextuple : float * float * float * float * int * string) : (float * float * float * float * int * string) =
<deMoivre>
let (cre, cim, zre, zim, its, retChar) = sextuple in
<deMoivre>
let (magn: float) = (zre * zre + zim * zim) in
<deMoivre>
And it's throwing an error on compilation at "zre" on the 3rd line
<deMoivre>
why?
<deMoivre>
it says Error: This expression has type float but an expression was expected of type
<deMoivre>
int
ollehar1 has quit [Remote host closed the connection]
<dmbaturin>
deMoivre: Because * is not overloaded, it's int -> int -> int.
<dmbaturin>
Use *. for floats.
<dmbaturin>
+ isn't overloaded either.
<deMoivre>
OH.
* deMoivre
corrects...
<deMoivre>
I think we've got something =)
<deMoivre>
Thank you!
yaewa has joined #ocaml
moei has quit [Ping timeout: 255 seconds]
swgillespie has joined #ocaml
<struktured>
deMoivre: it's classic ocaml gotcha, due to ultrastrict type system
<struktured>
deMoivre: also, you might want to use labeled arguments and/or records for tuples that complex and with the repeated types of same value
<dmbaturin>
Ultra-violent type system. ;)
<dmbaturin>
But yeah, there is no overloading whatsoever (on the other hand there is no need for type signatures either).
antkong has joined #ocaml
travisbrady has quit [Quit: travisbrady]
<deMoivre>
Great job, guys
<deMoivre>
I'll post the link to my bitbucket repo for this in a minute
<dmbaturin>
Does it produce pretty pictures?
reem has joined #ocaml
yminsky has joined #ocaml
olauzon has quit [Quit: olauzon]
<deMoivre>
in ASCII, yes
<deMoivre>
it's just a benchmark that I've been implementing in lots of languages to compare runtime performance for basic operations
<deMoivre>
So far, I've ported it to Java, C++, Fortran, Ada, Go, Haskell, and now OCaml
<struktured>
deMoivre: sweet, mandelbrot's spirit lives on
<deMoivre>
in a chain of recursive function calls in OCaml, what's the expected difference between defining the function as taking in a tuple vs currying?
<dmbaturin>
There should be very little difference.
<deMoivre>
I wonder why my OCaml code is benchmarking at 2m24s
<deMoivre>
instead of in the neighborhood of 9s as my very similar Haskell code does
<dmbaturin>
The most imperative ocaml I've ever seen. :)
reem_ has joined #ocaml
<deMoivre>
heh
<deMoivre>
yeah yeah
<dmbaturin>
Why in von Numan's sake you'd add autogenerated .s and the .ali to an Ada source repository?
<dmbaturin>
* Neuman's
<deMoivre>
dmbaturin: paranoia
<deMoivre>
I couldn't remember offhand which files were important or if there'd be anything worth looking at again later
<dmbaturin>
They'll be overwritten on rebuild anyway.
<sheijk>
or deployment/dependencies on tools
<dmbaturin>
Well, autogenerated stuff is rarely worth adding to a repo.
<yminsky>
I just built it on my laptop. It ran in 9s.
<deMoivre>
yminsky: My OCaml code?
<yminsky>
How did you compile it?
<yminsky>
Yup.
<deMoivre>
How did you compile it?
<yminsky>
ocamlc or ocamlopt?
<deMoivre>
I just ran it with ocamlc with no parameters
<yminsky>
Oh. Yeah, that’s the bytecode compiler.
<yminsky>
Try native code.
<deMoivre>
huh.
<yminsky>
Just “ocamlopt foo.ml -o foo”
<deMoivre>
I guess their bytecode compiler is nowhere near as quick as Java's Hotspot
<deMoivre>
ok
Algebr has quit [Ping timeout: 252 seconds]
<yminsky>
bytecode is portable, but not built for speed. Java bytecode is the only target they have, and there’s a JIT madly compiling to native code.
<deMoivre>
right
<deMoivre>
ahhhh
<deMoivre>
7.416s
<deMoivre>
NOT BAD
<deMoivre>
Not bad, at all
<deMoivre>
Java is around 9, Go is around 4.5
<yminsky>
FWIW, the code looks a little strange. Certianly, currying (and naming variables) is more normal.
<deMoivre>
C is about 4.1
antkong has quit [Ping timeout: 272 seconds]
<deMoivre>
Haskell is around 9.6, I think
<deMoivre>
yminsky: Yes...I'm working on a currying version right now as we speakj
<deMoivre>
-j
<deMoivre>
I was aware of the same thing in Haskell
<dmbaturin>
deMoivre: Well, it was never meant to be. The bytecode compiler is the last resort for architectures with no native compiler yet, the bootstrap tool, and a debug aid (the REPL uses bytecode libraries).
<deMoivre>
it's more idiomatic to use currying than tuples in that language as well
<deMoivre>
Also --
reem_ has quit [Ping timeout: 265 seconds]
<tokenrove>
deMoivre: be sure to try SML with MLton, too
<deMoivre>
The text output is all occuring at the very end of the computation
<deMoivre>
Is there a way to make it output in the middle?
<deMoivre>
as it's computing?
<yminsky>
Sure. You can call print_string whenever you want.
<deMoivre>
I am
<tokenrove>
deMoivre: be sure to flush your output.
<deMoivre>
and it's only *Actually*...
<deMoivre>
ahhh
* deMoivre
looks that up
<tokenrove>
flush stdout
<deMoivre>
ok
<deMoivre>
in Haskell, a different print function did that flushing for me
<dmbaturin>
I wonder if MLton solves currying efficiency problems that made SML authors use tuples all over the standard library.
<yminsky>
I also note you’re not using OCaml’s Complex module. That might make for cleaner, shorter code. Not sure about the performance.
<deMoivre>
right
<deMoivre>
I'm choosing not to use any complex numbers explicitly in any of these programs
<deMoivre>
because it's not always available in a given language
<deMoivre>
I'm trying to make the code be as directly comparable as possible between languages
<deMoivre>
yminsky: Yes; I've already looked at that page. Thank you, though. =)
badon has quit [Quit: Leaving]
<deMoivre>
tokenrove: that flush studout didn't seem to do the trick
<tokenrove>
deMoivre: after each print_string?
<yminsky>
Works for me.
<yminsky>
Just put “flush stdout” right after the print_string line (after a semicolon)
<deMoivre>
right
<tokenrove>
i'm not sure that forcing every language to use the same approach to the problem makes for useful comparisons.
<deMoivre>
after a semicolon...
<deMoivre>
hmm
<deMoivre>
tokenrove: I'm going to construct alternative versions where I try to accomplish the task in as little time as possible, no matter how it's implemented in each language
<deMoivre>
because I agree in a sense =)
<tokenrove>
as soon as you do your 6502 assembly and brainfuck implementations of the problem, you'll have to downgrade all the others to use fixed point arithmetic or worse.
<deMoivre>
heh
<tokenrove>
jon harrop, the author of that aforementioned mandelbrot page, went on a "compare all the languages" crusade for a while, too. i don't know if you looked at his raytracer stuff.
<sheijk>
hm. don't benchmark stuff which prints unless you want to benchmark the io libraries
<deMoivre>
tokenrove: Not yet.
<deMoivre>
sheijk: The I/O is an insignificant contribution to this
<deMoivre>
That's why I ramped the iteration limit to 1000000
<deMoivre>
to ensure that
<sheijk>
ah, ok
<deMoivre>
AHHHHHHHhhhhhhhh
<deMoivre>
perfect!!
reem has joined #ocaml
<yminsky>
I made a few trivial syntactic transformations to your code to clean it up.
<deMoivre>
but I now know enough about how to implement a nice little recursive function in the total absense of imperative style loops in order to do it
badon has joined #ocaml
reem has quit [Ping timeout: 265 seconds]
<deMoivre>
I implemented my own 'for' idiom via a function in Scheme, at least
<yminsky>
I’m sad to see him using polymorphic variants everywhere.
<yminsky>
Better to coordinate. For example, we’d be happy to break out our Result.t into a tiny module that could be shared amongst many users.
monod has quit [Ping timeout: 256 seconds]
<companion_cube>
it's a bit too late - would be ok if it was in the stdlib though
<companion_cube>
(trolling on both irc and twitter, nice)
<yminsky>
Polymorphic variants are complex, and the type discipline around them is error prone. Now that we have type-directed constructor disambiguation, I mostly prefer ordinary variants.
<yminsky>
Hey, you asked.
<companion_cube>
^^
<yminsky>
I thought this would be a more useful place to chat.
<companion_cube>
indeed
<yminsky>
Why too late?
<yminsky>
Isn’t Bos new?
<companion_cube>
I mean, for Result.t
<yminsky>
Why too late?
<companion_cube>
if eeryone agreed on it 10 years ago, it would be cool
<yminsky>
We could factor it out to a tiny library now.
<yminsky>
Huh? We can do it now. We can add it to the stdlib now. There’s no barrier.
reem has joined #ocaml
<yminsky>
If there was an existing Result.t, with the same definition that anyone defined, we could all share it.
<yminsky>
This is similar to Sexplib. Core_kernel uses Sexplib’s Sexp.t, and integrates it into its core-like view of the world. But you can use Sexplib on its own.
<yminsky>
Anyway, I’ll email bunzli and see what he thinks.
<bernardofpc>
I am especially boggled by Bos.Path.ext
reem has quit [Remote host closed the connection]
<companion_cube>
it's still big imho (Sexplib)
<companion_cube>
would be nice to have just the type def somewhere
<companion_cube>
poly variants are nice because they don't force you to have a common dep just to talk about the same type
<tane>
i noticed d.b. using a lot of polymorphic variants and wondered if there is any point why he's doing that? any ideas?
<ia0>
the common dep does not look like a good argument for poly variants
<companion_cube>
because all his projects use the same definition for errors, but they don't have dependencies (in general)
<ia0>
this is a architecture design problem
<companion_cube>
ia0: if there was another way, I'd use it
<companion_cube>
the point is, I don't want to depend on Core (or batteries) just for their definition of Result
<companion_cube>
(which is incompatible anyway)
<ia0>
you may split type definitions from function definitions
<companion_cube>
sure
<companion_cube>
if people did that, it would be neat
<companion_cube>
or if OCaml had a way to have some structural typing with regular variants
<ia0>
the only "good" point I see for poly variants is the fact that it's an open type
<companion_cube>
(meaning: types that are isomorphic can be converted)
<companion_cube>
open and structural, yes
<ia0>
what do you mean by structural?
<companion_cube>
two definitions of the "same" type are equivalent
<companion_cube>
I write type 'a or_error = [`Ok of 'a | `Error of string]
<companion_cube>
Bünzli writes type 'a result = [`Error of string | `Ok of 'a] (say)
<companion_cube>
those are the same type
<yminsky>
I agree that Sexplib isn’t tiny.
<yminsky>
But it shows the principle.
<companion_cube>
yminsky: why not make a proposal on caml-list for exporting types?
<companion_cube>
like, opam packages named "ty-foo"
<companion_cube>
that only contain type definition(s)
<yminsky>
One could break out just the type definition if you had a type definition worth sharing.
<companion_cube>
very simple and ligthweigth dependencies
<companion_cube>
yes
<companion_cube>
that would be very interesting, or at least worhty of discussion
<yminsky>
Indeed. I’m curious to see what I hear back from Daniel.
<yminsky>
It’s worth noting that there aren’t a lot of types that this is an obvious win for. And maybe we should just put all the ones we want in the standard lib.
<yminsky>
Other than Result.t, and maybe Sexp.t, I see on obvious suggestions from the Core world.
<companion_cube>
well, UChar seems to have troubles being included
<companion_cube>
why not Core.Sequence? (although I have my own iterators)
<companion_cube>
I see, for instance: Result, Sexp, UChar, LazyList, Core.Sequence, some UTF8 string, some UTF8 rope...
<yminsky>
The UTF8 ones seem good. I’m less convinced about Core.Sequence.
<yminsky>
I like the fact that the type there is abstract, and this only makes sense for non-abstract types.
larhat has joined #ocaml
segmond has quit [Ping timeout: 246 seconds]
<companion_cube>
maybe so
<companion_cube>
it's harder for external code to define iterators then, but ok
A1977494 has quit [Quit: Page closed]
SkoAleVal has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.32.1/20150204202218]]
<yminsky>
Sure, there’s a tradeoff there.
larhat has quit [Quit: Leaving.]
bytbox has joined #ocaml
<tokenrove>
yminsky: i'm not sure if you're the right person to ask, but is there any interest in getting jenga working on windows?
<yminsky>
Eventually I’d like to get Jenga and Async working on Windows.
<yminsky>
But it will take time. The next version of Async_kernel doesn’t depend on Core anymore (just Core_kernel), so it should be portable.
<yminsky>
We’ll need some work to write a scheduler based on libuv or something like that to get Windows to happen. I don’t think we’ll do that work intenrally at JS, but I’m hoping we can get it to happen.
<tokenrove>
so Async's portability is a problem for porting Jenga right now?
<yminsky>
Indeed. Jenga uses Async internally.
<yminsky>
But Jenga can generate makefiles which are portable.
<yminsky>
So if you use Jenga, you should be able to create packages that build anywhere.
<tokenrove>
well, i only just started looking at it yesterday, but i might have an opportunity to hack on it next month. i had counted on having to reimplement stuff like inotify but i didn't think about Async.
<yminsky>
But it’s not good for development on Windows.
<yminsky>
Well, Async_kernel will run on Windows in the next release...
<tokenrove>
ok, maybe i should just wait and see what happens, then
<yminsky>
But really, Jenga is not yet in a state where we can recommend it for external use.
<yminsky>
It’s absolutely great for our use, but we haven’t yet done enough to make it suitable for other people’s workflows.
segmond has joined #ocaml
<prsn>
hi! I'm having trouble getting the Tuareg repl set up in the same namespace as the project I'm working with. #load-ing each file sort of works, but there are dozens
<Drup>
(13:20:28) yminsky: Better to coordinate. For example, we’d be happy to break out our Result.t into a tiny module that could be shared amongst many users. <- for once, I agree with you yminsky :D
<prsn>
and they also depend on installed libraries outside the project directory which would be annoying to track down
<yminsky>
Drup: For once? What are the other terrible things I say?
vanila has joined #ocaml
<Drup>
oh, I just don't agree with Core and Async architecture in general
<prsn>
i feel like I should be able to just point to .. something .. and have it load everything needed recursively? Is that possible?
idem-pyon-tent has quit [Quit: I'm sorry but... I don't have any interest in three-dimensional girls.]
<Drup>
and the way jst tends to interact (library wise) with the rest of the community
<Drup>
but on the whole "let's use structural types to be compatible between various libraries", I think it's just show a terrible lack of synchronisation (and a terrible amount of NIH) from the various people in the community
<yminsky>
Well, not liking Core’s design is fine. Design is a thing about which opinions will differ.
segmond has quit [Ping timeout: 246 seconds]
<Drup>
sure
<Drup>
but one thing has been proven about monolithic libraries in the ocaml ecosystem: parts of them are reinvented elsewhere, not always better, but at the end the smaller part is usually used because it's not enormous
<companion_cube>
the compatibility-through-structural-types wouldn't have happened if the stdlib had accepted those types
<companion_cube>
and only the types
tnguyen has quit [Read error: Connection reset by peer]
<yminsky>
Maybe. Lwt is pretty big, but is used in lots of places.
<companion_cube>
is it that big?
tnguyen has joined #ocaml
<Drup>
it's smaller than async.
<yminsky>
And Core is getting smaller in the next release. With module alises, you no longer need to link in the whole thing.
<Drup>
(examples includes ocamlnet - eliom - cohttp/uri/etc)
slash^ has quit [Read error: Connection reset by peer]
<yminsky>
That should come in the next release or two.
<Drup>
(Core - basilions of litte things everywhere, cmdliner for example)
<companion_cube>
lwt.cma weights 372kB here, that's not big
slash^ has joined #ocaml
<Drup>
(eliom - opium, in a certain extend, is another example)
<yminsky>
There’s no question that Core_kernel is bigger than those other things. But increasingly, you’ll be able to link in only the parts you actually want to use.
<Drup>
sure, the point is that people keep redoing things between using just one thing that is part of Core is too costly if you don't use Core already
<yminsky>
It’s still not perfect: there are some pieces that are hard to avoid, like Result.t, Error.t, Sexp.t, etc, since lots of basic things use them.
<companion_cube>
unless you have a quasi-flat dependency graph, that won't happen with current ocaml
<Drup>
s/between/because/
<Drup>
(and Error/Result should be in a small independent library)
<yminsky>
I agree that Core_kernel is a bit of a take-it-or-leave-it experience. But I think there’s a lot of value if you do take it.
<Drup>
(said library was already done, btw, by smondet)
<yminsky>
Which library?
<Drup>
let me find you the name
<companion_cube>
yminsky: there's the part of the ecosystem that uses core, and the part that doesn't, and the divide is pretty clear
<companion_cube>
Drup: I still think there should be a lib (or a stdlib module) with only the type def
<companion_cube>
so you don't have to like the lib interface to use it
<Drup>
companion_cube: for error and result, having the whole thing is fine, there is basically nothing opiniated in the library
<yminsky>
For exposed types, like Result.t, this works.
<yminsky>
For abstract types, like Error.t, it can't.
<Drup>
yes, it keeps using polyvariants for your famous compatibility issue
<yminsky>
I thing breaking out Result.t to share it amongst multiple libraries that want it is a lovely idea, assuming someone else would be willing to share.
<Drup>
(basically, because dbunzli's lib)
monod has joined #ocaml
<Drup>
yminsky: I think it's slightly to late for Result.t
<companion_cube>
yminsky: I think this discussion should happen on caml-list: you want to have the opinions of Bünzli, smondet, {core,batteries}-{users,developpers}, and so on
<Drup>
well, maybe not actually
<Drup>
the main one that would need to change things is bunzli
<companion_cube>
the others would have to replace type 'a result = .... with type 'a result = 'a Result.t = ....
<companion_cube>
or something like this
<companion_cube>
which is pretty ok
<yminsky>
Indeed.
<Drup>
yep
<companion_cube>
I would have to change things too :>
<yminsky>
I emailed Bunzli.
<Drup>
(Batteries uses Ok | Bad
<Drup>
:/
<companion_cube>
arf
<companion_cube>
dooooooomed by retrocompat.
<Drup>
as always in batteries
<yminsky>
Right. To the degree that people like [type (‘a,’b) t = Ok of ‘a | Error of ‘b], we can share.
<yminsky>
But otherwise, not so much.
<Drup>
companion_cube: you would have to change containers too
<companion_cube>
I can manage the transition from poly variants with sed
<companion_cube>
yes, that's why I said I had to change things too
<Drup>
it's not about you, it's about users :p
<ia0>
:-)
<companion_cube>
users include me! :p
<Drup>
but are not limited to.
segmond has joined #ocaml
<companion_cube>
well, that would be a major release, sure
<yminsky>
Containers is still pretty young, and OCaml makes this kind of refactoring pretty easy.
<companion_cube>
also, same thing with S-expressions
<Drup>
yminsky: what's the plan for ppx ?
<companion_cube>
yes yes, I'm not afraid to break a bit of compat when it makes sense to
<yminsky>
Sure, if folks wanted to share the core s-expression type without sexplib, that’s doable too.
<yminsky>
drup: we’re actively working on converting all of our syntax extensions to ppx.
<Drup>
well, it will be necessary for any ppx_sexp.
<yminsky>
We’re going to drop camlp4 like a hot rock.
<companion_cube>
I'd be interested, I have an alternative streaming parser for S-epxressions
psy_ has quit [Ping timeout: 272 seconds]
<companion_cube>
(that I'm probably the only one to use)
<yminsky>
The old syntax extensions will still work, but we won’t use them.
<Drup>
yminsky: are you using ppx_deriving ?
<Drup>
(please do, please do, please do)
<Drup>
(for the community's sake, please do)
<yminsky>
Not clear yet. Jeremie Dimino has had some back and forth with whitequark.
<yminsky>
If the design works, we’d like to share it. But it may not be a match.
<Drup>
then modify ppx_deriving
<ggole>
How did camlp4 ever get to the state its in? Vast, undocumented, and relied on are a bad combination.
<yminsky>
The early design definitely wasn’t a good match, but some things have improved.
<yminsky>
camlp4 provided absolutely critical functionality. There were no alternatives.
<Drup>
and it was good enough to work
<ggole>
I suppose that paring down to the necessary parts and documenting everything was never going to happen
<Drup>
yminsky: having two library for deriving-like annotations would have exactly the same effect than the current lwt/async situation
<yminsky>
Agreed. There are one of two outcomes: we either can agree on a single design, or we can’t.
<companion_cube>
Drup: in a lower extend, it doesn't pose problems at link time
<yminsky>
If we can, then, yay! If not, well, that’s how open source works. Different people try different things, and you see what turns out to work.
<yminsky>
Yeah, it is nice that you can mix and match. We build all of our libraries using camlp4, but you don’t have to use camlp4 yourself to use them.
<Drup>
hum, actually.
<Drup>
you do.
<yminsky>
How so?
<companion_cube>
well, you have to install camlp4
<Drup>
core loads some pa_* for you
<Drup>
in particular, pa_ounit
<Drup>
so, it forces you to use camlp4 even if you don't need it
<yminsky>
Core doesn’t force you to build with syntax extensions.
<yminsky>
You have to build core with them, but you can link to Core without them.
<companion_cube>
yminsky: if you end with something different from ppx_deriving, please split it into small libraries ^^
<yminsky>
Of course. As we did with type_conv.
<yminsky>
We have to. Since Core_kernel is built with these syntax extensions, the extensions can’t depend on Core_kernel.
<Drup>
yminsky: but some syntax extensions are explicit dependencies
<Drup>
not only build-with
<yminsky>
Name one.
<Drup>
pa_ounit.
<yminsky>
Are you saying that you need to enable the pa_ounit syntax extension to link against Core_kernel?
<yminsky>
I can’t even imagine what mechanism there is to require that…
<tokenrove>
prsn: does #directory do what you need?
<yminsky>
I’m afraid I don’t fully understand the opam invocations here. But surely I can call ocamlbuild against Core without invoking syntax extensions.
<yminsky>
What does XMETAREQUIRES actually mean?
<Drup>
it's for ocamlfind
<Drup>
it tells the dependency of the ocamlfind package so that ocamlfind recursively links all the dependencies
<Drup>
(but actually, I linked the wrong thing)
<Drup>
(this one is ok, it's the runtime part of the said libraries)
<yminsky>
Yup. That part makes sense.
<Drup>
let me find the exact issue we had, some times ago
<yminsky>
If there’s something like this that you think is crazy about the design of Core, you should totally email the list.
<prsn>
tokenrove: partially, it looks like
<haesbaert>
anyway to modify the --help option in Cmdliner ? I want it to default to "plain" and to work with either -h or --help
<prsn>
tokenrove: it's kind weird actually, it seems to be able to #load a.cmo which previously broke on a dependency on b.cmo, but it still can't #load b.cmo because of a dependency on a library installed with opam
<Drup>
pa_pipebang has no runtime part, it's purely a syntax extension
<prsn>
tokenrove: but also maybe i don't need to #load things anymore? i don't really know exactly what #directory is doing
<tokenrove>
prsn: you can setup a .ocamlinit file in your project's directory that specifies your #directory and #require statements as needed
<yminsky>
Drop: So, what’s the concrete problem? Do you believe that if I build with ocamlfind against Core, that it will force you to build with camlp4?
<Drup>
that's ... not the exact issue
<yminsky>
Drup: If you think that’s the case, it’s a bug, and we’d appreciate a bug report.
<yminsky>
Drup: Ah, so can you describe the exact misbehavior?
<tokenrove>
prsn: (use #require to load the library you need)
<prsn>
tokenrove: #require in the repl says 'unknown directive require'
<Drup>
if you build with core *and* camlp4, it will bring uninvited syntax extension that may not be compatible with other (namely, deriving), even if you don't use the core syntax extensions
<yminsky>
Drup: Great. That also sounds like a bug. Could you report it on github?
<Drup>
yes
<yminsky>
Awesome.
<Drup>
(but I'm pretty sure a bug report about that was done some month ago, not by me though)
<tokenrove>
prsn: oh sorry, #use "topfind";; first
<yminsky>
Drup: If you can find the report and show it to me, I’d like to see it.
segmond has quit [Ping timeout: 244 seconds]
<prsn>
tokenrove: ok, that worked, but "#require Sedlexing", which is the opam-installed module I need, says no such package
<prsn>
do i need to set up a path?
<Drup>
prsn: "#require sedlex"
<yminsky>
Final thought before I go: we’re actively working on making Core_kernel and the rest of our stack more lightweight. Module aliases will take us a step in the right direction, allowing one to actually pull in only the modules that you actually need to use whatever functionality you want from Core_kernel. The Async_kernel change is another one. It will take some time, but we hope to make it a lot better in this regard in the
<yminsky>
year or so.
<yminsky>
Cheers all.
yminsky has quit [Quit: yminsky]
<prsn>
tokenrove: ah. Anyway i can know the package name from the error "reference to undefined global Sedlexing" that i got from trying to #load the module?
<prsn>
*Any way
<Drup>
no, you can't :)
<Drup>
that's the module name, not the package name
TheCommieDuck has joined #ocaml
<TheCommieDuck>
Hey. Can I do some kind of match x with Foo(bar) with baz=5 | Foo2(bar, baz) -> ... ?
<companion_cube>
replace 'with' with 'when' and you're good to go
<TheCommieDuck>
woo, thanks :)
<companion_cube>
also, if you have one argument, Foo bar is as good as Foo (bar)
<ggole>
If the baz there isn't the same identifier.
<TheCommieDuck>
the actual code is type x = Foo of bar | Foo2 of bar * baz, so I wanted to be able to have an inline default variable.
<ggole>
Hmm, write a function to map an x to a pair of bar, baz
<ggole>
eg let f = function Foo bar -> bar, 5 | Foo2 (bar, baz) -> bar, baz
<TheCommieDuck>
a better idea
segmond has joined #ocaml
dav has joined #ocaml
dav_ has quit [Ping timeout: 246 seconds]
vpm has quit [Quit: WeeChat 1.1.1]
vpm has joined #ocaml
ddosia has joined #ocaml
ned- has quit [Ping timeout: 244 seconds]
Thooms has joined #ocaml
pyon has joined #ocaml
bjorkintosh has quit [Ping timeout: 252 seconds]
leowzukw has joined #ocaml
yminsky has joined #ocaml
travisbrady has joined #ocaml
Algebr has joined #ocaml
HenriMorlaye is now known as Ansnum
Ansnum has left #ocaml [#ocaml]
Ansnum has joined #ocaml
captain_furious has joined #ocaml
travisbrady has quit [Quit: travisbrady]
Thooms has quit [Ping timeout: 256 seconds]
mort___ has joined #ocaml
struktured has quit [Ping timeout: 250 seconds]
darkf has quit [Quit: Leaving]
<def`>
TheCommieDuck: match x, 5 with Foo bar, baz | Foo2 (bar, baz), _ -> …
<ia0>
nice
<ia0>
and does a tuple for (x, 5) be created? or is this technique costless?
<Drup>
the tuple is created
<ia0>
:-( but still nice
<Drup>
let f bar baz = ..... in match x with Foo bar -> f bar 5 | Foo2 (bar, baz) -> f bar baz
<ia0>
Yes, that what I usually do
<ggole>
The compiler should do forwarding -_-
<def`>
Drup: the tuple is created ?
<Drup>
pretty sure it is, yes
<ggole>
Actually I think for immediate match it isn't
<Drup>
there was a similar issue at some point
struk|dtut has joined #ocaml
<def`>
"pretty sure" means no then.
<def`>
I am pretty sure it doesn't allocate :-)
captain_furious has quit [Quit: Leaving.]
<def`>
(even in bytecode)
<ggole>
Looks like it doesn't in 4.02.1
<def`>
Drup: I remember the issue you mention, its only in a let that it is allocated, for match it is not
<Drup>
hum, ok
<Drup>
I though naively that it was the same behavior
<def`>
(because there is a different path when match have the form a, b and the pair is not bound to a name)
<ggole>
A bit like the tuple arguments thing
mort___ has quit [Quit: Leaving.]
<Drup>
still weird that match with one branch do not behave the same as let bindings
freling has quit [Quit: Leaving.]
<def`>
I agree
<ggole>
What's the difference?
<def`>
tuple is allocated in a let
<def`>
let x, y = 1, 2 in …
<def`>
:'(
<ggole>
Oh :(
<mrvn>
and in match (1, 2) in (x, y) -> ... it is not?
<def`>
yes
<ggole>
If the tuple isn't named
pakchoi2 has quit [Quit: Leaving.]
<mrvn>
what about: match foo () in (x, y) ->?
<def`>
lol
<whitequark>
uh
<ggole>
Always allocated (unless inlined, I suppose)
<mrvn>
figures
* Drup
starts doing the pierre approved inlining dance.
<def`>
:D
<mrvn>
.oO(And here I was using -fno-inline with gcc)
<ggole>
It'll be interesting to see in how many cases more aggressive inlining lowers performance
<mrvn>
ggole: I've recently looked at a lot of arm-none-eabi-gcc output and it is amazing how bad optimized code is.
<whitequark>
clang?
<mrvn>
have to try and compare that one day
dav has quit [Ping timeout: 255 seconds]
<def`>
almost no peephole optimization are made?
<def`>
(because it's often counter-intuitive what code is "good" for the processor :))
<ggole>
Yeah
<ggole>
Workarounds for false dependencies can look quite ridiculous until you understand why they are there, for example
struktured has joined #ocaml
dav has joined #ocaml
<whitequark>
arm1176 isn't even out-of-order (almost)
<mrvn>
def`: I've looked at different code for bzero(). Just a simple loops to clear the memory in C. Depending on how I wrote the C code I got up to 4 times as many opcodes.
<mrvn>
including the function pre/posfix.
<whitequark>
I would be interested in the comparison
matason has joined #ocaml
<mrvn>
and none of them would unroll the loop and use stm (store multiple registers).
matason has quit [Client Quit]
<whitequark>
that's not necessarily faster
<mrvn>
you have to spill a few regs for it but above 64 byte or so you are faster.
ned has joined #ocaml
ned is now known as Guest80118
<Algebr>
Why do people get so excited over list comprehensions? Somewhat overrated methinks.
<Drup>
because they are used to it from python/LINQs, I guess
<Drup>
probably because it's impossible to write proper functional transformations in those langauges
<vanila>
in general people go crazy for being able to do a normal thing very slightly shorter
<vanila>
remember all the fuss about arc for the amazing contribution of shortening 'define' to 'def'
pakchoi2 has joined #ocaml
<Algebr>
I use it a lot in python but I've never been like I need a list comprehension in ocaml
<vanila>
I thinnk it's just easier to get excited about a O(n) save you can understand now rather than something complex that will really matter in the long term
pakchoi2 has quit [Client Quit]
badkins has joined #ocaml
<mrvn>
Algebr: What? YOu never used List.map, List.iter or List.fold_left/right?
yminsky has quit [Quit: yminsky]
<Algebr>
Of course I have, but I mean stuff like these syntax extensions [g | t <- ts; g <- functions t] (Ripped from the latest ocaml question on stack))
<mrvn>
What is that supposed to do? That's totaly unreadable.
<mrvn>
pythons [foo(x) for x in list] is at least understandable just by looking at it
mort___ has joined #ocaml
Nahra has quit [Remote host closed the connection]
<dmbaturin>
Algebr: In sane use cases "map f xs" or "filter p xs" tend to be shorter than list comprehensions, and cases where list comprehensions are shorter tend to be borderline obfuscation IMHO.
<mrvn>
One thing though is nice. The list comprehension in python constructs a list from an itrable. The source doesn't have to be a list.
<dmbaturin>
mrvn: True.
<Drup>
(you can do that in ocaml too)
<mrvn>
So it's more like: List.of_enum + map + filter
ddub has joined #ocaml
<Algebr>
Hmm, don't see List.of_enum
<Algebr>
is that part of batteries
<Drup>
yes
<Drup>
don't use enum
<Drup>
use sequence
<mrvn>
since the standard lib doesn't have any enums ...
<Algebr>
I'm kind of moving away from using core, its a bit heavy weight.
<Drup>
mrvn: that's not *exactly* true.
<Drup>
Algebr: sequence is a (small) independent library
<mrvn>
Drup: it has other things but not enum. And as you said: use sequence
<mrvn>
Somehow enums have come and gone before I started to actualy use them. :)
<struk|dtut>
those poor, neglected enums
AlexRussia has quit [Quit: WeeChat 1.2-dev]
<mrvn>
They can form a line to get some condolences
ygrek has joined #ocaml
yminsky has joined #ocaml
<Algebr>
does batteries have C dependencies?
<Drup>
Is the question "will it work in js_of_ocaml ?" ?
yminsky has quit [Client Quit]
<Algebr>
lol yes.
<Drup>
then no, not for now
<Drup>
at least, not very well
<Drup>
use containers if you want an stdlib extension jsoo-proof
ddosia has quit [Quit: Connection closed for inactivity]
pyon is now known as pyon-as-a-brick
<dmbaturin>
Someone will make JS of C eventually.
<Drup>
sure, it's call emscripten
larhat has quit [Quit: Leaving.]
<ddub>
hallo, I am trying to port an ocaml application from a docker to a rocket container but it gives me an unclear error when executing
<ddub>
it references camlinternal, given I don't really know the externals I am feeling out of my depth and would appreciate any suggestions to try and find the source of the error
<dmbaturin>
ddub: Well, without application source it's not possible to tell anything.
<dmbaturin>
And without knowing what exactly /run/liquidsoap.aci is doing.
ptc has joined #ocaml
ptc is now known as Guest81763
ygrek has quit [Ping timeout: 250 seconds]
<ddub>
no way to find out what is Not_found?
Guest81763 has quit [Ping timeout: 246 seconds]
<dmbaturin>
ddub: Not_found is a very generic exception name, functions like List.find or, in this case, Map.find raise it when an element is not found.
martintrojer has quit [Ping timeout: 240 seconds]
ptc_ has joined #ocaml
martintrojer has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
yminsky has joined #ocaml
<dmbaturin>
adrien: What if we make an install script for lablgtk on windows that takes ocaml and GTK installation paths as arguments?
martintrojer has quit [Max SendQ exceeded]
<dmbaturin>
Will you merge such a thing?
martintrojer has joined #ocaml
<adrien_znc>
dmbaturin: I'd do something based on win-builds
<dmbaturin>
Win-builds?
<adrien_znc>
at that point I'd much prefer to work on the ocaml cross-compiler for windows
<adrien_znc>
(btw, I'm on shared satellite connection through a ZNC so I might not properly see all messages (arriving at home in 3 to 4 hours though)
martintrojer has joined #ocaml
tane has quit [Ping timeout: 246 seconds]
tane has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<dmbaturin>
Oh, interesting. Didn't know of it.
<adrien_znc>
I'll need to tatoo the link on my back and run naked during a football game I guess
<dmbaturin>
I lack knowledge to work on windows cross-compilation, but maybe I can do something with that win-builds tool.
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<adrien_znc>
it already provides the GTK+2 stuff and it should be fairly simple to package the various pieces together
<reynir>
adrien_znc: that would be interesting
<adrien_znc>
I'd say the timeframe for cross-compiled lablgtk is roughly end of the year
martintrojer has quit [Max SendQ exceeded]
<adrien_znc>
(I mean, for it to be good enough to be officially distributed)
martintrojer has joined #ocaml
<adrien_znc>
so that leaves a lot of need meanwhile
Mandus has joined #ocaml
yminsky has quit [Quit: yminsky]
alpen has joined #ocaml
seangrov` has joined #ocaml
seangrove has quit [Ping timeout: 244 seconds]
dav has quit [Ping timeout: 256 seconds]
mort___ has joined #ocaml
<tokenrove>
if i'm working with local modifications of an opam package, do i want "opam init default ." or "opam pin add ."?
TheCommieDuck has left #ocaml ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
dav has joined #ocaml
struk|dtut has quit [Ping timeout: 246 seconds]
Kakadu has quit [Quit: Page closed]
struktured has quit [Ping timeout: 256 seconds]
Anarchos has joined #ocaml
Guest80118 is now known as ned
AlexRussia has joined #ocaml
<Drup>
tokenrove: later
<dmbaturin>
Why utop may not see the module names after I #load "foo/bar.cmo" ?
seangrov` has quit [Ping timeout: 256 seconds]
<ggole>
Use #directory to add foo (iirc)
vanila has quit [Quit: Leaving]
ptc_ has quit [Ping timeout: 240 seconds]
struktured has joined #ocaml
mort___ has quit [Quit: Leaving.]
swgillespie has joined #ocaml
willy_ has joined #ocaml
wwilly has quit [Ping timeout: 244 seconds]
nullcat_ has joined #ocaml
SkoAleVal has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
Kakadu has joined #ocaml
Haudegen has quit [Ping timeout: 244 seconds]
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark>
yes
<tokenrove>
is there a good example of a library exposing its ctypes types to other libraries that depend on the same types?
Haudegen has joined #ocaml
segmond has quit [Ping timeout: 264 seconds]
hilquias has joined #ocaml
<whitequark>
what's the problem?
<whitequark>
it should just work as usual
Haudegen has quit [Ping timeout: 255 seconds]
<def`>
hmm, you might want to expose the ctypes type witnesses (which are values as far as ocaml is concerned) in the interface too
Haudegen has joined #ocaml
nopf has joined #ocaml
segmond has joined #ocaml
Haudegen has quit [Ping timeout: 264 seconds]
seangrove has joined #ocaml
Haudegen has joined #ocaml
ptc has joined #ocaml
ptc is now known as Guest51991
hilquias has quit [Ping timeout: 255 seconds]
swgillespie has joined #ocaml
Guest51991 has quit [Ping timeout: 264 seconds]
yomimono has joined #ocaml
ptc_ has joined #ocaml
pyon-as-a-brick is now known as pyon-k
yomimono has quit [Ping timeout: 256 seconds]
rand000 has joined #ocaml
bjorkintosh has joined #ocaml
mort___ has joined #ocaml
antkong has joined #ocaml
<tokenrove>
whitequark: no problem, just trying to figure out what the best practices were in terms of how much one exposes in the interface
Submarine has joined #ocaml
Submarine has joined #ocaml
sivoais has quit [Ping timeout: 255 seconds]
Guest11627 has quit [Ping timeout: 252 seconds]
ggole has quit []
slash^ has quit [Read error: Connection reset by peer]
diethyl has joined #ocaml
<Anarchos>
tokenrove i would say : you expose only the minimum required
diethyl has quit [Ping timeout: 265 seconds]
Haudegen has quit [Ping timeout: 264 seconds]
diethyl has joined #ocaml
Haudegen has joined #ocaml
<Algebr>
Why does ocamlc complain about unbound modules if one does give the flag for -linkpkg?
<whitequark>
the order is important
<Algebr>
order of what, the flags to ocamlc?
<whitequark>
order of modules being linked. but it should be unlikely that you get that error
<whitequark>
can you be more specific?
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Algebr>
sorry, I was doing ocamlfind ocamlc -g json_data.ml -package yojson -o Foo.
<whitequark>
but that doesn't have -linkpkg
<Algebr>
where json_data.ml is a small thing using yojson and it craps out if I don't give -linkpkg
<whitequark>
oh
<Algebr>
I'm asking why does it need it?
<whitequark>
does NOT give the flag for -linkpkg
<Algebr>
oh oops, I forgot to write does not
<Algebr>
sorry
<whitequark>
well, it has to link Yojson into the final executable
<companion_cube>
I think the -package yojson might have to be before the module name
<whitequark>
companion_cube: no, that doesn't matter
<companion_cube>
I'm never sure with this
<Algebr>
so is -linkpkg always needed for executables?
<whitequark>
normally, -package just adds an include path
<whitequark>
but with -linkpkg, it specifies the .cma's
<whitequark>
yes
<companion_cube>
Algebr: it's needed for executables, but not for libraries
<Algebr>
but it still craps out if I dont give the -o flag
sivoais has joined #ocaml
sivoais has quit [Changing host]
sivoais has joined #ocaml
<whitequark>
"craps out" is not an error message.
<Algebr>
Error: Error while linking json_data.cmo: Reference to undefined global `Yojson' That is with ocamlfind ocamlc -g json_data.ml -package yojson
<companion_cube>
well yes, you need -linkpkg
<Algebr>
then how does one make a library
<whitequark>
ocamlc -a
A1977494 has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 256 seconds]
A1977494 has left #ocaml [#ocaml]
MercurialAlchemi has joined #ocaml
SkoAleVal has quit [Read error: Connection reset by peer]
antkong has quit [Quit: antkong]
monod has quit [Ping timeout: 250 seconds]
dsheets_ has quit [Ping timeout: 250 seconds]
antkong has joined #ocaml
<Algebr>
Is there something higher level than Unix.localtime? Something that will give me back "Jan 20 2001" for example given the float that localtime expects
MercurialAlchemi has quit [Ping timeout: 252 seconds]
* Kakadu
remembers something called 'calendarlib'
<companion_cube>
calendar, odate... look on opam
<def`>
Core also has a date api
MercurialAlchemi has joined #ocaml
<def`>
calendar is rich, but the api is hmm, verbose and not always following best practices
<companion_cube>
are there really explicit "best practices" in OCaml?
<def`>
no.
<def`>
but global state will never be one of them
<companion_cube>
oh.
<companion_cube>
there's global state in calendar? sad
<def`>
the timezone
<companion_cube>
oh.
willy_ has quit [Quit: This computer has gone to sleep]
<adrien>
C \o/
monod has joined #ocaml
<Algebr>
I'm trying to use it the calendar package in the top level, either utop or ocaml. I'm doing #require "calendar";; and then open Time but still get unbound Module errors. Also added #require "calendar" opaminit, is more required?
<companion_cube>
sounds stupid, but did you install calendar first?
<Algebr>
yea, it was already installed
<Algebr>
I guess something else had a dependency and I see the line that it was loaded by ocaml
<def`>
everything is a submodule of calendar something
<companion_cube>
maybe it's Calendar.Time
<def`>
yep
<Kakadu>
CalendarLib.Time;;
<companion_cube>
utop autocompletes, you should try
mort___ has quit [Quit: Leaving.]
<companion_cube>
def`: do you think the author of calendar would accept patches to improve the interface?
<Algebr>
oh, but ocp-browser had Time as its own module
<def`>
companion_cube: I don't know him at all
<companion_cube>
oh, he's a guy working on frama-C at CEA, I think
<def`>
but the API evolved a bit over time, so, maybe.
<companion_cube>
bad news is, it's on the forge, it might not be easy to contact him about this
<companion_cube>
I think there are some libs that are nice but have bad interface
<companion_cube>
e.g., to.ml
<def`>
not via pullrequest, but maybe an email :D ?
<MercurialAlchemi>
Lwt.Canceled
<def`>
I don't remember what is to.ml
<def`>
?
<def`>
lwt cancel semantics are broke :D
<MercurialAlchemi>
wrong copy-paste :)
<def`>
it's not nice, but it is a bad interface =)
<companion_cube>
a toml parser/printer
<def`>
(:
<def`>
Ok.
<Algebr>
okay, this is too much of a hassle, will just write code =/
<companion_cube>
I don't know whether odate is good
Kakadu has quit [Remote host closed the connection]
dsheets_ has joined #ocaml
travisbrady has joined #ocaml
yomimono has joined #ocaml
swgillespie has joined #ocaml
swgillespie has quit [Client Quit]
reem has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<MercurialAlchemi>
companion_cube: looks like it makes it easy to mix dates with different (or no) timezone
BitPuffin has joined #ocaml
<companion_cube>
I don't know dates well enough :/
swgillespie has joined #ocaml
ollehar1 has joined #ocaml
<companion_cube>
I'd think everything would be in unix timestamps, and timezones would be used only when printing to human readable form
<def`>
dates are always more complicated that we assume :)
antkong has quit [Ping timeout: 256 seconds]
<Drup>
that reminds me an article about what programmers assume about (postal) addresses
<companion_cube>
or mail addresses
<companion_cube>
just accept any string with an @ inside
travisbrady has quit [Quit: travisbrady]
Ansnum_ has joined #ocaml
<dmbaturin>
Drup: Got a link?
Ansnum has quit [Ping timeout: 256 seconds]
Ansnum_ is now known as Ansnum
<Anarchos>
companion_cube unix timestamps are false reference for time : you miss the supplementary seconds....
<dmbaturin>
I used to think it's reasonable to make postal code in address forms mandatory until I had to enter a Hong Kong postal address in a form. :)
ruoso has quit [Remote host closed the connection]
tnguyen has quit [Quit: tnguyen]
<MercurialAlchemi>
you can't have everything in utc all the time
<whitequark>
of course you can
<whitequark>
convert data to utc immediately after input / from utc immediately before output
<whitequark>
similarly to utf8\
<MercurialAlchemi>
you can't as in "if you base your library on this idea, you're doing it wrong"
<companion_cube>
whitequark: yeah, it sounds so reasonable
<whitequark>
a library that enforces keeping everything in utc is, obviously, a good library
<MercurialAlchemi>
no, it's a library by people who don't need naive dates
<companion_cube>
whitequark: so, would you think a lib dealing with file paths, should deal only with absolute paths?
<MercurialAlchemi>
you may also need dates which are valid in a single timezone
<companion_cube>
convert into absolute path on input, then deal only with those
<whitequark>
companion_cube: the concept of a current directory is quite awful, actually
<companion_cube>
yes
<companion_cube>
it's a big global variable
<whitequark>
and you don't need it outside of a shell
<whitequark>
MercurialAlchemi: "naive" ?
<companion_cube>
well you can emulate it easily, using a context, and so on
<companion_cube>
but still, I think it's the same kind of idea
<companion_cube>
I need to keep working on CCIO.File, which does this
<MercurialAlchemi>
whitequark: dates with no timezone info associated
<whitequark>
yes, you don't need naive dates. it's not data that makes any sense
<whitequark>
like text without associated encoding
<MercurialAlchemi>
yeah, right
<companion_cube>
MercurialAlchemi: use the current timezone in this case
<companion_cube>
but once you've entered the date, the timezone is explicit
<companion_cube>
(same as curdir/absolute path)
<MercurialAlchemi>
haha
<MercurialAlchemi>
seriously, no
<companion_cube>
well, when I mean "friday 13th, feb 2015" I mean in my timezone
<companion_cube>
otherwise I'd specify the timezone
<whitequark>
a date without a timezone doesn't specify a point in time. it doesn't allow you to safely perform any operations on it
<whitequark>
except store as-is and display back as-is
<whitequark>
quite similar to text without encoding, actually
mengu__ has joined #ocaml
<MercurialAlchemi>
companion_cube: when you get an icalendar invitation, you may get a DATE
<MercurialAlchemi>
meaning it's a fullday event on a given day, regardless of the timezone
<whitequark>
so, it's 48 hour long?
<MercurialAlchemi>
in general, I wouldn't suggest implementing a time library without looking at RFC 5545
<whitequark>
to cover all the timezones.
keen__________75 has joined #ocaml
<MercurialAlchemi>
whitequark: maybe it's your birthday
keen__________74 has quit [Ping timeout: 244 seconds]
<MercurialAlchemi>
it's the same date, regardless of your timezone at the moment
<companion_cube>
a birthday is an informal date
hilquias has joined #ocaml
<companion_cube>
if you want to be specific, it's a time interval in a specific timezone
<companion_cube>
(unless the baby is born in a plane crossing timezones?)
<companion_cube>
(aww)
<MercurialAlchemi>
well, it may be an "informal" date, but you still need to have this notion :)
<companion_cube>
yes
<companion_cube>
but it means 'where I am'
<whitequark>
actually, your example doesn't work. if I was planning anything for my birthday, I would surely take timezones into account, for I know a lot of people in US
<companion_cube>
basically
<MercurialAlchemi>
yes
tane has quit [Quit: Verlassend]
<MercurialAlchemi>
that's why something like this wouldn't have a specific tz
<whitequark>
and I was born in a specific place and timezone, for that matter
<companion_cube>
MercurialAlchemi: this would be a "symbolic" date
<companion_cube>
something that needs to be evaluated
<MercurialAlchemi>
There are two kinds of date and time objects: “naive” and “aware”.
<MercurialAlchemi>
A naive object does not contain enough information to unambiguously locate itself relative to other date/time objects.
<MercurialAlchemi>
(from the Python docs)
<companion_cube>
so what's a naive object good for?
<MercurialAlchemi>
of course, it introduces a good deal of complexity, but welcome to the real world
<companion_cube>
I think we should divide into: 1/ a precise representation of time intervals/instants in the referential of Earth
<whitequark>
so you're saying essentially the same. you can't perform any operations on that
<whitequark>
it's basically an opaque string that is formatted like a date.
<companion_cube>
2/ an expression language for representing dates that are symbolic
<companion_cube>
like "next friday"
<companion_cube>
those expresions would have to be evaluated in some specific timezone, etc.
<whitequark>
companion_cube: relative to a specific date (which implies a timezone)
<MercurialAlchemi>
whitequark: nothing prevents you from adding days to a naive date
<companion_cube>
whitequark: I mean, things like "Easter day" are symbolic dates
<companion_cube>
but they should not belong to the same language as precise dates
<companion_cube>
they should evaluate to precise dates, every year (in this example)
<whitequark>
MercurialAlchemi: calendar switches, for example
<MercurialAlchemi>
calendar switches?
<whitequark>
yes. old/new style dates
<MercurialAlchemi>
hm
<MercurialAlchemi>
like switching to the gregorian calendar?
<whitequark>
yeah
<MercurialAlchemi>
I don't think you should take that into account
<whitequark>
it would probably work if you add something like "after 1970", and even then I'm not sure
<MercurialAlchemi>
not aware we changed calendars after 1970 :)
<MercurialAlchemi>
of course, if you also want non-naive dates to work with, say, the russian orthodox calendar, you're going to have fun
<whitequark>
tzdata already handles that
<MercurialAlchemi>
(in a type safe way, that is)
reem has quit [Remote host closed the connection]
<MercurialAlchemi>
I guess you could represent that as a special timezone...
<whitequark>
nah, you just use the regular, say, Europe/Moscow
antkong has joined #ocaml
<whitequark>
and you get a discontinuous (local) timeline
<whitequark>
all UTC points map to some local point, but some local points never happened
<MercurialAlchemi>
right
ptc_ has quit [Ping timeout: 265 seconds]
<MercurialAlchemi>
anyway, it's messy
<MercurialAlchemi>
DST is a pain too
<whitequark>
and there are still people alive whose birthday was before the switch
ghostpl_ has joined #ocaml
<MercurialAlchemi>
I must confess that I don't know when DST started
<MercurialAlchemi>
before WWII?
travisbrady has quit [Quit: travisbrady]
<dmbaturin>
MercurialAlchemi: In some XIX century.
<whitequark>
in Russia?
<MercurialAlchemi>
in general :)
<dmbaturin>
Different countries started and stopped using it at different time though. I think the US might be the first country to do it.
<MercurialAlchemi>
I assume that like women voting, it took some time to propagate
dbp has joined #ocaml
<dmbaturin>
Yes, DST is a serious but slowly spreading disease. ;)
<whitequark>
"Germany and Austria-Hungary organized the first implementation, starting on 30 April 1916."
<whitequark>
spreading?
<whitequark>
more like contracting
<MercurialAlchemi>
oh, that's what WWI was all about
ollehar1 has quit [Quit: ollehar1]
<dmbaturin>
MercurialAlchemi: From this point of view, we all lost the battle for continuos time.
<MercurialAlchemi>
yeah
<dmbaturin>
Aztecs and maya had calendars very similar to UNIX timestamps, just with funny formatting and really ancient epoch start date.
hilquias has quit [Remote host closed the connection]
antkong has quit [Ping timeout: 244 seconds]
Haudegen has quit [Ping timeout: 245 seconds]
Haudegen has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<MercurialAlchemi>
:)
Ansnum has quit [Ping timeout: 265 seconds]
myst|work has quit [Ping timeout: 252 seconds]
Anarchos has joined #ocaml
myst|work has joined #ocaml
reem has joined #ocaml
mcc has joined #ocaml
reem has quit [Remote host closed the connection]
<tokenrove>
is there any way to ensure a value is stack allocated? particularly, is it possible to declare a foreign struct allocated by ctypes to have dynamic extent?
MercurialAlchemi has quit [Ping timeout: 246 seconds]
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
reem has joined #ocaml
badon has quit [Quit: Leaving]
<whitequark>
dynamic extent?
<whitequark>
ctypes does not allocate values on stack
nullcat_ has quit [Quit: gone...]
<whitequark>
and all values allocated by ctypes are freed when finalized by GC, you can't do that explicitly
mcc has quit [Quit: This computer has gone to sleep]
rand000 has quit [Quit: leaving]
Simn has quit [Quit: Leaving]
laughing-octo-sh has quit [Ping timeout: 252 seconds]
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
<tokenrove>
sorry, dynamic extent is a lispism, i guess. anyway, that's unfortunate.