Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-15

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

All times shown according to UTC.

Time Nick Message
01:22 jeffreykegler judrand: On investigation, I find my claim that the "configure" script that comes in libmarpa_dist is "vanilla" autoconf was a little bit bogus.
01:25 jeffreykegler For Perl XS, I needed a library that was both static and compiled with position-independent-code (PIC).  As it happens, autoconf has "convenience libraries", which are build in exactly this unusual combination -- they are intended as intermediate stages.
01:25 jeffreykegler So I set automake up to make the convenience library, which I then pulled out of the autoconf directory to link with my XS code.
01:26 jeffreykegler Anyway, the result was that "configure" ignored all flags to create shared libraries.
01:28 jeffreykegler I've now changed this -- now Libmarpa's configure really is "vanilla", and by default builds shared libraries on systems that support them.  When building with Perl/XS, I pass in flags to change this so I get the static libraries that I need.
01:45 jeffreykegler More re shared libraries -- I changed autoconf and by some miracle the Config::Autoconf installs seems to "just work".  Perhaps because they grab their defaults from Perl's config, so they're already right for linking with XS?
01:45 jeffreykegler I've tested on Linux/x86 and Darwin/PPC, but now for the big challenge ...
01:45 jeffreykegler ARM/Linux on the Raspberry Pi!
03:26 ronsavage joined #marpa
05:03 jdurand joined #marpa
05:03 jdurand Re http://irclog.perlgeek.de/​marpa/2014-04-15#i_8588145 - Ah I was sure it has to do with LT_INIT... thanks!
05:06 jeffreykegler joined #marpa
05:28 jdurand joined #marpa
05:29 jdurand Re http://irclog.perlgeek.de/​marpa/2014-04-15#i_8588196 - yes, Config::AutoConf is using ExtUtils::CBuilder, i.e. inherit perl's default flags
05:30 jeffreykegler I've uploaded a new developer's release, with the fix
05:30 jdurand Great - thx - will retry on that, and maybe send an ITP (Intent to Package) request to debian
05:30 jeffreykegler You should be able to: 1.) First, build Marpa::R2.  (This to make sure your release tests OK.).
05:31 jeffreykegler 2.) The copy the Libmarpa distribution from libmarpa_dist
05:31 jeffreykegler 3.) Then configure and build it in the same way you would any autoconf based software, independent of Perl
05:32 jdurand Yep, that's what i have in mind - in case of success I'll might create debian branch on your repo - will see - morning here, children waking up, see you later! Cheers
05:32 jeffreykegler Talk to you later
05:34 jeffreykegler And as a general announcement: a new developer's release, Marpa-R2-2.085_000 is up on CPAN.  Value added is the fix to allow Libmarpa to be pulled out and build apart from Perl.
05:35 jeffreykegler Changes to the install procedures are always dicey so, and as always, testing is appreciated.  Thanks!
07:17 ronsavage Marpa::R2 V 2.085
07:17 ronsavage Counts: Tests: 542. Modules: 8. Passes: 8. Fails: 0
07:17 ronsavage Duration: 1 minute and 37 seconds
11:20 LLamaRider joined #marpa
17:23 jeffreykegler joined #marpa
17:25 jeffreykegler ronsavage: re http://irclog.perlgeek.de/​marpa/2014-04-15#i_8589024 -- thanks!
17:26 jeffreykegler1 joined #marpa
17:28 jeffreykegler2 joined #marpa
17:29 jeffreykegler2 re shared libraries from Libmarpa: my apologies for the bug.  Getting Libmarpa, Perl-free and directly from the distribution directory, should be a very easy thing to do.  And the autoconf configure should handle all the standard flags correctly.
17:38 jeffreykegler joined #marpa
17:52 jeffreykegler joined #marpa
17:54 jeffreykegler1 joined #marpa
17:58 jeffreykegler joined #marpa
18:22 jdurand joined #marpa
18:24 shadowpaste "jdurand" at 88.160.190.154 pasted "configure warning" (25 lines) at http://scsys.co.uk:8002/350177
18:29 shadowpaste "jdurand" at 88.160.190.154 pasted "shared lib ok but version is missing" (16 lines) at http://scsys.co.uk:8002/350183
18:45 jeffreykegler joined #marpa
18:51 jeffreykegler re http://irclog.perlgeek.de/​marpa/2014-04-15#i_8592077 -- I guess the version numbers should be the same I'm currently using.  The Libmarpa version is not the same as the Marpa version -- you can see it in the output of a "Build test"
18:53 jdurand Jeffrey, yep I know. Nevertheless I am enclined to have the internal libmarpa version here
18:54 jeffreykegler While not the same, Libmarpa version and Marpa::R2 version are co-ordinated.  In particular, Marpa::R2 is *very* fussy -- it will not run except with a specific version number, major.minor.micro, with all 3 components exact.  The disadvantage is you can't mix and match.  The advantage is that you can't mix and match.
18:56 jdurand That's why R2.xs has the checks on marpa version, with EXPECTED_MARPA_xxx - i.e. Marpa::R2 handles that. And if both versions are co-ordinated, then why have these two
18:57 jdurand I mean: R2.xs does the check because he wants to load a single version and another one. A case which cannot happen btw since you link with a static version.
18:58 jdurand From general developper point of view, it is perfectly legal to have a minor version move of a shared version of libmarpa. So, unless the exception which is to nw knowledge only Marpa::R2 perl package, any developper will rarely check the version
18:58 jeffreykegler IIRC, the checks are not redundant.  One set checks that the headers match.  Another that the library matches.
18:58 jdurand In addition, checking the version is useless when using shared libraries, because versioning is coded inside the libraries, and the executable dependencies
18:59 jdurand that's why there is always libxxx.so -> libxxx.so.MAJOR_VERSION -> libxxx.so.MAJOR_VERSION.MINOR_VERSION
19:01 jdurand about the checks, IMHO they cannot mismatch unless perl build system would be broken: -I guarantees you hit the good headers, your link with the static guarantees you link with the correct lib. Nevertheless I understand the functionnality of this extra code - I just mean that I don't see how it could fail in a perl environment
19:02 jdurand The notion MICRO_VERSION would fit well the extra versioning that packager often do. But that's not a necessity.
19:03 jeffreykegler joined #marpa
19:03 jdurand Anyway, up to you to decide which versioning to give to libmarpa - I will not contradict your decision, and I see you are alreaady fighting with your internet connection! -; !
19:04 jeffreykegler Actually, different existing libraries use different strategies.
19:06 jeffreykegler1 joined #marpa
19:06 jeffreykegler1 Security libraries often simply increment the major level with every change, and leave minor and micro permanently at zero.
19:06 jeffreykegler1 I may want to do that.
19:08 jdurand As you like. I just meant after all there is a need of versioning with the generated so -; Btw I just found this remarquable link: http://www.fortran-2000.com/​ArnaudRecipes/sharedlib.html
19:09 jeffreykegler joined #marpa
19:13 jeffreykegler joined #marpa
19:19 jeffreykegler1 joined #marpa
19:41 jeffreykegler joined #marpa
19:48 jeffreykegler1 joined #marpa
19:55 jeffreykegler joined #marpa
21:14 jeffreykegler I've just sent an email to the Google group re Libmarpa versioning: https://groups.google.com/forum/​#!topic/marpa-parser/2joTl-x0VcI
21:15 jeffreykegler It's of interest only to a portion of Marpa's users, but it's a significant enough decision I don't want to make it without a chance for feedback.
21:16 jeffreykegler Bottom line: my current inclination is to use the style of versioning used by security packages, where the version is major.minor.micro, but minor and micro are always 0, so that every change is treated as a major version change.
21:18 jeffreykegler This is cautious, but it means that a silent upgrade can never break an app.

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