<Alpounet>
gildor, I was thinking about one branch per project
kaustuv has joined #ocaml
<Alpounet>
with a final merge for releases
<gildor>
why a branch per project ?
<gildor>
I mean most project will be unrelated
<rwmjones>
upvoted, but I think you should have put it on /programming/ instead
<Alpounet>
rwmjones, it's on both, in case..;
<rwmjones>
ah
* rwmjones
checks
<Alpounet>
I just submitted it, on both.
<Alpounet>
gildor, my git knowledge isn't the best here, so what do you mean by multiple repos ?
<Alpounet>
is there a way to merge them easily ?
<gildor>
you have a first repository gitroot/newhope/newhope.git
<Alpounet>
yeah
<gildor>
when you adopt ocamlsdl you create gitroot/newhope/ocamlsdl.git
<gildor>
and then gitroot/newhope/camlgl.git
<gildor>
etc
<Alpounet>
hmm... how ?
<Alpounet>
I've only manipulated existing git repos.
<gildor>
what is the point to merge this different repository
<gildor>
this is just a matter of mkdir ocamlsdl.git + git init (or smthg like that)
<Alpounet>
gildor, I was thinking about a one-shot archive generation with all adopted projects
<mfp>
Alpounet: you can do that with git submodules
<mrvn>
gildor: plus some magic to initialy push something in there.
<mfp>
Alpounet: but merging all the repos into one, with different branches for each project Sounds Very Wrong(TM)
<Alpounet>
ok
<mrvn>
totally
<Alpounet>
gildor, so there's an ssh access.
<Alpounet>
hcarty hasn't sent it to me yet
<gildor>
separate repository can help you to simply migrate the repository to another project, whenever someone want to adopt it
<gildor>
(in this case, this will be mostly a "mv" command)
<gildor>
Alpounet: of course, you have to add you ssh public key to you forge account
<mfp>
Alpounet: git submodules allows you to have "child" subprojects in a git repository --- essentially, the parent keeps a reference to the other repositories plus the idhash of the commit that is to be co'ed
<gildor>
and then ssh forge.ocamlcore.org
<Alpounet>
gildor, already done
<Alpounet>
mfp, ok... does it sound to be the right way ?
<mrvn>
submodules are pretty fragile. way to easy to screw up.
<Alpounet>
ok.
<Alpounet>
gildor's way seems fine.
<gildor>
Alpounet: separate repository! simple and straight
<gildor>
i.e. KISS
<mfp>
mrvn: really? worked fined for me so far. Only have to remember to make commits from child modules available so that the parent can be pulled.
<mrvn>
see, you have to remeber something.
<Alpounet>
yeah
<Alpounet>
separate repos
<Alpounet>
ok
<mfp>
Alpounet: git submodules uses one repository per module ("gildor's method"); what it adds is a parent repos that references all the others, so you can checkout everything at once
<gildor>
Alpounet, contact me for your first repo creation, I will give you various command to do it
<mfp>
mrvn: so you think git push in the parent should also push the submodules?
<gildor>
mfp: don't understand that, it works like "svn:externals" ?
<Alpounet>
gildor, ok.
<Alpounet>
mfp, ok...
<gildor>
mfp, Alpounet: in this case separate repo + "unite them all in newhope.git"
<mfp>
gildor: from what I remember from svn:externals, pretty much
<mfp>
yup
<gildor>
mfp: svn:externals was not very used
<Alpounet>
gildor, by the way, maybe I should write a script for updating newhope.git from all the projects
<gildor>
I tried to do some experiment wiht it (inside pkg-ocaml-maint repository)
<Alpounet>
(if I don't use submodules)
<gildor>
Alpounet: begin by adopting project ;-)
<mfp>
because there are not that many projects with sub-projects that benefit from it
<gildor>
Alpounet: once it won't be manageable by hand, write a script with various command you have used by hand
<Alpounet>
gildor, yeah, waiting for hcarty and palomer to subscribe to the ML
<mfp>
Alpounet: what do you want newhope.git for? just to fetch all the code at once?
<Alpounet>
(at least)
<gildor>
Alpounet: tell them to use the URL rather than the "reply-to" method
<Alpounet>
mfp, don't know yet, as I didn't know before that we could add other git repos.
<Alpounet>
gildor, yeah, ok.
seafood has joined #ocaml
<gildor>
BTW, I am subscribe to newhope
<Alpounet>
gildor, seen it :)
<Alpounet>
Which orphaned libraries do you know guys ? (except OCamlSDL, Cairo-OCaml, GLCaml)
<kaustuv>
Please don't get reddit involved. We do not need the peanut gallery's input yet.
<kaustuv>
(And reddit/r/programming is increasingly a toxic dump)
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<Alpounet>
wow
<Alpounet>
the GSL OCaml library seem to be unmaintained and out-of-date
<gildor>
and then browse to debian/patches, read 00list and corresponding patches
<gildor>
this gives you a good metric about this
<Alpounet>
I may be missing something... the Debian package is less out-of-date than the official release of ocamlgsl ?
<Alpounet>
patches related to new versions have been applied ?
<gildor>
no this is just that ocamlgsl is still working with minimum diff
<gildor>
upstream version of ocamlgsl
<gildor>
in this case, it doesn't need to be orphaned/adopted
<Alpounet>
ok
<Alpounet>
I was thinking about getting ocamlgsl up-to-date w.r.t the C version.
<gildor>
I think someone talk about camomile
<gildor>
But the binding to ocamlgsl seems to work
<Alpounet>
no need to update it IYO ?
komar_ has quit [Remote closed the connection]
<gildor>
with gsl 1.9
<gildor>
Alpounet: don't know, but AFAIK there is no problem
<Alpounet>
ok
komar_ has joined #ocaml
<gildor>
someone talked about a patch provided to camomile...
<Alpounet>
we'd rather focus on other libraries.
<Alpounet>
ok
<gildor>
and not applied
<gildor>
anyway, I think the biggest part of this will be to reach maintainer and made them give you the control
<kaustuv>
Camomile is definitely either orphaned or the author is too busy to work on it
<gildor>
e.g. reaching camomile upstream author and make him give you the source code and unregister (or redirect) SF project to newhope
<Alpounet>
Known problems
<Alpounet>
Crash is reported on AMD64 and Itanium. If you know the detail, please let me know.
<Alpounet>
(Camomile)
<kaustuv>
I don't think we should try to ask the authors/maintainers of libraries to give up control. There is no reason for them to trust us.
<gildor>
kaustuv: duplicate should be avoided
<gildor>
you can propose upstream author to join newhope team if they wish to still do some maintainance
<Alpounet>
yeah
<gildor>
but let other contribute as well
<kaustuv>
I would advise being cautious about scope creep.
<kaustuv>
And more, to take baby steps first. Get a single or a few packages under the umbrella first, then use that success as leverage.
|Jedai| is now known as Jedai
<gildor>
kaustuv: I agree
jeremiah has joined #ocaml
<gildor>
kaustuv: I think finding a project that can be maintained and which upstream agree with newhope is the best way
Jedai is now known as |Jedai|
<Alpounet>
Indeed, but we must select them
<gildor>
kaustuv: the danger is to not have upstream agreement at all, and being seen as "project hijacker"
<gildor>
kaustuv: this would be very bad advertisement
<kaustuv>
gildor: Not necessarily. I think demanding maintainership up front is being a bit unfriendly. The newhope community can organize patches and offer them upstream with the additional offer of taking the burden of maintaining off their hands if they have moved on.
|Jedai| is now known as Jedai
Jedai is now known as |Jedai|
|Jedai| is now known as Jedai
<gildor>
kaustuv: try to begin with project that upstream really gives you control
<gildor>
kaustuv: when everything will suceed and you gather enough "positive recommendation", I think you will be able to do what you want
* gildor
got to lunch
kaustuv has quit ["75bc07d179571f3c6e9aa42bcd54ff59"]
Ariens_Hyperion has quit [Read error: 110 (Connection timed out)]
<Alpounet>
mail sent on the list :)
verte has joined #ocaml
jamii_ has joined #ocaml
<Alpounet>
damned
<Alpounet>
lists must digest us first
<gildor>
Alpounet: what is the problem with the mailing list ?
tar_ has quit []
sOpen has joined #ocaml
<kaustuv>
[newhopespam] I've got the cairo library updated with the new symbols from 1.4. Now on to 1.6 and 1.8. What patch format(s) do you guys accept?
<Alpounet>
diff
<Alpounet>
git accept diff patches
<Alpounet>
but we can add you as a developer
<Alpounet>
so that you'll be able to work on the git repos
<Alpounet>
don't worry for that
<Alpounet>
gildor, it rejects me
<Alpounet>
and moreover we're not yet "digested subscribers" on the ML
<gildor>
wait a sec
<gildor>
I try to send a mail myself
<kaustuv>
Actually, I think I'll do some light testing before sending patches out.
<Alpounet>
gildor, I had the same problem when registering to HLVM's ML
<hcarty>
I use both the Cairo and GSL bindings, so I've been doing my best to follow them wherever they end up...
<kaustuv>
hcarty: how important is backwards compatibility?
<gildor>
hcarty: no release on googlecode... for now
<Alpounet>
nothing on their SVN, too
<hcarty>
Alpounet: Their SVN is populated
<hcarty>
No tagged releases though
<Alpounet>
ok
<Alpounet>
let's drop the ocamlgsl idea so
<Alpounet>
any other suggestion ?
<hcarty>
kaustuv: For the Cairo bindings, I'd say backwards compatibility is mildly important - there was never an official release from what I can tell
<hcarty>
kaustuv: Perhaps the tagged 1.0 release in CVS counts as an official release
<hcarty>
kaustuv: What are you interested in breaking?
<kaustuv>
hcarty: mainly functions of type such as [> `Any ] surface -> ... when they really want to be 'a surface -> ...
<hcarty>
Alpounet: Since GSL seems to be maintained (I've submitted a patch for it already), my main interest in is Cairo
<hcarty>
kaustuv: It shouldn't break my code, so I'd be ok with that :-)
<hcarty>
kaustuv: But I'd still like to hear from the original author
<kaustuv>
hcarty: also, for example, representing rectangles as a float record instead of a tuple.
<kaustuv>
Eg. Cairo.stroke/fill/clip_extents
<hcarty>
kaustuv: Would it be better to define a type such as "type surface_kind_t = [ `Image | `Pdf | ... ]" and make those functions take a surface_kind_t surface?
<kaustuv>
We have that already -- Cairo.surface_type
<hcarty>
Ah, right
<Alpounet>
I must go
<Alpounet>
brb tomorrow
<Alpounet>
email on the list :)
Alpounet has quit ["Quitte"]
<hcarty>
Alpounet: As soon as something comes up, will do
<hcarty>
kaustuv: Ah, of course
<kaustuv>
But the polymorphic variants are kind of unnecessary here, because either a function works on any surface or only on a particular one. Design wise it would be better to use a normal variant.
<hcarty>
kaustuv: Then would it be better to change [> `Any ] to Cairo.surface_type?
<hcarty>
kaustuv: Sounds reasonable
<kaustuv>
Yeah, that's one possibility. [> `Any ] is doubly bad because `Any isn't a member of surface_type, so any client code that uses a surface_type surface breaks
sOpen has quit [Read error: 110 (Connection timed out)]
<hcarty>
kaustuv: Maybe not. How would you provide compile-time checks?
<hcarty>
(for the normal variant case)
<kaustuv>
Well, I haven't gone over the entire library yet, but I haven't spotted function that only works only on `PDF and `PS surfaces (for example), so a type such as [> `PDF | `PS ] should never occur...
<kaustuv>
Well anyhow I won't make incompatible changes until I've got all the new stuff in 1.6 and 1.8 integrated.
<hcarty>
kaustuv: Sounds reasonable
<hcarty>
Thanks again for working on that
Camarade_Tux has quit [Remote closed the connection]
Camarade_Tux has joined #ocaml
kaustuv has quit ["5b7aca71913555732dffced297df840a"]
<palomer>
hrmph
<Camarade_Tux>
someone should tie me up until I do a proper release of ocaml-gir...
<mrvn>
hands too?
<Camarade_Tux>
yeah, I'm not that bad nose and tongue typing :)
<hcarty>
Camarade_Tux: ocaml-gir?
<hcarty>
An OCaml version of Zim's robot
<Camarade_Tux>
hcarty, it is a binding generator for any gtk-based app
<hcarty>
Camarade_Tux: Oh, very nice
<Camarade_Tux>
the name comes for gobject-introspection actually ;)
<hcarty>
I suppose that's a more logical source :-)
<Camarade_Tux>
I've developped it because I wanted bindings to webkit-gtk but its api was expected to change (it changed and is still changing)
rwmjones has quit ["Leaving"]
<Camarade_Tux>
the problem is that it relies on a "dictionnary" of types to translate between lablgtk, gir and gtk types and this dictionnary needs to be checked and expanded
<Camarade_Tux>
(gosh, that's a really bad film on TV)
<mrvn>
Letal Weapon 3.
<Camarade_Tux>
Backdraft, with Kurt Russel
prime2 has joined #ocaml
ztfw has quit [Remote closed the connection]
BiDOrD has quit [Read error: 60 (Operation timed out)]
<palomer>
ocaml-gir = what people are trying to do with qt?
<Camarade_Tux>
palomer, somehow
<palomer>
don't you mean "somewhat"?
<Camarade_Tux>
wordreference just told me I meant "somehow", but "somewhat" is ok too ;)
BiDOrD has joined #ocaml
<Camarade_Tux>
gobject-introspection is made for python at first, they would generate bindings to gtk and other libs at runtime so maybe that ocaml-gir could be used to bind gtk itself
<Camarade_Tux>
(but not gobject)
<palomer>
this is for runtime generation?
<Camarade_Tux>
no, ocaml-gir generates .ml and .c files
<Camarade_Tux>
gobject-introspection lets me get the function prototypes easily
<palomer>
at runtime
<Camarade_Tux>
there are several components in gobject-introspection and ocaml-gir only use the one to find the function prototypes
<Camarade_Tux>
the python part relies on others
jeanbon has joined #ocaml
prime2 has quit ["leaving"]
Elrood has joined #ocaml
<flux>
uh, this is one stupid problem
<flux>
I move source to another directory (out from my "test" directory) with the _tags file, and now the damn thing won't even parse :) (apparently due to not using pkg_bitstring)
<flux>
I suppose I keep on developing it in my test directory then :)
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
authentic has joined #ocaml
verte has quit ["~~~ Crash in JIT!"]
jeremiah has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
Any official-INRIA-binary-using OSX users here?
sporkmonger_ has joined #ocaml
<hcarty>
A friend is attempting to try out OCaml, but he's working on a Mac and I am unfamiliar with the landscape