<NaCl>
what tends to be more efficient, tail recursion or loops?
<NaCl>
in ocaml, anyway
<companion_cube>
they are compiled the same
<companion_cube>
afaik
<NaCl>
You monster!
<companion_cube>
No, me cube.
<orbitz>
I should hope they are the same since if recursion is efficient it's so trivial to compile a loop into a recursive call
lamawithonel_ has quit [Remote host closed the connection]
philtor has joined #ocaml
<NaCl>
thelema: Array.sub and Vect.sub have different signatures
<NaCl>
thelema: is that intentional?
buriedhead has quit [Ping timeout: 240 seconds]
<ecc>
I've written an ocamlsdl app that needs to specify some window manager hints. Is there any way to do it besides writing a C stub?
oriba_ has joined #ocaml
<NaCl>
ecc: there are bindings to xlib out there, but I'm not exactly sure they'll do what you want
<ecc>
I can't even see how to get the low-level info (like X window id, display connection, etc.) via the ocamlsdl interface
oriba has quit [Ping timeout: 240 seconds]
<NaCl>
:/
buriedhead has joined #ocaml
roconnor_ has quit [Ping timeout: 255 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
emmanuel_ has joined #ocaml
emmanuel_ has quit [Read error: Connection reset by peer]
buriedhead has quit [Read error: Connection reset by peer]
dsheets has quit [Ping timeout: 244 seconds]
dsheets has joined #ocaml
philtor has quit [Ping timeout: 240 seconds]
oriba_ has quit [Quit: oriba_]
emmanuelux has quit [Remote host closed the connection]
ulfdoz has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
ulfdoz has quit [Ping timeout: 240 seconds]
dsheets has quit [Ping timeout: 240 seconds]
dsheets has joined #ocaml
philtor has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
philtor has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
cago has joined #ocaml
edwin has joined #ocaml
dsheets has quit [Ping timeout: 248 seconds]
dsheets has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
ttamttam has joined #ocaml
BiDOrD has joined #ocaml
BiDOrD_ has quit [Ping timeout: 255 seconds]
Cyanure has joined #ocaml
<adrien>
is there no tool to generate a C header file from ocaml type definitions?
_andre has joined #ocaml
<adrien>
having to use indices for all the macros is simply too brittle
<flux>
maybe you could at least write all the stuff in the same file, and generate the .ml+.h-files from it with a preprocessor?
newbie26 has joined #ocaml
<adrien>
my current issue is rather that C stubs are quite unreadable and typos are quite likely
<flux>
it's too bad nobody (myself included ;)) seems to have the energy and the mind power to solve these problems once and for all :)
<adrien>
might try it some day; with the standalon ecamlp4 parser, it shouldn't be too hard
<flux>
until a case you hadn't considered comes along ;)
<adrien>
yup ='(
<newbie26>
I am writing a parser in lex and yacc. What does `fun i -> Parser.IF i` construct mean?
<adrien>
but I think that something like "type t = { foo : int; bar : int }" -> #define T_FOO 0, #define T_BAR 1
<adrien>
would already be nicer
<adrien>
(I need a dice to find out how many new bugs there are in the modified C stubs)
<flux>
newbie26, that is an expression of a function that accepts a value and returns the same value wrapped into a datatype constructor Parser.IF
<newbie26>
@flux somethi9ng like a type cast?
ulfdoz has joined #ocaml
buriedhead has joined #ocaml
<flux>
newbie26, not really
<flux>
Parser.IF is a like a case of a tagged union
<flux>
or, it can be just a single constructor, in which case it is just tagging it with that name. however, given that name, I think it's one of multiple cases.
<newbie26>
@flux Thanks a lot! I think I need to RTFM more on this.
buriedhead has quit [Ping timeout: 252 seconds]
newbie26 has quit [Quit: Page closed]
asmanur1 has joined #ocaml
asmanur has quit [Ping timeout: 260 seconds]
sebz has quit [Quit: Computer has gone to sleep.]
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
<ttamttam>
adrien: ping
<adrien>
ttamttam: pong
<ttamttam>
Did you already check odll?
<ttamttam>
It did not evolve, but was interesting.
<adrien>
I actually did but that was years ago and had forgotten about it
<adrien>
I'll have to try it, thanks
<ttamttam>
If I remember correctly, it was generating a DLL from a module.
<ttamttam>
I don't think it will work out of the box.
<adrien>
"Simply run ODLL with you CMA/CMXA and one or several CMI interfaces"
<ttamttam>
But it is some OCaml versions back.
<ttamttam>
And using com
<ttamttam>
compiler code to analyse modules.
<ttamttam>
→ should certainly be adapted
<adrien>
it won't be useful for my current (as in "*right* now") but it could be useful for yypkg
<adrien>
current projects*
buriedhead has joined #ocaml
Xizor has joined #ocaml
letrec has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
dsheets has quit [Read error: Connection reset by peer]
dsheets has joined #ocaml
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
<Kakadu>
Qrntzz: hi!
<Kakadu>
Does anybody has cygwin nearby?
<Kakadu>
can you call `grep stack_t /usr/include/* -r` ?
<f[x]>
Kakadu, nothing
<Kakadu>
f[x]: I suppose that you'll fail to compile lwt on cygwin :D
* f[x]
dunno
buriedhead has joined #ocaml
<thelema>
NaCl: unlikely - I'll fix
avsm has joined #ocaml
<thelema>
NaCl: ah, it was done for ease of implementation
buriedhead has quit [Ping timeout: 268 seconds]
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
buriedhead has joined #ocaml
emmanuelux has joined #ocaml
lamawithonel has joined #ocaml
Kakadu has quit [Quit: Page closed]
roconnor_ has joined #ocaml
roconnor_ is now known as roconnor
oriba has joined #ocaml
ikaros has joined #ocaml
<NaCl>
thelema: I noticed a few interface differences between DynArray and Array and other types as well.
<NaCl>
And that DynArray was in some places 2x faster than Vect
<thelema>
dynarray has the advantage that it's not chunked like vect, but I'm a little surprised at 2x faster
<thelema>
(vect is a tree of short arrays)
Xizor has quit []
<thelema>
NaCl: let me know the other interface differences; batteries is going through a "great standardization" right about now
ankit9 has quit [Read error: Connection reset by peer]
oriba has quit [Quit: oriba]
Snark has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
<hcarty>
thelema: Which is more important in Batteries during this standardization process - consistency within Batteries, or compatibility/consistency with stdlib?
ankit9 has joined #ocaml
<NaCl>
thelema: DynArray has "get" whereas everything else I've seen has "at". index_of instead of findi. No "mem".
<NaCl>
thelema: thoes are the ones at the top of my head
<hcarty>
NaCl: My guess is that DynArray.get is meant to match Array.get
buriedhead has joined #ocaml
<NaCl>
ah
buriedhead has quit [Ping timeout: 252 seconds]
Kakadu has joined #ocaml
<thelema>
hcarty: compatibility with stdlib is first priority, but consistency within batteries can often be achieved by extending stdlib modules
cago has left #ocaml []
buriedhead has joined #ocaml
<thelema>
NaCl: only list has at... index_of is fixable, mem can be added
<thelema>
NaCl: do you recall the performance problem?
<NaCl>
thelema: not particularly. It just went "faster". I won't be able to profile it until tonight
philtor has joined #ocaml
<hcarty>
thelema: I'm thinking along the lines of labeled arguments and raising/not raising exceptions.
<hcarty>
thelema: I've been happy with the BatFoo.Exceptionless and BatFoo.Labels approach
<thelema>
NaCl: ok.
<thelema>
hcarty: I think batteries original modules should be exceptionless and labeled
<hcarty>
thelema: I'm ok with that, it just make it harder to use Batteries with non-Batteries code.
<thelema>
stdlib-extended libraries should be stdlib-compatible by default and have Exceptionless and Labels
<hcarty>
thelema: Functors, for example, which expect stdlib-like modules
<hcarty>
That's horribly inconsistent within Batteries
<hcarty>
Why should there be that big of a difference between BatArray and BatEnum?
<thelema>
hmm...
<thelema>
you're right...
<thelema>
functor parameters probably shouldn't be named
<thelema>
err, labelled
<thelema>
I think labeled arguments are very good, and should be encouraged
<thelema>
exceptionless, maybe a bit less so.
<thelema>
but still useful.
<thelema>
I still want to have `map ~f`, and I can't have it in stdlib modules by default, but I could have it in batteries modules by default
<hcarty>
thelema: I'm not sure I agree with exceptionless ... I really like the "limited gotchas" results that come from having foo : ... -> 'a option and foo_exn : ... -> 'a
<hcarty>
thelema: But then every Batteries user needs to know which modules are stdlib-based and which ones aren't
<hcarty>
You can't provide a functor that works across both
<hcarty>
If that functor requires map, for example
<thelema>
who's functorizing across code that raises exceptions?
<hcarty>
No no - the labeling
<hcarty>
Sorry, my exceptionless comment was an aside
<thelema>
on labeling, it's trivial to strip the labels - I think I'm ok buying common label usage for some friction functorizing some uncommon needs
<hcarty>
How is it trivial?
<thelema>
module FOut = FIn(struct include Enum let map xs f = map ~xs ~f
<thelema>
end)
<hcarty>
But why is Enum different than Array?
<hcarty>
That feels very unpolished
<thelema>
well, for the map example, we have mappable already
<thelema>
we have a module interface for it.
<hcarty>
But that interface can't be applied directly to both stdlib-based and Batteries-original modules
<thelema>
I agree that Enum following one style and array following another style by default feels funny. I'm still looking for better solutions...
<thelema>
I'm not happy with the .Labels solution as it's not default anywhere
<hcarty>
It's more work initially, but I think it's better to have .Labels and .Exceptionless everywhere, then provide Batteries, BatteriesExceptionless, BatteriesLabels
<thelema>
maybe making a BatteriesL which includes all the .Labels modules will fix this
<thelema>
why BatteriesExceptionless? why not default exceptionless on non-stdlib modules?
<hcarty>
Or, if you prefer, Batteries = BatteriesL(abels); BatteriesNolabels = stdlib-like; BatteriesExceptionless = no exceptions
<thelema>
I would like that, but it would break the stdlib backwards compatibility
<hcarty>
thelema: Consistency. That's one of the benefits of using Batteries.
<thelema>
To have stdlib compatibility, we have to sacrifice some consistency
<thelema>
I can see better and better why core made the choices they did.
raichoo has joined #ocaml
<hcarty>
thelema: I agree. If I weren't already heavily invested in using Batteries in my code I would strongly consider moving to Core now that they have opened up a bit.
<hcarty>
But I don't want to give up BatIO or the pervasive *.print functions or any of the other Batteries goodies
<hcarty>
If stdlib compatibility is among the top priorities, then it makes sense to have "module Batteries" be stdlib-like throughout (no default labels, raise exceptions)
<hcarty>
Then, additionally, provide BatteriesSomething with labels and no exceptions, BatteriesLabels with labels and exceptions, BatteriesExceptionless with no exceptions and no labels
<hcarty>
If that approach isn't taken then it makes "module Batteries" a PITA to use because every module will behave differently.
<thelema>
Maybe just Batteries and BatteriesNC (not compatible - with both labels and exceptionless)
<hcarty>
Or that
<thelema>
we might keep .Labels and .Exceptionless for those that want to customize things themselves, but having just two toplevel interfaces to support seems better than 4
<hcarty>
If Batteries.Foo always have .Labels and .Exceptionless (where necessary/appropriate) then it makes is easier for users to transition to the BatteriesNC way of thinking if they want to.
<hcarty>
thelema: I agree. Two is going to be easier to keep straight than 4.
<thelema>
also easier to document. Which is the next challenge...
<hcarty>
thelema: In that case though, you probably want BatFoo.NC only
<hcarty>
thelema: Otherwise you have BatFoo.Labels.map and BatFoo.Exceptionless.map, each with a different and incompatible signature.
<hcarty>
Not to mention the BatFoo.Cap modules...
<thelema>
oh yeah, can't just compose the two...
<hcarty>
But of .Cap sticks around it should probably be NC-only
<hcarty>
s/of/if/
<thelema>
hcarty: that was my thinking for the rest of the batteries modules.
<hcarty>
thelema: But if you do that with BatFoo directly then you lose consistency
<thelema>
maybe `Batteries` should only extend stdlib, and `BatteriesNC` includes more fun stuff
<thelema>
yes, but then the consistency problems...
<hcarty>
And if BatFooA acts differently than BatFooB then it grealy increases the barrier to entry.
<thelema>
I'm fine not providing *all* of batteries in backwards compatibility mode.
<thelema>
(I think)
<thelema>
we have to provide Enum and IO there
<hcarty>
thelema: I think that anything not stdlib-like should be kept out of module Batteries if that's the approach taken
<thelema>
but it's probably fine if batFingerTrees have only the advanced interface
<thelema>
hmmm...
<hcarty>
That would reduce the development burden - no need to have BatFoo.NC anywhere but in the stdlib-like modules
<hcarty>
However, that really muddies the waters when it comes to figuring out what Batteries is
<hcarty>
"Hey cool! Batteries have finger trees!"
<thelema>
true. Batteries may shrink a bunch because of this.
<hcarty>
"No, wait, it doesn't..."
<hcarty>
"No, it does! You just need to open BatteriesNC rather than Batteries!"
<thelema>
we already have that with BatteriesThreads
<hcarty>
Threads changes a lot more than calling conventions.
<hcarty>
There is no spooky action at a distance when going from Batteries -> BatteriesNC. There is from Batteries -> BatteriesThreads.
<thelema>
true.
<thelema>
I'm not too happy with the core/core_extended dichotomy, I'd prefer not to have such a split in batteries
iago has joined #ocaml
ulfdoz_ has joined #ocaml
<thelema>
mainly because consistency would be even more difficult - the logical result is a separate project for each unrelated module.
<hcarty>
thelema: I agree
<thelema>
Enum and IO bind together batteries in a way that data structures libraries don't.
ulfdoz has quit [Read error: Operation timed out]
ulfdoz_ is now known as ulfdoz
<hcarty>
thelema: Quite.
<thelema>
biab
letrec has quit [Ping timeout: 244 seconds]
ttamttam has quit [Remote host closed the connection]
buriedhead has quit [Ping timeout: 252 seconds]
avsm has quit [Quit: Leaving.]
jamii has joined #ocaml
sebz has joined #ocaml
<hcarty>
thelema: If BatteriesNC does happen, I vote for gasche's Ord over stdlib-like compare functions in addition to the other proposed changes.
milosn has quit [Ping timeout: 240 seconds]
<flux>
soo, BatteriesNC is some unified-parameter-order-interface for Batteries?
<flux>
or vice versa?
sebz has quit [Quit: Computer has gone to sleep.]
milosn has joined #ocaml
buriedhead has joined #ocaml
buriedhead has quit [Ping timeout: 252 seconds]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
buriedhead has joined #ocaml
_andre has quit [Quit: o.O]
Submarine has quit [Remote host closed the connection]
buriedhead has quit [Ping timeout: 276 seconds]
mdelaney has joined #ocaml
<thelema>
flux: the first one. Batteries-NotCompatible
<thelema>
hcarty: yes, stdlib compare will be removed from NC
taupin has quit [Ping timeout: 268 seconds]
raichoo has quit [Quit: WeeChat 0.3.4]
Drup has joined #ocaml
jamii has quit [Ping timeout: 244 seconds]
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
<hcarty>
thelema: Hooray :-)
<thelema>
hcarty: I strongly approve of ord (and eq)
<Ptival>
but now I have multiple files so this does not work anymore
<thelema>
change the predicate for your tags to just "true"
<Ptival>
ok
<thelema>
wait, which version of ocaml are you using?
<thelema>
3.12.0 or .1?
<Ptival>
oh, it works
<thelema>
you might be running into a 3.12.0 bug with ocamlbuild... or not
<Ptival>
3.12.1
<thelema>
ok, glad it works. I usually tag based on the first part of the filename, tagging on extensions isn't needed because tags do different things for different actions
<thelema>
I guess tagging *.byte doesn't work. or maybe it's that "" doesn't do globbing... hmmm
<Ptival>
I don't really care about the pattern for now :)
<Ptival>
true is fine with my use
<thelema>
great. carry on.
<Ptival>
thanks
<NaCl>
So, I'm looking at making a lexer/parser. What are the advantages of using ocamlyacc/ocamllex over yacc/lex?
<thelema>
NaCl: you get to use ocaml
<NaCl>
I see
philtor has quit [Ping timeout: 252 seconds]
ulfdoz has quit [Ping timeout: 240 seconds]
<Drakken>
Anybody know why Archimedes.Viewport.layout_borders makes the plot on the parent viewport disappear?
<Drakken>
layout_borders creates several child viewports. I can write onto them, but I'm not sure what happened to the plot on the original viewport.
<thelema>
Drakken: I assume you can't order things so it all works?
<Drakken>
thelema I tried before the plot and after.
<thelema>
maybe all plots must be child plots?
<Drakken>
maybe. I can't even find a general manual on wtf a viewport exactly is.
<Drakken>
I thought it was the clipping region for the plot, but I can use the viewport to display text in the margin.
sebz has joined #ocaml
<thelema>
viewports are usually a combination clipping region / scaling factors for each axis
<Drakken>
right
<Drakken>
it just seems strange that the parent suddenly disappears.
<thelema>
try two children instead of parent/child
<Drakken>
what do you mean? layout_borders created five children: one for each border and one for the middle.
<thelema>
ok, maybe I don't understand what's going on.
<thelema>
I've still not used archimedes, despite skimming your code
<adrien>
NaCl: with ocaml, you have variants and that makes ASTs much nicer to create and go through
<Drakken>
I could try drawing on the center child, of course, but I'm wondering why I bothered to initialize the parent with cairo/png.
<Drakken>
and whether there would be new borders in the center if I initialize that.....
<thelema>
adrien: very true - Variant types are awesome for ASTs
<thelema>
Drakken: I have no idea.
<Drakken>
thelema that's okay. I'm posting a support request to the archimedes group.
NihilistDandy has joined #ocaml
<adrien>
NaCl: C: unions + enums and switch-case vs. OCaml: variants and pattern-matching
Ptival has quit [Quit: leaving]
mdelaney has joined #ocaml
willb has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
<NaCl>
adrien: If I do this in ocaml, I will have to take ownership.
* NaCl
isn't sure he wants that
<thelema>
how complex is the thing you're parsing?
edwin has quit [Remote host closed the connection]
<ousado>
NaCl: maybe you want to take a look at a few compilers written in ocaml vs. some written in C or C++ (that'd be the alternative, right?) and base your decision on that
roconnor has quit [Ping timeout: 252 seconds]
Drup has quit [Quit: Leaving.]
ztfw has joined #ocaml
pcjoby has left #ocaml []
milosn has quit [Ping timeout: 252 seconds]
milosn has joined #ocaml
Snark has quit [Quit: Quitte]
oriba has joined #ocaml
<NaCl>
thelema: simple, probably just something close to s expressions
<thelema>
NaCl: it may not matter
<thelema>
ocaml vs. c
<thelema>
for more complex grammars, ocaml is very nice
<NaCl>
I think it's just going to be glorified boolean logic
<NaCl>
with some easy noncomplex way to specify certian predefined function parameters
<thelema>
wait, if it's got logic, that's not so trivial.
<thelema>
if it's as complex as a calculator, use ocaml.
<NaCl>
kk, I'll look into it
<NaCl>
I was essentially told by one of my coworkers that if I used a parser generator I'd take ownership of the thing anyway.
<adrien>
mmmm
<adrien>
let him do it without a parser generator and see how he manages? :P
<thelema>
use ocaml and have fun with parser combinators
<NaCl>
mmm
<NaCl>
I'll see if the guy who asked me to do this agrees with the idea
probst has quit [Quit: probst]
<NaCl>
adrien: have any idea how reliable the mysql bindings are?
<adrien>
NaCl: dunno; somehow I expect them to be good but I don't know why
<adrien>
you should try to see what is using them
<_habnabit>
well, that assumes that anything related to mysql can be 'reliable'
<NaCl>
I don't have a choice in the matter.
<NaCl>
MySQL is a requirement
<_habnabit>
I'm sorry
<NaCl>
heh
letrec has joined #ocaml
milosn has quit [Ping timeout: 252 seconds]
mdelaney_ has joined #ocaml
mdelaney has quit [Read error: Connection reset by peer]
mdelaney_ is now known as mdelaney
Morphous_ has quit [Read error: Operation timed out]