<pippijn>
I just wanted to start using oasis again
<pippijn>
and I immediately found why I didn't like it again
osa1 has quit [Quit: Konversation terminated!]
<pippijn>
1) modules in subdirs *must* be capitalised, or oasis won't know they exist
<pippijn>
2) if oasis doesn't know a module exists (because it might be built by a custom rule), it doesn't do its magic in _tags files
avsm has quit [Quit: Leaving.]
q66 has quit [Quit: Leaving]
madroach has quit [Ping timeout: 264 seconds]
madroach has joined #ocaml
ygrek has joined #ocaml
alang has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
darkf has joined #ocaml
milosn_ has joined #ocaml
milosn has quit [Ping timeout: 268 seconds]
dsheets has quit [Ping timeout: 260 seconds]
ygrek has joined #ocaml
ben_zen has quit [Ping timeout: 245 seconds]
ggole has joined #ocaml
shinnya has quit [Ping timeout: 240 seconds]
mal``` has quit [Ping timeout: 241 seconds]
ben_zen has joined #ocaml
mal`` has joined #ocaml
mal`` has quit [Ping timeout: 264 seconds]
Xom has quit [Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]]
mfp has quit [Read error: Connection reset by peer]
ollehar has joined #ocaml
Drup has quit [Quit: Leaving.]
mal`` has joined #ocaml
mfp has joined #ocaml
weie_ has joined #ocaml
weie has quit [Ping timeout: 264 seconds]
<adrien>
pippijn: "modules in subdirs have to be capitalized" <- what do you mean? for packs?
yezariaely has joined #ocaml
yezariaely has quit [Client Quit]
dtg has joined #ocaml
hto has quit [Ping timeout: 264 seconds]
hto has joined #ocaml
manud has quit [Quit: manud]
weie has joined #ocaml
weie_ has quit [Ping timeout: 260 seconds]
zpe has joined #ocaml
djcoin has joined #ocaml
yezariaely has joined #ocaml
zpe has quit [Ping timeout: 248 seconds]
<gasche>
adrien: hongboz just added -no-ocamlfind to camlp4-ocamlbuild compilation command
<gasche>
(you may have had that in your patch pipeline)
ben_zen has quit [Quit: sleeeeeeep]
<whitequark>
hm, can ocaml narrow class types?
<whitequark>
something like: match shape with rectangle as r -> r#width * r#height
zpe has joined #ocaml
fmardini has joined #ocaml
<adrien_oww>
gasche: yeah, I made a local patch for that
<adrien_oww>
gasche: I haven't had time to try again to see whether that was enough to avoid the fact that -linkpkg was always given
<adrien_oww>
whitequark: you could use variants for that I guess
<adrien_oww>
possibly through fantom types
<whitequark>
adrien_oww: so basically Choose Your Own RTTI
<whitequark>
fantom types ?
<adrien_oww>
phantom* maybe
<adrien_oww>
well, not rtti at all
<adrien_oww>
but you'd ask for an argument like (`Width x, `Height y)
<whitequark>
oh no
<adrien_oww>
but I'm not sure I've fully understood how you wanted things to "appear"
<whitequark>
poorly chosen example
zpe has quit [Ping timeout: 245 seconds]
<whitequark>
so I have an inheritance tree for an SSA IR. at the lowest level there's value, and constant <: value, and instruction <: value
<ggole>
:> provides a narrowing coercion: not sure if it does what you want though
<whitequark>
now imagine I want to do constant folding. for this, I'd have to take two value-s, and check if they're both constants, and extract their content if they are.
<whitequark>
in Ruby, I did value.is_a?(SSA::Constant); value.get
<whitequark>
I imagine this is impossible in OCaml, unless I can somehow narrow the type from value to constant
<ggole>
Write to_constant : value -> constant option?
<adrien_oww>
I think I'd prefer to have variants to tag the elements
<adrien_oww>
rtti is not a very good api
<whitequark>
adrien_oww: unfortunately values must be mutable
<adrien_oww>
you could "attach" tags
<adrien_oww>
or use a record
<whitequark>
I've thought about using a combination of variants and records, but all of my sketches had astonishingly bad design
<whitequark>
I'm pretty positive I need classes here.
<ggole>
You could use a *spit* object
<adrien_oww>
your real use-case is certainly more complicated but usually you can do quite a lot with variants, polymorphic variants, records
* ggole
nods
<whitequark>
adrien_oww: I know. I spent a lot of time thinking about it and I'm almost entirely sure ADTs won't solve my problems.
<whitequark>
without creating worse ones.
<adrien_oww>
have you considered polymorphic variants too?
<adrien_oww>
(at least, trying to is a good way to learn how to use them well)
<whitequark>
yes
* whitequark
giggles.
<whitequark>
I just realized I can take camlp4 and add the kind of RTTI I want to ocaml.
<whitequark>
not sure if that's the best way to solve it, though.
<whitequark>
(check validity of conversion with camlp4-generated methods, and then use Obj.magic to do the, well, magic.)
<adrien_oww>
(am I the only to believe this will soon cause other issues?)
<whitequark>
(no. but I'd be really interested in examples.)
<ggole>
By "values must be mutable", do you mean you want the ability to change an x which is currently a value into a constant while maintaining the identity of x?
<whitequark>
ggole: no. I mean that the cleanest way to maintain use-def lists is to stash them inside values themselves
<ggole>
Hmm
<whitequark>
you could say that then I'm better with just records inside variants, but variants cannot be extended, and I want my library to be split between "basic" SSA operations and "language-specific" instructions
<whitequark>
then you could say that I can use a parametric module to inject language-specific instructions into basic SSA backbone, but that results in two levels of indirection, and the resulting pattern matching is incredibly unwieldy
<whitequark>
and so on. I can twist ADTs in various ways to achieve what I want, but then the code to work with all this becomes quite horrible.
<ggole>
I can't say I have a clear notion of the problem, but it does sound like something is wrong there.
<whitequark>
I can try explaining it more clearly and sequentally if you're interested
<ggole>
Sure, why not.
<whitequark>
ok. So, my language heavily relies on SSA IR transformations. I took the general SSA IR design from LLVM, which is probably the reason RTTI is natural for it, and it works very well for my use case.
<whitequark>
the IR is based on "values". Everything is a value: constants, instructions, basic blocks, functions, function arguments. Every value maintains a list of use-def chains, which are used for the basic replace-all-uses-of SSA transformation.
<whitequark>
*replace-all-uses-with.
<ggole>
OK, that seems a bit strange.
<ggole>
Basic blocks and constants aren't very similar things.
<ggole>
But go on.
<gasche>
whitequark: note that you can allow open-extension even with variants
<gasche>
you just have to add an open case to the closed list of cases
<whitequark>
naturally, this requires each value to maintain a set of its uses, respond to #add_use and #remove_use, and, for values which have operands (mainly, instructions), it must be possible to mutate operands
<whitequark>
gasche: such as type 'a value = Const | Instr | SomethingElse of 'a ?
<gasche>
type value = Const of ... | Instruction ... | Open of { ... }
<gasche>
where Open's record enumerate the methods in a way that allows to inject any implementation, object-oriented-style
<whitequark>
ggole: with that design, jump instructions refer to basic blocks as operands just as everything else.
<ggole>
Oh, I see
<whitequark>
ggole: it probably is also done this way because (GC)C allows to capture addresses of basic blocks, but it's convenient nevertheless.
<whitequark>
gasche: well, isn't that just reimplementing OO on top of ADT, poorly?
<whitequark>
I'm not sure of the benefit.
<gasche>
well
<gasche>
ADT model "closed worlds" well, with the accompanying benefits
<gasche>
OO models "open world" well, with the accompanying costs (eg. binary methods are hard)
<ggole>
whitequark: dead code removal would be nice and clean that way, too
<whitequark>
ggole: indeed
<gasche>
this model lets you have sum types for the part of your design that is closed
<whitequark>
I really like how this IR is quite generic.
<gasche>
but still leaves the door open for open-world uses
<whitequark>
gasche: the problem is that I want instructions to be open
<gasche>
without making you pay the open-ness costs for the parts that are statically known
<whitequark>
and matching of instructions is quite frequent
<whitequark>
so the benefit is marginal at best
<whitequark>
there are other problems, though.
<gasche>
but when/how would you match on the user-introduced classes?
<gasche>
(also it would help to have a toy usage-case to study where you write down precisely the extension situations etc.)
<whitequark>
gasche: in the user-introduced transformations, where user-introduced instruction classes are in scope.
* whitequark
nods
<whitequark>
so. as I've said, all values maintain use lists. so that'd be `type value = value list ref * value_content'
<whitequark>
value_content is a variant like this: `type value_content = Constant of Lang.value | Function of function | Basic_block of value list ref | User of value list ref * user_content`
<whitequark>
the most interesting part is, of course, User
<whitequark>
I have it distinct because I want the part of my code which maintains use-def list to be generic; as in, not replicating that bookkeeping code all the way round
zpe has joined #ocaml
<ggole>
Why the two value list refs for the User case?
<ggole>
(Er, and the Basic_block case)
<whitequark>
that'd be basic block content and user operands
<whitequark>
so, the main downside to this model is: even in a closed-world model, to get inside an instruction I have to pass three levels of indirection
<whitequark>
efficiency aside, that'd just be monstrous match clauses
<ggole>
Mmm
<whitequark>
with open-world model, that's four levels in some cases
zpe has quit [Ping timeout: 245 seconds]
ggole has quit [Ping timeout: 256 seconds]
Kakadu has joined #ocaml
<whitequark>
gasche: so, what do you think? is it rational to use "RTTI" in my case?
cago has joined #ocaml
hkBst has joined #ocaml
hkBst has quit [Changing host]
hkBst has joined #ocaml
ggole has joined #ocaml
zpe has joined #ocaml
lenstr has quit [Read error: Connection reset by peer]
zpe has quit [Ping timeout: 276 seconds]
ggole has quit [Read error: Connection reset by peer]
thomasga has joined #ocaml
ygrek has quit [Ping timeout: 264 seconds]
ggole has joined #ocaml
<Kakadu>
hi
<Kakadu>
in June `opam list` have printed list of all avaialble packages but now in opam-1.1.0 it shows only installed
<Kakadu>
installed ones
* Kakadu
confused
<Kakadu>
And it seems that `opam -help` hasn't been updated yet
zpe has joined #ocaml
Simn has joined #ocaml
<Kakadu>
(maybe these are problems after upgrade 1.0.1->1.1.0)
<thomasga>
Kakadu: indeed the behavior has changed
<thomasga>
but maybe not the man page ...
<thomasga>
use -a if you want to get all the packages
zpe has quit [Ping timeout: 264 seconds]
<Kakadu>
thanks
<thomasga>
Kakadu: I've fixed the description in my working branch, will do the merge properly later
<thomasga>
thx for the report
<gasche>
whitequark: I didn't understand enough of your example (eg. what User) is to comment
<gasche>
I am basically fine with any solution that is type-safe
<gasche>
using Obj.magic is a no-go
<whitequark>
I see
<gasche>
forcing yourself to keep things typesafe is a good way to constrain you into reasonable designs
<whitequark>
gasche: so you aren't fine with ocamlyacc? :)
asmanur_ has joined #ocaml
zpe has joined #ocaml
ygrek has joined #ocaml
asmanur has quit [Ping timeout: 276 seconds]
<gasche>
whitequark: I prefer to use menhir, and I would like menhir to be updated to use GADTs instead of Obj.magic when possible
tane has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
<flux>
I know I've switched from xml-light to using xmlm because xml-light uses Obj.magic :)
<ousado>
still there's quite a difference between a compiler emitting certain constructs and a human using them directly.
<whitequark>
I see
<whitequark>
ousado: I intended to, essentially, extend the language with a particular construct
<whitequark>
so it's not using magic directly, nor would it violate type safety
mcclurmc has quit [Quit: Leaving.]
<whitequark>
that being said, I think that polymorphic variants may cover most of my use case there
<flux>
let's say your program crashes due to segmentation fault. then you discover some library you used makes use of Obj.magic. uncertainty and fear arises.
<flux>
(the next or even first in the list would be a C library binding of course)
<ggole>
Let's program in C, where every operation is Obj.magic.
<ggole>
^
<gasche>
whitequark: there are ways to do safe RTTI using GADTs
<ousado>
if that library has been generated, you can probably fix all instances of that error by fixing the code-generator in one place
<flux>
and if that library isn't one you've written chances are it will take a lot of time to educate yourself in the internals of said library.
<ousado>
I think this argument is pretty straight-forward. should a human use assembly? probably not. should a compiler emit assembly? ymmv, but I think there might be reasons to do so
<gasche>
there are provably safe ways to use Obj.magic
<gasche>
which you may still get wrong (bugs happen all the time), but at least are theoretically justified
<flux>
indeed, but do you think xml-light could not have been written without Obj.magic?
<gasche>
(eg. when people were using Obj.magic to emulate then-missing GADTs)
<flux>
and wrong uses Obj.magic can result in difficult-to-track bugs
<gasche>
then there are the people that think that "this looks safe, let's use Obj.magic there"
<flux>
as they break all the guarantees the type system gives
<ousado>
that being said, I don't know anything abut OBj.magic, but I guess it's similar to 'Dynamic' in haxe, and such can be avoided in pretty much all cases that matter
<gasche>
and this is not ok
<gasche>
indeed flux, indeed
<gasche>
you could also have patched xml-light to avoid Obj.magic
<ggole>
Obj.magic is simply the identity function, typed as 'a -> 'b
<flux>
maybe, but xmlm is probably more mature anyway
<ggole>
You can imagine what sort of fun that might cause.
<flux>
it not using Obj.magic is one sign :P
<gasche>
I remember there were weird things in xml-light's code
<ousado>
so it's Dynamic
<ousado>
makes anything unify with everything else
testcocoon has quit [Quit: Coyote finally caught me]
<gasche>
ousado: with no runtime check at all
<ousado>
yes
<ousado>
does someone here know why menhir/ocamlyacc use it?
<flux>
probably to have some performance edge versus C versions
<flux>
(wild guess)
<gasche>
menhir comes from a research paper about how the invariants maintained by an LR parser can be safely encoded through GADTs
testcocoon has joined #ocaml
<gasche>
the authors, François Pottier and Yann Régis-Gianas, then decided to do an OCaml implementation demonstrating their work
<gasche>
but OCaml had no GADTs at the time, so they used an emulation of it using Obj.magic
<flux>
so I was wrong :)
<gasche>
since then menhir evolved nicely from research prototype to one of the nicest parser generators for OCaml
<gasche>
but nobody did the work of trying to change their code generator to use GADTs in 4.00
<flux>
if menhir were to use gadts it would probably be the most widely used gadt-based ocaml tool/library
<ousado>
didn't oleg come up with a way to encode GADTs before that?
<gasche>
there is a patch proposed on the bugtracker to reimplement Printf/Scanf/Format using GADTs
<gasche>
that would be even more widely used than menhir
<gasche>
and I think it is closer to be integrated (but nothing is certain yet)
<flux>
gasche, would it result in the format types being changed?
<gasche>
ousado: menhir predates Oleg's encoding, but one reason for not using them would be that they are less efficient than sum types + Obj.magic
<gasche>
flux: no
<gasche>
(the change would probably have been rejected earlier if it had changed the format types)
<gasche>
but it implements the format6 type using GADTs internally
<gasche>
instead of string + phantom types as currently
<ggole>
Doesn't Queue use Obj.magic for efficiency hacks as well?
<gasche>
yes, but that's a mistake
<gasche>
there are safe implementations that are equally efficient
<gasche>
a more interesting use is in BatSplay in Batteries
<ggole>
Has that changed at some point, or was the initial implementation just wrong-headed?
<gasche>
I'm not exactly sure what "wrong-headed" means, but the author of Queue did premature optimization
<gasche>
(I believe it was François Pottier again)
<gasche>
as it is a provably safe use of Obj.magic, nobody bothered to change the implementation
hkBst_ has joined #ocaml
<ggole>
I see.
<ousado>
I can't think of cases where Obj.magic would improve performance that couldn't be improved by an optimization in the compiler
Kakadu_ has joined #ocaml
<gasche>
ousado: except it's unclear anyone is willing or able to implement that optimization
hkBst has quit [Remote host closed the connection]
Kakadu has quit [Remote host closed the connection]
<gasche>
besides, there are cases where you need something unsafe in any case (eg. when extracting from Coq that uses a strictly richer type system)
<ggole>
Hmm, what's the safe implementation of Queue?
<ggole>
The obvious approach is to have an option for tail
<gasche>
François told me he had made an implementation with list of arrays that was faster and safe
<gasche>
I haven't looked at the code myself
<ggole>
Ah, I see
<ousado>
well, that's a gain a case of a compiler emitting unsafe code.
<ousado>
*again
q66 has joined #ocaml
zpe has joined #ocaml
<whitequark>
I wonder what will happen if I find a collision between hashes for two polymorphic variant names
<whitequark>
that doesn't sound as very hard. probably even brute force will work.
zpe_ has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
<gasche>
whitequark: there are known collisions reported on the bugtracker
<gasche>
the compiler will reject programs that have collisions in them
<gasche>
and the user must change one of the names
<gasche>
whitequark: if you want to use polymorphic variants for your use-case
<gasche>
you *must* read Jacques Garrigue's article, "code reuse through polymorphic variants"
<gasche>
in particular, it uses an open recursion pattern that you will probably need as well
mfp has quit [Quit: Leaving]
<whitequark>
gasche: thanks
<whitequark>
I will
<ggole>
That's a hack for independent compilation, I take it
<gasche>
if you're talking of variants conflict checking, I suppose it may be done at link-time
<gasche>
I don't know the details
rossberg__ has quit [Quit: Leaving]
mort___ has joined #ocaml
mcclurmc has joined #ocaml
avsm has joined #ocaml
<yezariaely>
I didn't get the full discussion but: why not use polymorphic variants only internally and provide "normal" ADTs for the interfaces outside and convert them?
<Kakadu_>
guys, where should I look for examples about $list...$ antiquotation in camlp5?
dsheets has joined #ocaml
cago1 has joined #ocaml
tane has quit [Quit: Verlassend]
cago has quit [Read error: Operation timed out]
<ousado>
Kakadu_: do you need compatibility with ocaml 3.09 and earlier?
<Kakadu_>
Noooooooooooooooooooo
<ousado>
why don't you use camlp4 then?
<Kakadu_>
because I'm hacking library which is already built over camlp5
<ousado>
ok :)
kerneis has joined #ocaml
<kerneis>
hi
<kerneis>
does anybody know when Dynlink.init has been deprecated? the Changes doesn't mention it
<kerneis>
Date: Tue Apr 22 12:24:10 2008 +0000
<kerneis>
sorry for the noise
<avsm>
kerneis: when alain implemented Natdynlink, iirc
<kerneis>
yes, more or less
<gasche>
avsm: do you know the frequency of github/ocaml/ocaml resynchs with the SVN trunk?
<avsm>
gasche: hourly iirc
<avsm>
59 * * * * cd ~/ocaml.org-scripts/ && ./sync.sh
<gasche>
ok
<gasche>
thanks
<avsm>
can do it more frequently, but that seemed a bit rude to the poor svn server
<avsm>
which reminds me. must add 'install gitlab' to the TODO for a self-hosted mirroring service
<gasche>
I saw that in that heated mailing-list thread
<gasche>
I'm a strong supporter of not relying on github
<gasche>
wanted to mention that, but never got the occasion
<gasche>
I dislike using a proprietary service in a crucial place of my open-source workflow
<gasche>
I wish the projects I contribute to would consider a different platform
<gasche>
(I've used gitorious so far, which is sensibly less usable than github. Self-hosted gitlab may be a better option.)
<orbitz>
It's git, you're not a slave to github any morethan you want to be :)
<gasche>
that's not so true when github's Issue tracker effectively killed your project mailing-list, and the only known way to contribute something is "send a github pull request"
<gasche>
it is pretty much impossible to do anything around OPAM without using github
<gasche>
(for example)
<avsm>
Like all services, Github's an enabler to give it a short-term boost
<orbitz>
I don't think it's so bad, github is realtively enjoable to use and since all the data is on git you can pivot pretty trivially
<avsm>
It's not sensible to blindly say "dont depend on third-party services"
<gasche>
I get the cost-benefit considerations that make github a good option
<avsm>
However, the long-term concern is definitely true, hence my scripting to save all Github metadata (via their excellent API) so that we can reconstruct it later
<gasche>
I'm just saying that, long term, I'm a strong supporter of alternatives
<avsm>
long-term plans require short-term work as well though :)
<avsm>
I'd welcome anyone who evaluates alternatives to drop a note to the infrastructure list
<avsm>
yallop did recommend gitlab, so I'm trying that out
<pippijn>
hi avsm
<gasche>
nobody would switch from github if they didn't have helpful people producing or suggesting alternatives, and some less-helpful whiners to occasionally create an ambiant pressure to not consider this the end goal
<gasche>
I'm doing the whiner
<emias>
orbitz: That's only true if you consider issues, pull requests and related discussions non-essential.
* emias
is good at whining as well!
<pippijn>
avsm: I forked some of your projects, yesterday, with the intention of adding debian/ubuntu packaging, but I failed :\
<avsm>
pippijn: oh; i'd prefer an OASIS->Debian if at all possible (btw, I think you might have forked my working trees — the masters are usually at mirage/*)
<pippijn>
oh
<avsm>
pippijn: if you do come up with an OASIS->Deb/RPM tool though, I'll be an eager first user. I'd love to have the Ubuntu PPA for all these
<kerneis>
(google images seems to agree with google translate)
<Kakadu_>
When I load camlp4/5 into toplevel is it possible to use `-loc _loc` option of camlp5o?
_andre has joined #ocaml
<adrien_oww>
train station, german :-)
<ousado>
right :) forgot to mention that
cago1 has quit [Ping timeout: 245 seconds]
avsm has quit [Quit: Leaving.]
cago has joined #ocaml
milosn_ has quit [Ping timeout: 248 seconds]
sgnb` is now known as sgnb
malo has joined #ocaml
mort___ has quit [Ping timeout: 276 seconds]
avsm has joined #ocaml
<avsm>
hrm, that .cmi thread reminds me that we dont have an ocamlbuild target for .cmt{i} either
<avsm>
not entirely sure how to add that, since it pulls in the bin_annot tag but is really a sideeffect of a cmi compilation
<avsm>
gasche, any ideas?
Anarchos has joined #ocaml
<Anarchos>
if i want to call caml_c_thread_unregister when my C thread exits, may i achieve this by calling pthread_cleanup_push(void (caml_c_thread_unregister, null); at the beginning of the thread ?
PM has quit [Ping timeout: 246 seconds]
PM has joined #ocaml
demonimin has quit [Ping timeout: 246 seconds]
demonimin has joined #ocaml
ygrek has quit [Ping timeout: 256 seconds]
Qrntz has quit [Ping timeout: 264 seconds]
Qrntz has joined #ocaml
Drup has joined #ocaml
milosn has joined #ocaml
<whitequark>
are there any guarantees on how the string literals laid out?
<Kakadu_>
Guys, Is it possible to create a list in camlp5 without code like
<Kakadu_>
let listify2 ys = List.fold_right (fun x acc -> <:expr< $x$ :: $acc$ >>) ys <:expr< [] >> in
<Kakadu_>
?
<Anarchos>
whitequark they are sequence of characters followed by 1,2,or 3 null characters (due to ocaml values alignment restriction)
<Kakadu_>
My problem: when I use line above in toplevel it seems to be OK but when I compile it in source file it points to
<Kakadu_>
":: " and doesn't compile
<Kakadu_>
syntax extension is big and not easy to compile. No idea how to show it to you yet
introom has quit [Remote host closed the connection]
wmeyer has joined #ocaml
<wmeyer>
Hi
<ggole>
Strings have a byte at the end describing the amount of trailing padding iirc
<ggole>
(Minus one to keep zero-termination?)
<wmeyer>
why do you need it?
<wmeyer>
there is no string termination
<wmeyer>
string is continous block in ocaml
<wmeyer>
with a usual length
<ggole>
Somebody was asking how strings are laid out
<whitequark>
Anarchos: sorry, got distracted and didn't finish the question
<Anarchos>
whitequark no problem
<whitequark>
for example, can I rely that "a" == "a", if the "a" literals are defined in arbitrary parts of the project ?
<whitequark>
I've considered using nullary polymorphic variants for that purpose, but they can have collisions
<whitequark>
it's not very practical question, just curiosity
<ggole>
No
<whitequark>
I think that for practical purposes variants are much better
<ggole>
module A = struct let s = "a" end module B = struct let s = "a" end A.s == B.s
<whitequark>
oh, I see
<whitequark>
thanks
<Anarchos>
whitequark in ocaml code ?
<whitequark>
whitequark: yes
<ggole>
In fact, I don't think ocaml will merge strings at all
<Anarchos>
ggole whitequark A.s = B.s ==> true;;
<whitequark>
it's false for me
<ggole>
That's structural equality
<whitequark>
oh, =
<Anarchos>
whitequark (==) is for physical equality and (=) is for logical equality
cago has quit [Quit: Leaving.]
<whitequark>
Anarchos: yeah, I was talking about ==.
<Anarchos>
whitequark i got false too with (==) in a toplevel (just did the test)
<pippijn>
# "a" == "a";;
<pippijn>
- : bool = false
<adrien_oww>
(of course)
<pippijn>
merging strings only works if they are read only
tane has joined #ocaml
<pippijn>
"a".[0] <- 'b';; is fine
<ggole>
That's such an ugly thing with literals -_-
<whitequark>
well, exactly
<ggole>
And inconsistent with array literals
<whitequark>
since they aren't copied _anyway_, I expected them to be merged
<whitequark>
ggole: you can introduce values in array literals, but not string ones (no splicing)
<pippijn>
ggole: inconsistent?
<ggole>
Array literals construct a new array every time they are evaluated
<ggole>
String literals do not
<pippijn>
oh
<pippijn>
that's bad
<pippijn>
I didn't know that
<ggole>
It'd be fine if strings were immutable... but that's an old complaint
<pippijn>
I treat them as immutable
<pippijn>
except when they are used as buffers
<pippijn>
so I never run into that problem
<ousado>
urgh
<ousado>
that's horrible
<whitequark>
it's also quite a bit of speedup
<whitequark>
and for example Ruby (the more performant implementations :) runs into a bag of problems with copying of string literals
<whitequark>
so I can totally see why it was done this way
<ousado>
errm..
<ggole>
The clean thing would be to have a mutable buffer type and immutable strings
<whitequark>
personally I would like something along these lines: two typeclasses, mutable_string and immutable_string; string literals belong to immutable strings by default
<ggole>
(A nice buffer type, not that awful Buffer.t thing.)
<whitequark>
(unless you copy them)
<ousado>
let s () = "s"
<ousado>
being able to make that return something different from "s" is just wrong
<pippijn>
whitequark: type mutable type immutable type 'mutability string
<whitequark>
pippijn: oh, awesome
<pippijn>
val get : 'm string -> int -> char
<pippijn>
val set : mutable string -> int -> char -> unit
<pippijn>
etc.
<pippijn>
it's probably not a good idea to allow aliasing between mutable and immutable strings
<pippijn>
so making a mutable string immutable involves copying
<ggole>
You could also indirect in the string type
<ggole>
Probably not worth it though
<pippijn>
very probably not worth it
<pippijn>
the indirection will probably cost too much
<ggole>
I'm still thinking in terms of a buffer type, where you already have indirection and might want storage stealing as well
<ggole>
Silly idea for strings.
<pippijn>
ah
<pippijn>
sure
<pippijn>
if the buffer type is more closely integrated with the language, then strings and buffers can have the same representation (data + string length + allocated length)
<ggole>
I don't think that works. If you reallocated, how would other references to the buffer know where the new data was?
<pippijn>
no
<pippijn>
the buffer has an indirection
<pippijn>
but you can steal the internal string and make a "string" out of it
<ggole>
Yeah, that would work
<pippijn>
that wouldn't work for the current buffer representation
<pippijn>
Buffer.contents must copy unless allocated length = string length
<pippijn>
for current string* representation
<gasche>
Kakadu_: the revised syntax for list cons is [a::b] instead of a::b
<ggole>
Hmm... you can imagine an interface to tell the allocator that the end of the storage is no longer in use
<gasche>
so you need to add brackets there
<pippijn>
gasche: I don't like that syntax
<pippijn>
it's weird
<pippijn>
[a;b] and [a::b]
<gasche>
I also don't like it
<pippijn>
the latter feels like you're making a list of lists
<pippijn>
with a single list in it
<ggole>
(I think it would need to place some info there so that the GC knows the meaning of the dead storage)
<gasche>
there are good and bad things in the revised syntax
<gasche>
I'd be very interested in currified constructors
<gasche>
I mostly don't care about the rest
<gasche>
(and having parametrized types in the reverse order would be nice to exchange code which just everyone else, though I don't dislike OCaml choice)
<pippijn>
gasche: I quite like how currified constructors in coq are put into ocaml
<rks`>
gasche: I'd also love to have every match end with the "end" keyword
<pippijn>
the generated code is nice
<rks`>
(so "match .. with .. end", "try .. with ... end")
<gasche>
rks`: reasonable
<pippijn>
ggole: right, when you turn it into a string, you can be sure that dead storage is dead forever
<gasche>
though "begin match" serves me well
<Kakadu_>
gasche: ah. Me nooob. thnaks
<rks`>
gasche: yes, I use that as well
<rks`>
but I wouldn't be against having a "closed" form by default :)
<pippijn>
I like to say "string list"
<gasche>
I like it as well
<ggole>
pippijn: the thing I was concerned about is that the GC will look at the string header and scan that many words to get to the next object... which will be the former bytes of the string unless something is done.
<pippijn>
but yes, most other languages say "list of string"
<gasche>
but it's painful when you, say, write papers to be read by both an OCaml and Haskell audience
<ggole>
I think you could handle that, but it is a bit hacky.
<gasche>
so long-term I think "list string" is the better choice
<gasche>
(also it's easier to read when you move to higher-kinded types)
travisbrady has joined #ocaml
<ggole>
Let's move to a whitespace sensitive syntax and get rid of end entirely.
* ggole
ducks
<gasche>
(but I would agree that everyone writes function application in the wrong order, it should clearly be (x)f)
hkBst_ has quit [Quit: Konversation terminated!]
<gasche>
ggole: I've actually implemented whitespace-sensitive syntaxes for OCaml as Camlp4 extensions
<ggole>
How did you like them?
<gasche>
they were prototypes that would have to be roughened out for real use, but I never released them because having more syntaxes is harmful or ignored at best
<gasche>
as you said, indentation-sensitivity allows to have more delimiters without being heavier on the eye
<ggole>
Yeah
<gasche>
I think that's a good idea (Haskell's choice to have a way out for code generators is good)
<ggole>
You could lose a lot of the 'in', 'with', 'do', 'done' clutter
<ggole>
I'm not convinced that it is a good idea though
<ggole>
The ability for an editor to reindent code is a nasty loss
<ousado>
if you can transform all of them to/from some form it's ok
<Anarchos>
gasche why wrong order ?? It is just a matter of convention indeed
<gasche>
Anarchos: f(x) is more convenient for people that write from right to left
<ggole>
Not to mention that modules and functions already take their arguments in "traditional order"
<gasche>
you see this when you try to write down the type (currified or not) of the composition function
<Anarchos>
gasche so why is it wrong to write it left to right ?
<gasche>
you want to write
<Drup>
Armael: because when you write g(f(x)), you apply g before g
<gasche>
compose : (A -> B) -> (B -> C) -> (A -> C)
<Drup>
f before g*
<gasche>
but that doesn't work
<gasche>
because function application is in the wrong order
<gasche>
I think Leibniz used the right order, and some categoricians do that, using ; for reversed composition
<ggole>
Wouldn't you write the type the other way too?
<gasche>
well
<gasche>
with x(f)
<ggole>
(C <- A) <- (B <- C) <- (B <- A)
<gasche>
x has type A, f has type A -> B, the whole thing has type B
<gasche>
makes sense
<gasche>
ggole: reversing the sense of the arrows is one way to make the current order "right"
<gasche>
some people do that
<ggole>
(For full affect, please mentally align that to the right of your irc channel.)
<ggole>
Hmm.
<gasche>
as you see, it makes sense for semitic languages where you write right to left
<Anarchos>
gasche in the source code of the compiler (driver.ml), you can find let (++) x f = f x to achieve reverse order notation
<gasche>
yep
<gasche>
or the piping notation (|>) in some places
<ggole>
Funny how these things become so baked into everything else.
<Armael>
Drup: meh.
<Anarchos>
gasche but there is no better notation since they each have their own drawbacks
lenstr has joined #ocaml
<gasche>
well
<gasche>
the order of the function arrow is an arbitrary choice
<gasche>
but once you've picked it, the order of function application should follow
Drup has quit [Read error: Operation timed out]
<gasche>
I don't see any advantage of picking the one that doesn't make the composition type natural, except of course history and compatibility with other readers/writers
<gasche>
that said
<gasche>
I've too much things to do to troll mathematical notations on IRC :-'
<gasche>
I've been trying to make modular ocamlbuild plugins work, but no success this morning
<Anarchos>
gasche you can't be wrong against centuries of mathematical evolution, do you ? ;)
<ousado>
I want to read which function is applied before reading to which arguments
mort___ has joined #ocaml
ygrek has joined #ocaml
Drup has joined #ocaml
travisbrady has quit [Quit: travisbrady]
travisbrady has joined #ocaml
<Anarchos>
ousado we were all trained like that in math lessons :)
<ousado>
I'm not sure it's just a matter of training.
<ia0>
I didn't read everything, but to the last post: We usually write left to right, so we usually write A -> B
<ia0>
If we were writting the other way around we might have chosen the other way around or not
hto has quit [Ping timeout: 264 seconds]
hto has joined #ocaml
mort___ has quit [Ping timeout: 276 seconds]
<ousado>
Anarchos: my reasoning being this: when encountering a function and after it the arguments, one can trivially put the arguments into context. If one reads the arguments first, and doesn't know yet what they're for, it's more likely to have to go back and read the arguments again.
<Anarchos>
ousado i know :)
<gasche>
when programming, both styles are preferred at times
<gasche>
sometimes the argument is more important, sometimes the function
<gasche>
some languages fix word orders in ways that force you to put the subjects and objects before the verb, and no native learner would find that impractical
<gasche>
(you have to stack the whole sentence for comprehension which limits their complexity to a reasonable amount, but that's a good practice anyway and other fixed word-orders rarely do better)
<ggole>
You could program in APL (or Joy) where the issue is entirely moot.
<ggole>
APL programmers might even argue that it is easier to read.
<gasche>
I've tried stack languages before
<ggole>
Same - never clicked for me.
<gasche>
I don't think the point-free style is such a good idea in the general case
<gasche>
but I've never tried array languages
<gasche>
re. stack-based languages and point-free styles: it can be the best choices locally in some places
<ggole>
The reduction in boilerplate can be quite astonishing
<ggole>
And trying to comprehend the result of even a short programming session can be equally astonishing
<ggole>
Mind you, I'm not a serious user of an array language: apparently you get used to the idioms after a while.
fmardini has quit [Ping timeout: 245 seconds]
<gasche>
ggole: I suspect much of this can be encoded succesfully in the right abstractions in a general-purpose functional language such as OCaml and Haskell
<gasche>
reserved for the problem domains that it fits well, and avoided the rest of the time
leroux has left #ocaml []
<gasche>
(I had a bit of the same conclusion about Prolog; there is a paper about how teaching logic programming in Haskell rather than Prolog is actually helpful to students)
<gasche>
("Escape from the Zurg" or something like that)
<ggole>
Embedding Prolog in other languages seems somewhat common
<ggole>
There are a few Lisp libraries for logic programming, and Clojure has core.logic in its standard library
shinnya has joined #ocaml
<ggole>
Never seen anything like array languages embedded though
<gasche>
embedding stack-based languages is rather easy, I don't know for array languages
<gasche>
I guess they're too arcane for people to have bothered
yezariaely has quit [Quit: Leaving.]
<ousado>
I'd still argue that there's an impact on the performance of comprehension. in some natural languages it's possible put important info at the end of sentences, in a way that makes it impossible for a simultaneous translator to start translating the sentence without having heard it completely
<ggole>
Operations like reduce and scan are originally from APL, I think
<ousado>
.. I'm pretty sure that's equally true for programming languages
<ggole>
It's been influential if not widely adopted.
<chris2>
where does opam store which files belong to which package?
<whitequark>
ggole: what about embedding forth?
<whitequark>
you are probably used it several times last week. perhaps more.
<whitequark>
oh, nevermind, misread that
<ggole>
I guess you're referring to Postscript?
Kakadu_ has quit [Quit: Konversation terminated!]
alang_ has joined #ocaml
introom has quit [Remote host closed the connection]
alang has quit [Ping timeout: 276 seconds]
vbmithr_ is now known as vbmithr
Xom has quit [Ping timeout: 264 seconds]
Anarchos has quit [Ping timeout: 276 seconds]
skchrko has quit [Quit: Leaving]
<levi>
gasche: Haven't you seen points-free style Haskell? It's very APL-like.
<levi>
I started reading a tutorial for J, which is sort of the modern incarnation of APL. It's pretty interesting.
<levi>
You have to memorize a lot of stuff before you can read much code, but it follows a very regular structure.
Qrntz has quit [Changing host]
Qrntz has joined #ocaml
thomasga has quit [Quit: Leaving.]
<whitequark>
anyone familiar with camlp4 ocaml parser here?
<whitequark>
I can't seem to understand where exactly it handles patterns with "when"
<whitequark>
in Camlp4OCamlParser.ml
<whitequark>
oh, it inherits grammar from RevisedParser, it seems
<gasche>
yes
<gasche>
levi: there are a lot of things that look like point-free style
<gasche>
we cited stack-based languages before (Forth, but the modern incarnation would be Factor, or Cat)
<gasche>
John Backus also had point-free languages
<gasche>
(he describes one in his Turing Award lecture, I don't remember the name, it was never used)
<gasche>
I'm confident array-based languages are related to point-free style but I wouldn't expect them to be "just like it"
<gasche>
(in the sense that it's not enough to get the idea: you also need to know the base combinators to have a mental model of what it's like; I don't)
<levi>
gasche: Backus's language was called FP.
zpe has quit [Remote host closed the connection]
Anarchos has joined #ocaml
avsm has quit [Quit: Leaving.]
levi has quit [Read error: Connection reset by peer]
levi has joined #ocaml
ttamttam has joined #ocaml
ttamttam has quit [Client Quit]
Sim_n has quit [Read error: Connection reset by peer]
* Anarchos
finally did a proof of concept for interfacing OCaml with a C++ multithreaded API
zpe has joined #ocaml
<Anarchos>
Now i have a graphical app with 6 threads and all the work is done in ocaml
<orbitz>
Anarchos: awesome
<orbitz>
what GUI API?
<Anarchos>
orbitz Haiku API (the reimplementation of BeOS)
<orbitz>
ah ok
<Anarchos>
each window launches its own thread to receive message from the OS
<orbitz>
I have this dream to make a GUI API that is like X11-lite, where each app is a GUI process and a business logic process
<Anarchos>
orbitz i did it before you and trust me, it was not trivial
<Anarchos>
orbitz and i may experience some bugs in the future...
<orbitz>
The trick is defining hte correct wire protocol
<Anarchos>
orbitz but i think my work is stable enough to go public :)
<Anarchos>
wire protocol ?
<orbitz>
yes for your business logic to talk to your GUI
cdidd has quit [Remote host closed the connection]
darkf has quit [Quit: Leaving]
<adrien>
orbitz: X11-lite, you mean mostly Wayland?
<orbitz>
I'm not sure
<orbitz>
In this case every GUI program woudl be composed of a running business logic process and a generic GUI proc, and teh BL proc tells the generic GUI proc what to do. That way you can go from GTK to QT without changing a line of code. all the cross process gunk is hidden in another proc
<orbitz>
and also you are just communciating over FDs os integrating event loops is a non issue
zpe has quit [Ping timeout: 276 seconds]
<orbitz>
I'll neer write it, and i'm sure it woudln't work out as well in practice than in my head, but one of the ideas i have in my brain
<Anarchos>
orbitz i just reused the haiku API and focused on hte communication with ocaml GC !
<adrien>
but its issue is that you're limited to what's common to each of them
<orbitz>
does wxWidgets run as a separate process?
<gasche>
if you have helpful comments to make here or there, I would be interested
<orbitz>
adrien: yep i know
<adrien>
not a separate one
<adrien>
just mentionning an issue :-)
<orbitz>
then no, not like wxWidgets
<Drup>
gasche: the closest I know is "wall of text" :)
<orbitz>
The add-value in the design in my head is: switching toolkits is a simple as switching which generic gui proc you run. Integrating event loops is a nonissue sinceeveryone knows how to wait on an fd
<Anarchos>
orbitz just use select :)
<orbitz>
that sucks a lot
<orbitz>
since people don't like to expose their fd's
<rks`>
gasche: « looking in _tags for tags that would apply to "myocamlbuild.ml" » wow
<rks`>
that's... surprising.
<orbitz>
anyways, no bigdeal, i'm not interested enough in GUIs to try to implement it
<orbitz>
my latest thing is a workflow engine!
<adrien>
gasche: reading, "add can add"
thomasga has joined #ocaml
<gasche>
does anyone know if wmeyer is gone on holidays?
<rks`>
gasche: the "composable subprojects" thingy looks... I was going to say "unrealistic" but I'll settle for "non trivial"
<orbitz>
gasche: i don't recall him saying anything
<rks`>
don't think so either
<adrien>
gasche: he's there sometimes but he escapes quickly
<adrien>
seems to be on the run
hto has quit [Read error: Operation timed out]
<gasche>
ok
<adrien>
probably noticed I'd try to catch him as soon as I could
<orbitz>
is wmeyer wanted in 7 countries?
<adrien>
at least!
<rks`>
gasche: I'd be against introducing "_plugin_tags"
<rks`>
there are already so many files (_tags, .mllib, .mlpack, myocamlbuild.ml, whatever) to edit, I wouldn't like to see one more
<gasche>
I don't think that is a good argument
<rks`>
(and yes I know, I can ignore most of them most of the time, but that's not the point)
<rks`>
gasche: why is that?
<gasche>
well
<gasche>
having two separate files to fit two different purposes is better than non-optimally mixing them in one
<gasche>
the perceived cost of having one more file is subjective, not objective
hto has joined #ocaml
<rks`>
my point is (in essence): it already looks complicated for new users, don't make it more complicated
<gasche>
in practice nobody care if it's documented well-enough
<rks`>
sure, sure
<gasche>
(which is not currently the case, admitted)
<rks`>
(yep)
<gasche>
the problem with doing this in _tags is that you get all the "true: foo" stuff to cover myocamlbuild.ml as well
<gasche>
which feels wrong
<rks`>
yes
<gasche>
wronger than having a different kind of file, I think
<gasche>
besides, if you don't want to edit one more file, you can pass plugin options on the command-line
<rks`>
as I said
<rks`>
"I know I don't have to"
<rks`>
:p
<gasche>
(but soon you'll get tired to do that each time, and you will wonder were to put that information; it cannot go into myocamlbuild.ml, and it's surprising to put it in _tags, so you look at the documentation)
<rks`>
well, yes indeed, it _is_ surprising to put in _tags
<gasche>
in fact it could go in myocamlbuild.ml if my proposal to allow directives-like headers at the top of .ml files had generated more interest on the ocaml-platform mailing-list
<gasche>
rks`: so where would you put it?
<rks`>
haha, nice story, "you look at the documentation"
<rks`>
wish that were true
<Anarchos>
rks` i look often at the ocaml manual
<rks`>
gasche: I don't know, I was merely agreeing with your point
<Anarchos>
rks` but rarely in general :)
<rks`>
you kinda convinced me with the "it's surprising to put it in _tags"
<adrien>
gasche: I'd avoid plugin_tags
<rks`>
gasche: I didn't see that thread on platform, when did you create it?
avsm has joined #ocaml
<adrien>
gasche: I wouldn't mind having to pass the related tags on the command-line
<Drup>
my opinon is that, as long as it's documented, I doesn't matter
<adrien>
it's a one-time operation, simple and probably would fit in 80 chars
<Drup>
It*
<adrien>
and everyone already uses make to call ocamlbuild
<rks`>
true.
<rks`>
Drup: oh but it does :D
<Drup>
adrien : well, that's a sign of a problem with ocamlbuild cli ...
<adrien>
also, it parallelizes better on my fingers
<adrien>
("make" that is)
<Drup>
adrien : and the fact the cli is hideous and that you can't define a default target for ocamlbuild ....
xavierm02 has joined #ocaml
<xavierm02>
hey
<rks`>
Drup: no, it's just that when you "ship" your project to anyone
<rks`>
people are used to run "./configure ; make"
<rks`>
:)
<Drup>
that's not true anymore for a non trivial number of developer community.
<adrien>
agreed
<adrien>
they look it up on the internet
<adrien>
instead of reading README and INSTALL
<xavierm02>
I'm trying to enumerate the cartesian product of two enumerable sets (that can be finite but don't have to) with an Enum from betteries given two Enums. Is there a very simple and elegant way of doing this? At the moment, I'm trying to do something with a list to store the first n elements of the left set and then I just reset the right_enum, get all the couples untill the list is empty, take a new element from the right_enu
<gasche>
xavierm02: I don't think you can do much better than that
gnuvince- has quit [Remote host closed the connection]
<gasche>
Enum are inherently tuned for linear workflows (traversing the data only once)
<xavierm02>
yeah
<gasche>
you have an inherently quadratic workflow in one of the two enums
<xavierm02>
that's why I keep the list
<gasche>
so you'll have to keep intermediate structures
zpe has joined #ocaml
<xavierm02>
okay :(
<avsm>
does ocamlbuild not generate symlinks when run in non-interactive mode
<avsm>
blasted thing is driving me insane as usual
<gasche>
sometines ocamlbuild fails to generate symlinks, I haven't looked at the reasons yet
<gasche>
(eg. when creating .cma iirc)
<avsm>
or binaries, or bytecode :-/
<avsm>
but no idea when
<gasche>
file a bug report :)
<avsm>
not even sure what to file it about yet
skchrko has joined #ocaml
<gasche>
agreed, getting a repro case is hard
zpe has quit [Ping timeout: 276 seconds]
<avsm>
hm, sometimes, it appears to do nothing at all, but not return a non-zero exit code.
* avsm
ponders
<gasche>
I've been reading the ocamlbuild code yesterday
<gasche>
it's a bit strange at places, but actually reasonable
<gasche>
(I wish some of the design decisions were better documented, though)
<avsm>
that's really weird. It's creating .native files without a+x set
<avsm>
-rw-r--r-- 1 avsm staff 11377856 5 Aug 17:58 sum.native
<avsm>
not seen this particular thing before
<avsm>
I dont really understand the virtual path solver. it's totally opaque
<gasche>
you've certainly looked deeper than me
<gasche>
I haven't look much at virtual paths yet
<gasche>
*looked
<avsm>
was trying to figure out the order of flag filling in, iirc
<avsm>
the hole thing is great until you have link order problems
dsheets has quit [Ping timeout: 248 seconds]
<gasche>
ocamlfind should take care of that :-'
<gasche>
avsm: I've been thinking at this -use-ocamlfind by default thing
<xavierm02>
about my problem, never mind. I just had to use doubly-linked lists and everything gets easier :)
<gasche>
I used to think that wmeyer was a bit prematurate in putting that in trunk, given your reserves
<avsm>
my reservations are more around getting rid of yet another shell-out in the toolchain
<avsm>
if everything were libraries, and we had an ocamlmkcompiler, that would be ideal for me
<gasche>
nowadays I think that through collaboration with Gerd we should be able to get good performances in the -use-ocamlfind cases, by changing the way we get information from ocamlfind/findlib in non-observable ways
<avsm>
just build a custom front end for your project
<avsm>
well, you'll need to cache the findlib outputs for a batch of pkgs
<avsm>
that's kind of tricky in the current ocamlbuild
<avsm>
unless you create virtual targets for them
<kerneis>
avsm: aren't you supposed to be in a pub right now?
<gasche>
Gerd proposed to have a way to discuss with a findlib program through a pipe
<avsm>
i am! i'm here by myself doing POPL reviews since the rainstorm has delayed everyone else :)
<kerneis>
ha
<kerneis>
yeah, I gave up because of the rain
<gasche>
instead of caching on the ocamlbuld side, the first step would be to discuss on a pipe instead of invoking other ocamlfind processes
<avsm>
kerneis: weaaaak. hope the agda course was good
<kerneis>
it was
<gasche>
that would replace the shell-out cost by some communication
<gasche>
but it may be enough
<avsm>
gasche: keeping a persistent ocamlfind open across targets? seems a hack on a hack
<gasche>
in any case, I won't personally do any shell-out-cost changes before getting the hand on a repro case (e.g. trying to build mirage)
<gasche>
avsm: during a single ocamlbuild run
<avsm>
almost noone needs to vary their findlib targets across targets. why not just calculate it at configure time, and never talk to ocamlfind again...
<adrien>
somehow, caching sounded easier
<orbitz>
avsm: Btw, <rant>The CUFP registration page is a UX nightmare, I simply can't tell if i've actually signed up for CUFP or not</rant>
<avsm>
orbitz: not me! complain to Sperber and Marius! :)
<kerneis>
gasche: about ocamlbuild, I find the code very hard to read because it uses partial applications to a certain level of madness
<kerneis>
at least in the ocaml-specific part
<orbitz>
avsm: I'm complaining vicariously!
<gasche>
ah yeah
<avsm>
orbitz: sorry about that though. It was a bad decision to use Drupal a few years ago for the new site
<gasche>
kerneis: but at least it's not semantics-relevant, right?
<gasche>
hm
<gasche>
maybe it is with the memoized parts
<orbitz>
avsm: it's not drupel per se, it's just that the actual atble where you choose things is impossible to udnerstand
<avsm>
kerneis: yeah, and I *love* that the ~tags argument in rules is completely ignored
<gasche>
I'll get rid of that
<orbitz>
There are checkboxes in weird spots, i don't know what they mean
<avsm>
i think i uploaded a patch that did that on some ticket
<kerneis>
gasche: I sent a patch a few days ago, very simple
<avsm>
orbitz: those are the "secret talks y/n" for special people checkboxes
<orbitz>
well i feel special, just not in the positive way, trying to sign up
<gasche>
kerneis: for some reason I hadn't seen that
<kerneis>
no problem
<avsm>
isn't it via ICFP though, not the CUFP site?
<orbitz>
yes
<kerneis>
I also emailed Damien about the Target Version but didn't get a reply yet
avsm has quit [Quit: Leaving.]
<gasche>
kerneis: two things
<gasche>
(1) it may be safer from a backward-compatibility p.o.v to raise a warning instead of an error (but I don't really see a reasonable case where people would depend on this particular behaviour, as non-buildable .mllib seem strange)
<gasche>
(2) it may be papering over a wider design defects; maybe some rules should always be assumed to work when there is clear user intent that it's the way to go (eg. when a .mllib and .mlypack is there, it should not fail)
<gasche>
the patch in itself looks fine (and it's nice that ocamlbuild makes this so easy to expression), but I suspect it's not the end of the story
<kerneis>
(1) strongly disagree
<kerneis>
there is no backward-compatibility
<kerneis>
if your .mllib is broken, this is a bug on your side
<kerneis>
fix it or get rid off it
<gasche>
my notion of backward-compatibility is "what worked in the past should continue to work", without any regards to how sane it was or why it actually worked
<kerneis>
(2) agreed
<gasche>
but I'd agree that in this case we could decide to forget about this
<kerneis>
there is some notion of precedence between rules
<kerneis>
"if this one applies, this other should not"
<kerneis>
that cannot be expressed by ocamlbuild currently
<kerneis>
(you can have deps, but not "anti-deps")
<kerneis>
and about backward-compatibility, yeah, I know this is the OCaml position (in general), I agree with it sometimes, but here I would really consider the previous behaviour as a bug, not a feature
<gasche>
we could add a form of logical cut that lets some rule say that if they fail, their target must fail as well
<kerneis>
OCaml is not Linux ("we don't break user-space"…)
<gasche>
but it looks like a dangerous idea
<gasche>
so I'd rather work on the easy stuff that everyone likes first :-'
<kerneis>
too powerful
<gasche>
regarding my objection (2)
<gasche>
before getting lost in design considerations, do you know of other rules where a similar treatment could be beneficial?
<gasche>
(similar treatment to what you did in that particular case)
<kerneis>
mlypack as you said, I guess
<gasche>
but then we'd need to enumerate all the rules that could have a similar production
<gasche>
and cut them off with this technique
<kerneis>
agreed
<gasche>
looks like a poor-man implementation of cut / anti-rules
<gasche>
I hesitate between give myself more time to look into the problem and sleep on it
<gasche>
or commit your patch now and then do the above
zpe has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
<kerneis>
looking at the output of the following command:
<kerneis>
option 2: you could also decide not to traverse anything which contains a myocamlbuild.ml (git-style)
<kerneis>
but look for _tags in anything else
zpe has quit [Ping timeout: 245 seconds]
Drup has quit [Ping timeout: 248 seconds]
bobry has joined #ocaml
smondet has quit [Ping timeout: 264 seconds]
zpe has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
Drup has joined #ocaml
bkpt has joined #ocaml
cdidd has quit [Read error: Connection reset by peer]
cdidd has joined #ocaml
<gasche>
kerneis: I feel "subprojects modularity" is best left for future work right now; I think would be acceptable to move from a "traverse all" to your proposal if/when we understand how to interpret sub-myocamlbuild.ml
zpe has joined #ocaml
_andre has quit [Quit: leaving]
zpe has quit [Ping timeout: 268 seconds]
Kakadu has quit []
skchrko has quit [Quit: Leaving]
yezariaely has quit [Quit: Leaving.]
zpe has joined #ocaml
<kerneis>
agreed
zpe has quit [Ping timeout: 260 seconds]
pango has joined #ocaml
manud has joined #ocaml
zpe has joined #ocaml
djcoin has quit [Quit: WeeChat 0.4.0]
zpe has quit [Ping timeout: 256 seconds]
xavierm02 has quit [Ping timeout: 260 seconds]
demonimin has quit [Ping timeout: 264 seconds]
thomasga has joined #ocaml
thomasga has quit [Client Quit]
Anarchos has quit [Ping timeout: 264 seconds]
zpe has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
watermind has joined #ocaml
Anarchos has joined #ocaml
travisbrady has quit [Quit: travisbrady]
<Anarchos>
Is ocamlmklib difficult to use/understand ?
demonimin has joined #ocaml
mcclurmc has quit [Quit: Leaving.]
travisbrady has joined #ocaml
mcclurmc has joined #ocaml
wmeyer has joined #ocaml
Anarchos has quit [Quit: time to sleep]
<wmeyer>
Hi Kakadu, fine, just tired after training
avsm has joined #ocaml
mcclurmc has quit [Quit: Leaving.]
beckerb has joined #ocaml
beckerb_ has quit [Ping timeout: 245 seconds]
venk` is now known as venk
wmeyer has quit [Ping timeout: 240 seconds]
beckerb has quit [Ping timeout: 245 seconds]
tane has quit [Quit: Verlassend]
dsheets has joined #ocaml
Xom has joined #ocaml
Khady has quit [Ping timeout: 245 seconds]
Khady has joined #ocaml
watermind has quit [Quit: Konversation terminated!]