Time |
Nick |
Message |
00:58 |
|
ronsavage joined #marpa |
17:23 |
|
jdurand joined #marpa |
18:00 |
|
jeffreykegler joined #marpa |
18:02 |
shadowpaste |
"jeffreykegler" at 99.118.54.20 pasted "How to test external shared libraries using Marpa::R2" (72 lines) at http://scsys.co.uk:8002/359500 |
18:03 |
jeffreykegler |
Marpa::R2 2.085_004 includes hooks that let you use the Marpa CPAN distribution for testing external shared libraries. |
18:04 |
jeffreykegler |
As shadowpaste just said, I've written a document describing how to do this. |
18:06 |
jeffreykegler |
Your testing of the new developer's release is appreciated! |
18:24 |
jdurand |
Nice. I copy/pasted the shadowpaste to re-read it when I will work on that - many thanks |
18:42 |
|
rns joined #marpa |
18:43 |
|
rns left #marpa |
18:48 |
|
rns joined #marpa |
18:49 |
rns |
Marpa::R2 2.085_004 installed and runs ok for me (cpantesters reports sent). |
18:50 |
rns |
As for libmarpa as shared library, this is certainly a nice thing to see. |
18:51 |
jeffreykegler |
Jean-Damien has instigated this, so is due much of the thanks. |
18:52 |
rns |
Sure, thanks Jean-Damien. |
18:52 |
rns |
I've been following the developnment of this idea and it looks to me now that a CPAN dist Marpa::R2::libmarpa |
18:52 |
jeffreykegler |
I've learned to wait until there is some kind of audience for what I do, if possible, because without a receptive audience ... |
18:52 |
jeffreykegler |
my work can vanish into a black hole. |
18:52 |
jeffreykegler |
And I also need feeback about the feature set, .... |
18:52 |
jeffreykegler |
testings, etc., .etc. |
18:54 |
rns |
sure, my point is just that all you'be said is much easier if one can just `cpan Marpa::R2::libmarpa` and see what's there. |
18:55 |
rns |
I have to say though that building Marpa::R2::libmarpa off the same repo doesn't look like easy. |
18:55 |
jeffreykegler |
On that, I waiting for libmarpa shared libraries to get some actual use. |
18:55 |
jeffreykegler |
So we know things like what directories they wind up in, etc. |
18:56 |
rns |
Sure. Good point about the audience, BTW. |
18:56 |
jeffreykegler |
What I've just done is a big step toward Marpa::R2::libmarpa. I'll take the next step once there are some libmarpa.so's sitting out there and in use. |
18:58 |
jeffreykegler |
At some point, I could even switch over to where Marpa::R2 (or successor) by *default* tries to use a libmarpa shared library installed somewhere on your system. |
18:58 |
jeffreykegler |
And the current static linking then becomes the option. |
18:59 |
jeffreykegler |
Also, by that point, there may be other Marpa front ends, using these shared libraries, so it's no longer all about Marpa::R2. |
19:00 |
rns |
Sounds good. And then perl may become just a vehicle to install and test libmarpa shared lib for use by a local frontend. |
19:01 |
jeffreykegler |
Or not even install -- perhaps just a test suite. |
19:02 |
rns |
Sure. |
19:02 |
jeffreykegler |
By the way, I don't know of any other shared library which uses a CPAN module as its installer. Is there one? |
19:03 |
jeffreykegler |
All the cases I see, the CPAN module is a wrapper for something it assumes that you've already figured out how to install. |
19:04 |
jeffreykegler |
Also, autoconf/libtool is an ungainly beast, but it does install shared libraries *portably*. |
19:04 |
rns |
Same thing here. And the wrapped lib needs to installed separately and its location specified for the module to build. |
19:05 |
rns |
Yet another thing pioneered by Marpa. |
19:05 |
jeffreykegler |
Actually I think there was a Perl.org grant which covered some of the same ground. |
19:06 |
jeffreykegler |
But I do believe I've wound up pioneering a lot of Perl build techniques -- something I had no ambition or even desire to do. |
19:06 |
jeffreykegler |
Apparently nobody before has used a CPAN module for introducing a new C library to the world. |
19:07 |
jeffreykegler |
Which brings up another aside ... |
19:07 |
jeffreykegler |
There has been talk about a CCAN -- a C language equivalent of CPAN. Something of that name in fact exists, I think. |
19:08 |
jeffreykegler |
But what I keep repeating about CPAN is that the real value is in CPANtesters -- that's where all the CPAN "equivalents" for other languages all short IMHO. (Is there an exception, where they do testing?) |
19:09 |
jeffreykegler |
Anyway, a way to do CCAN is what I did with the Marpa C library. That is, CPAN == CCAN. |
19:09 |
jeffreykegler |
That way you get testing for your C library. |
19:19 |
rns |
Sure. |
19:19 |
rns |
CPAN did a great thing to Marpa on the audience side, with testing and interface development. |
19:20 |
rns |
Looks hardly possible in any language other than Perl. |
19:21 |
jeffreykegler |
rns: I think you may be right there, which is ironic ... |
19:22 |
jeffreykegler |
because Perl-ers are probably the most theory-hostile programmers out there, and Marpa is all about bringing theory and math back into parsing, |
19:23 |
jeffreykegler |
which has Marpa advancing into a strange combination of support and hostility. |
19:26 |
rns |
Well, Marpa does the job for those who dare trying. |
19:27 |
rns |
Now other languages' frontends/bindings to libmarpa have a choice; rewrite SLIF or roll their own. |
19:29 |
jeffreykegler |
The SLIF shouldn't be that hard to clone, particularly since you can refer to my own implementation ... |
19:29 |
jeffreykegler |
I think the biggest obstacle is getting people working in the libmarpa interface. |
19:30 |
jeffreykegler |
Jean-Damien in now doing that, and Peter Stuifzand did. |
19:31 |
jeffreykegler |
And this latest work with Jean-Damien has taught me a few things, and led me to rearrange the documentation a bit. |
19:35 |
rns |
Yep, Peter's go-marpa-* and marpa-cpp-rules and JD's https://github.com/jddurand/libmarpa-packaging/tree/master/examples, all good things. |
19:41 |
rns |
Have to get back to my translation job, goodbye. |
19:42 |
jeffreykegler |
rns: bye |
22:32 |
|
ronsavage joined #marpa |
22:45 |
ronsavage |
I've just downloaded 2.085_004. During installation I got: |
22:45 |
ronsavage |
libtool: link: ar cru .libs/libmarpa.a marpa.o marpa_obs.o marpa_avl.o marpa_tavl.o marpa_ami.o marpa_codes.o marpa_slif.o |
22:45 |
ronsavage |
libtool: link: ranlib .libs/libmarpa.a |
22:45 |
ronsavage |
libtool: link: ( cd ".libs" && rm -f "libmarpa.la" && ln -s "../libmarpa.la" "libmarpa.la" ) |
22:45 |
ronsavage |
make[1]: Leaving directory `/home/ron/Downloads/Marpa/Marpa-R2-2.085_004/libmarpa_build' |
22:45 |
ronsavage |
cc -I/home/ron/perl5/perlbrew/perls/perl-5.18.2/lib/5.18.2/x86_64-linux/CORE -DXS_VERSION="2.085_004" -DVERSION="2.085_004" -fPIC -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I /home/ron/Downloads/Marpa/Marpa-R2-2.085_004/libmarpa_build -I xs -Wall -W -ansi -Wpointer-arith -Wstrict-prototypes -Wwrite-strings -Wmissing-declarations -Wdeclaration-after-statement -O2 -o lib |
22:45 |
ronsavage |
lib/Marpa/R2.xs: In function ‘XS_Marpa__R2__Thin__SLR_g1_lexeme_complete’: |
22:45 |
ronsavage |
lib/Marpa/R2.xs:6091:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] |
22:45 |
ronsavage |
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Marpa/R2/R2.bs') |
22:45 |
ronsavage |
cc -shared -O2 -L/usr/local/lib -fstack-protector -o blib/arch/auto/Marpa/R2/R2.so lib/Marpa/R2.o /home/ron/Downloads/Marpa/Marpa-R2-2.085_004/libmarpa_build/.libs/libmarpa.a |
22:45 |
ronsavage |
All prerequisites satisfied |
22:45 |
ronsavage |
Just mentioning it. Proceeding to test with my modules..... |
22:56 |
ronsavage |
Hmmm. Those message above don't make it clear, but Marpa-R2-2.085_004 did not install. My tests used "Marpa::R2 V 2.085002" |
23:26 |
|
jeffreykegler joined #marpa |
23:28 |
jeffreykegler |
ronsavage: re http://irclog.perlgeek.de/marpa/2014-04-27#i_8645836 -- thanks for testing. The CPANtesters matrix is pretty thorough at this point and OK except for previously known issues: http://217.199.168.174/cgi-bin/cpantestersmatrix.pl?dist=Marpa-R2 |
23:32 |
jeffreykegler |
The tests should not be mixing the two versions: Marpa-R2-2.085_004 and Marpa::R2 V 2.085002. That is very likely to be a sign of issues, even if the installation goes through. |