Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-17

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

All times shown according to UTC.

Time Nick Message
01:38 jeffreykegler Re the version checking in Marpa's internals (jdurand asked about this yesterday, I think):
01:40 jeffreykegler Libmarpa is, like just about similar packages, a library and a set of headers.  Since mismatches are possible, each has a version number.
01:40 jeffreykegler The libraries is compiled into some globals, and the main public header has some defines.
01:40 jeffreykegler When this is combined with Perl's XS a third set of version numbers come into play ...
01:41 jeffreykegler the version that Marpa::R2 *expects* to be working with.
01:41 jeffreykegler So the XS code has two checks -- one that the header versions are as expected ...
01:42 jeffreykegler and a 2nd that the version numbers compiled into the library are as expected.
01:45 jeffreykegler I've just cleaned up this code a bit, and these remarks reflect the state of the code as of the most recent commit.
02:12 jeffreykegler joined #marpa
04:46 jdurand joined #marpa
04:46 jdurand laste paaste should have been named: "templated libmarpa packaging under debian"
04:47 jdurand Obviously some errors and redundant files between the twos, the the principle is here : it works
04:47 jdurand as marpa doc is in a separate directory libmarpa_doc_dist, there will be another explicit package for it a priori
04:49 jeffreykegler I'm sure not sure I followed the last -- you are planning a separate Debian package for the Marpa docs?
04:50 jdurand Re http://irclog.perlgeek.de/marpa/2014-04-16#i_8599530 : I'll look into that in detail later... Thanks for the link
04:50 jdurand because there is an explicit ./configure in both, this is causing problem - will build work if I copy all files in libmarpa_doc_dist into libmarpa_dist ?
04:52 jeffreykegler re rpath: That's fine, I just wanted to make sure you weren't caught unawares by it, and understood the approach (more like non-approach) I took to it in libmarpa.
04:53 jdurand did http://scsys.co.uk:8002/351523 make it into your IRC client ? I do not find it in the IRC log
04:53 jeffreykegler re libmarpa_doc_dist: No you'd have to do a separate copy and build, but you could then take the resulting PDF's, etc and combine them into a Debian package
04:53 jeffreykegler No I did not see the paste
04:54 jeffreykegler That's assuming Debian allows you to deliver HTML, PDFs.
04:54 jdurand Ah... ok so you have the link now - my utf8 characters from my shell maybe puzzled nopaste
04:55 jeffreykegler If you really want the Debian package to *build* the document, that introduces a whole bunch of dependencies, and yes, you'd probably want to keep those in a separate package.
04:55 jeffreykegler Building the docs requires a Tex setup with a good number of the bells and whistles.
04:56 jdurand Yes: either pre-generate the docs and copy them to avoid a big tex build-dependency, either an explicit package because of these - I'll see
04:56 jeffreykegler jdurand: I'm happy to let you make these choices :-)
04:57 jeffreykegler Looking at the paste ...
04:57 jdurand otherwise, yes, no problem to package PDF of HTML
04:57 jeffreykegler Are all the .h files necessary?  I think at least some of them may not be.
04:58 jeffreykegler marpa.h is the public file, and is necessary if you're going to compile a libmarpa app.
05:00 jdurand This is the default behaviour to take eveyrthing that configure install installed. Then there are customizations. No pb to remove all header files but marpa.h from the package.
05:01 jeffreykegler Re the .h files, frankly I went back and forth in the design, so I'm not sure which need to be public, except for marpa.h, which *definitely* is public.
05:01 jdurand Ok - this is a minor thing from packaging point of view -;
05:02 jeffreykegler Also, some might be in the category, "I hope to make this available to the public someday, but right now it's not ready-for-prime-time"
05:02 jeffreykegler marpa_avl.h might be in that category
05:04 shadowpaste "jdurand" at 88.160.190.154 pasted "marpa.h only" (20 lines) at http://scsys.co.uk:8002/351534
05:04 jdurand took 10 secs to change the packaging. Ok, have to go -; see you later!
05:05 jeffreykegler Bye -- I'll make a few more comments you can catch from the backlog.
05:05 jdurand ok
05:06 jeffreykegler Anyway, for jdurand to catch up with from the backlog
05:10 jeffreykegler Re the .h files: marpa_slif.h may also be necessary as a public .h -- the rest currently are not public, although someday some of them might be.
05:11 jeffreykegler By intention marpa.h is public stuff ...
05:12 jeffreykegler marpa_slif.h is stuff needed by the SLIF.  It's definitely public in the sense that Marpa::R@
05:12 jeffreykegler ... Marpa::R2's XS code needs it ...
05:12 jeffreykegler but maybe it should be left out of the Debian distro.
05:13 jeffreykegler The others should be private, not needed (and therefore not wanted) in the distro.
05:15 jeffreykegler Caveat: since I've just been using these .h files to build Marpa::R2 on installation, my theories about what is needed for what are just that -- untested theories.  I know what I intended, but I may have put some defines or declarations into the wrong .h, etc.
05:16 jeffreykegler jdurand: you might want to create a simple Marpa app from your Debian package before finalizing it, to make sure that all (and only) the necessary .h files are there.
06:31 ronsavage jeffreykegler: Did you see http://irclog.perlgeek.de/marpa/2014-04-16#i_8600284
07:25 jeffreykegler joined #marpa
07:27 jeffreykegler ronsavage: re http://irclog.perlgeek.de/marpa/2014-04-17#i_8601225 -- yes and thanks!  I already ack'ed it, at the very end of yesterday's log.
09:32 ronsavage joined #marpa
19:46 jdurand joined #marpa
19:47 jdurand Jeffrey, could you explain the relationship between CPAN version of libmarpa version - under which condition libmarpa version will change, at each upload on CPAN (?)
19:49 jeffreykegler joined #marpa
19:51 jeffreykegler judrand: re http://irclog.perlgeek.de/marpa/2014-04-17#i_8604256 -- I really haven't fully decided yet.  From the downstream point of view the only safe assumption is that the Marpa::R2 version will change whenever the associated libmarpa version changes.  The opposite will not necessarily be true.
19:52 jdurand If the opposite is not true, a priori the content of libmarpa_dist and libmarpa_doc_dist should not change when a the libmarpa does not change isn't it
19:52 jdurand "when the libmarpa version does not change"
19:54 jeffreykegler Good point.  *ANY* change in libmarpa_dist or libmarpa_doc_dist should be accompanied by a change in their version number.
19:54 jeffreykegler Even so much as a whitespace change in one of the docs.
19:55 jdurand Ok
19:55 jeffreykegler On the other hand, this applies *only* to source.
19:55 jeffreykegler Some of the contents of libmarpa_dist and libmarpa_doc_dist are built, and they might change even without a change in the source.  Hmmmmmmmmmm ....
19:56 jdurand Fine, we'll see over time how this is robust v.s. development in there
19:56 jdurand Ah... just reading your phrase before before
19:56 jdurand bad point then -;
19:56 jeffreykegler If you're happy to let this evolve, we'll leave things there.
19:57 jdurand That's ok, a priori a new libmarpa packaging will always be a by-hand decision, and not correlated with every CPAN upload - let's not puzzle our minds with that for the moment
19:58 jeffreykegler There are good points, thought and I will give them some thought.
19:58 jeffreykegler * There are good points, though and I will give them some thought.
19:58 jdurand what would like to see in git: a dedicated directory handling all that under branch master, or another branch (which could be empty at the beginning -;)
19:59 jeffreykegler git for the distro you mean?
19:59 jdurand yes
19:59 jdurand or another repository
19:59 jeffreykegler distro probably should be its own repository, under your control
20:00 jdurand I was going to do that - we are synchronized on this point ! Ok then.
20:01 jeffreykegler My only caveat would be to check if other Debian distros have some cooler way of doing this.
20:01 jeffreykegler Must be a *lot* of Debian distros on github these days
20:02 jdurand I'll call it libmarpa-packaging - because I envisage other distros that could be interested to contact me/us perhaps in the future - rpm has its own format (although supports deb format since come years now), other are more tarball oriented like gentoo, etc.
20:02 jdurand "since some years"
20:02 jdurand Yes and no - at lot of debian distros have a debian/ directory at the top
20:03 jeffreykegler Anyway, it's your decision.
20:03 jdurand while Marpa--R2 builds a CPAN packaging that embeds libmarpa - quite a different concept. I mean that untarring Marpa-R2 will not present *only* libmarpa -
20:04 jdurand We'll see - this will need tuning, the goal is to have a first (working) shot
20:04 jeffreykegler Thanks for doing this.
20:05 jdurand No pb, that's the kind of thing I like to do - in parallel I am progressing in the xsub's marpa stuff -; you'll see that sooner or later - my first xsub serious stuff, so I am doing things slowly, reading more doc than coding - for things that could be trivial for a xsub experienced programmer
20:10 jdurand Have a nice end of day. AFK.
20:10 jeffreykegler Bye!
20:53 LLamaRider joined #marpa
22:46 LLamaRider joined #marpa

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