Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-07-03

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 jeffreykegler joined #marpa
05:43 jeffreykegler joined #marpa
05:44 jeffreykegler left #marpa
06:14 ronsavage joined #marpa
06:17 ronsavage joined #marpa
06:20 ronsavage left #marpa
13:29 jeffreykegler joined #marpa
17:01 jeffreykegler https://github.com/jeffreyk​egler/Marpa--R2/issues/150
17:01 jeffreykegler Github issue 150 is at the moment very active -- it concerns Debian build problems.
17:02 jeffreykegler An alternative being considered is to release Libmarpa as a separate library on Debian, and have a flag that allows Marpa::R2 to use, not the library that ships with it, but an outside one.
17:47 Aria Ooh. That sounds not unfortunate.
17:49 jeffreykegler It's a nice idea, but I'd held off, because CPANtesters can't deal with dependencies except for Perl dependencies, so a Marpa::R2 configuration that relied on a separate library would go untested.
17:50 Aria Aah, fun.
17:50 Aria That is unfortunate.
17:51 jeffreykegler However, if it becomes the standard Debian config for Marpa::R2, Debian's testing may be enough.
18:36 jdurand_ joined #marpa
18:37 jdurand_ Re http://irclog.perlgeek.de/​marpa/2014-07-03#i_8969122 - agreed
18:37 jdurand_ lucs - have you seen my latest updated on ECMAScript issue 1
18:37 jeffreykegler Just heard from Debian, by the way.  As you can see from issue #150, they feel quite strongly that their infrastructure can handle the testing and other needs.
18:38 jeffreykegler So I'll be setting up Marpa::R2 to allow linking with Libmarpa as a separate library.
18:39 jdurand_ jeffreykegler, in anycaase yes I kinda trust their build infrastructure, history & experience is speeking in Debian's favour
18:39 jdurand_ Yes, that is a good option IMHO, this will not prevent libmarpa to be distributed with Perl, and allow distributions to fit their needs
18:41 jeffreykegler jdurand_: I know you've done a lot with separate Libmarpa libraries, so I'll hope for your advice in this matter.
18:41 Aria Yeah. Debian is second only to perl in testing.
18:43 jeffreykegler This will require a bit of refactoring of my build environment. :-)
19:00 jdurand_ jeffreykegler, ok, I wrote a script that was generating debian from Marpa::R2, not sure this can be the right way to do, but I am willing to help
19:00 jdurand_ I wait for your wants & recommendations & constraints and we can maybe produce something good in a minimum amount of time
19:01 jeffreykegler As it happens Jonas (who has been working on this on the Debian side) will be traveling for a week, so we have some time to get our act together.
19:02 jeffreykegler I think what I have to do at this point is split the Github repository in half -- libmarpa and Marpa::R2.
19:03 jdurand_ ok - I was looking to https://github.com/jddurand/libmar​pa-packaging/blob/master/create.pl and it seems not the way to do - better that you list what you have in mind, we agree on that, and then develop - I personnally have some experience in Debian packaging as well (google could thell about that -;)
19:04 jeffreykegler The classic (no library) Marpa::R2 build will work from its own copy of the Libmarpa code, but will no longer contain any Libmarpa development stuff.
19:05 jeffreykegler And the separate Libmarpa will not contain its own tests -- it will rely on using Marpa::R2 for that.
19:06 jdurand_ ok - one thing important is also the development framework. Do you want to libmarpa in Marpa--R2 or a separate repository ? In case of a separate repository, git offers two notion to link a repository within another
19:06 jeffreykegler Jonas will be helping on the Debian packaging side, so I think we merely need to give it our best.
19:06 jdurand_ "to keep libmarpa ./.."
19:07 jeffreykegler judrand_: separate repositories.  I'm not sure using Github mechanisms to link will add value.
19:08 jeffreykegler What are the two Github mechanisms/notions for linking?
19:09 jdurand_ one is "git tree"
19:09 jdurand_ the other is ahem... few seconds
19:09 jdurand_ oups "git subtree" and "git submodule"
19:10 jdurand_ but take care, google on them - there are pros and cons - and if do not want to fall in problem, the safer is to explicitely copy a new libmarpa explicitely -;
19:11 jeffreykegler I'll look at these.  The big advantage of explicitly copying, of course, is that it's something I can figure out how to do. :-)
19:12 jdurand_ ok. Do not understimate copy, though. Git purists will tell it is not perfect - having 100% control and avoid any git problem (and there /are/) with subtree or submodule methods is a strong argument as well
19:12 jdurand_ I personally git a git subtree if I remember well in my marpaXml repo
19:13 Aria subtree.
19:13 Aria Basically managed copy. It's a winning strategy if you're in a system without dependency management.
19:17 jeffreykegler I'll probably start with just copying.  Undetected and unaudited screw-ups are the main downside of this, but I do version checking, so I'm pretty safe.
19:18 jdurand_ ok, I will not contradict such position
19:18 jdurand_ Aria, what about http://blogs.atlassian.com/2013/05/alte​rnatives-to-git-submodule-git-subtree/
19:18 jeffreykegler That is, whenever Marpa::R2 starts, it does a 3-way comparison of the version from the headers at XS-compile-time, a version compiled into libmarpa, and an "expected" version coded into the XS object.
19:19 Aria jdurand_: That's exactly what I do. Subtree merges.
19:19 jeffreykegler You can still do a bad build, but it takes a little bit of work. :-)
19:19 jdurand_ this is what I followed - and I am still not sure it is so safe -, because http://www.mos6581.org/git_subtree_alternative lists a third (!) alternative: git-subrepo
19:20 jeffreykegler A good guide, by the way ...
19:20 jdurand_ you know what - git seems to be a animal with so many arms, it frightens be sometimes
19:20 Aria Yeah. It's all complex in the tooling.
19:21 Aria Though I must say, the underlying data structures are elegant.
19:21 jeffreykegler is to look at those people in similar situations who can be expected to know what they are doing, and ask "What do they use?"
19:21 jdurand_ "an animal ./.. frightens me sometomes"
19:21 Aria I highly recommend "git from the bottom up" to not be afraid of it.
19:21 jeffreykegler Aria: for example with rust.
19:21 Aria "Oh, you're a write-once DAG. I KNOW YOU"
19:21 jeffreykegler I checked whether Linus Torvalds is considering it.
19:22 jdurand_ lol - jeffrey, ok: but IMHO do not waste time on that, first alternative with a brual copy remains a good option IMHO because as you say you have full control
19:22 Aria jeffreykegler: indeed. I can say the google repo tool is an antipattern. My god. Getting an android build environ is 8GB, can't be partial, and takes HOURS to clone.
19:23 jeffreykegler Because if there were a better C, you'd expect Linus to be all over it.
19:23 Aria Perhaps. He doesn't seem particularly interested in exploring, though.
19:23 Aria (also, rust is just finally stabilizing)
19:24 jeffreykegler It'll be interesting to see how Linus reacts as rust stabilizes.
19:25 Aria Indeed.
19:25 jeffreykegler Linus is like RMS, in that both have a reputation as resistant to change, but in fact, they both have strong agendas.  They love change when it fits their agenda, and don't care about it otherwise.
19:32 Aria Yeah. They just don't seek it for its own sake.
19:32 Aria Not sure I agree with either of their agendas. Do like some of the work that's come out of it though
19:52 jdurand_ lucs, I'd like to know if you gimme a green light for an indexed release of MarpaX::Languages::ECMAScript::AST
19:53 jdurand_ Brw, jeffrey, I implemented a Marpa sub-grammar as a fix -;
20:10 jeffreykegler jdurand_: great!  Conquering the universe, one regex at a time! :-)
20:12 jdurand_ I wanted to convert /all/ regexps to a Marpa subgrammar, but refrained because it made ECMAScript much slower - the one I fixed is executed at most once, and the very end - so no visible effect
20:12 jdurand_ But I am truely very happy about that -;
20:12 jdurand_ After I was thinking to revisit entirely the PCRE into a Marpa version
20:13 jeffreykegler Actually, I was kidding about the regexes.  Marpa::R2 itself uses a *lot* of regexes.
20:15 jeffreykegler A Marpa-driven PCRE would be interesting.  Most regexes will run *slower* with Marpa, but some can benefit big-time.
20:16 jeffreykegler AFK -- lunch
21:02 lucs jdurand_: Oh, your fix fixed the mentioned bug as far as I can tell, but did you notice I posted another issue yesterday?
21:05 lucs jdurand_: I see you did (just logged onto github).
21:34 jdurand_ lucs, is the resolving of the issue satisfactory enough for you
21:35 lucs Why certainly my friend. Thanks for asking.
21:38 jdurand_ Ok, I push an indexed release then - thx
21:42 jdurand_ Done. MarpaX-Languages-ECMAScript-AST-0.017.
21:42 lucs Thanks.

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary