EV on AIX?

[Darin McBride]

On Friday March 23 2012 8:19:09 PM Marc Lehmann wrote:
> On Fri, Mar 23, 2012 at 09:06:38AM -0600, Darin McBride 
<darin.mcbride at shaw.ca> wrote:
> > How about someone without knowledge? :-)
> 
> Well, knowledge can sometimes be found, more important is, and I forgot
> to mention, the ability to actually test it (making it compile and making
> sure the change is actually used is already a great test :-)

Well, there is that.  I'm just not sure how to ensure I'm excersising this :-)

> > things out, and got it to compile.  And then "make test" worked, though I
> 
> Thanks a lot, that looks good enough for the next version - you could test
> current CVS, if you wish (cvs -z3 -d
> :pserver:anonymous at cvs.schmorp.de/schmorpforge co libev)

Actually, after further conversations with Peeter (the guy who wrote that 
blog, he's the primary guy responsible for the AIX "port" of DB2, so seems 
knowledgable/experienced), the patch isn't quite right.  I showed him what you 
used for gcc and had some comments there as well.  So a patch on top of the 
previous patch.  This one is too big (as far as line length is concerned - 
keeps getting word-wrapped), so we'll try an attachment.

> > don't know how much of this memory fence stuff is tested by the current
> > test suite.
> 
> None is tested, and I wouldn't even know how to properly test it, as in
> many cases (and on many cpus), it would work without memory fences - it'S
> a race after all.

I'm no good at races.  I generally lose. :-)

> For example, all x86 cpus factually procide more guarantees, which is why
> older libev versions do not need memory fences on these cpus, but there is
> no guarantee that future cpus wouldn't change this.
> 
> However, the normal EV tests uite will execute the fence code, so it will
> at least check whether the code is legal.

Okay, that's a start.  I've got my test for Term::ReadLine's event model using 
AnyEvent (all started on rt 108470, and I want to apologise for that whole 
thread, I was embarrassed to be involved in it, nevermind having opened the 
wishlist item in the first place).  I added in a "use EV;" at the top.  That 
failed miserably until I went and did a "make install" in my other window :-) 
and then it worked fine.  Same with Coro.  I'm testing with the attached patch.

> > the author IRL, and he does seem to be a genius).  The only issue is that
> > Peeter claimed that this function was in builtins.h, but I can't find that
> > on my AIX box.  I'll have to ask him about it.  (It doesn't seem to be
> > required.)
> Maybe some builtins are form there, and others are not, and ibm wanted to
> keep the option of moving things around.
> 
> Or maybe your aix box is just too old *g*

AIX 6.1 - which comes with perl 5.8.8.  Old enough. :-)

Peeter tells me that the documentation always said that you didn't need to 
#include it, and that maybe they've fixed the code to match the documentation.

> > Which it does with modern gcc compilers, but xlC's defaults don't allow
> > that. Yes, I know, that's from the 1999 standard of C.
> 
> Good that xlC has an option for it :) In fact, perl should properly
> configured with that option, and suddenly all those modules start to work.

Yeah, I better go and open a bug report for adding -qlanglvl=extc99 to the 
Configure options that perl itself uses and stores for modules' use.  It's 
getting a bit late in the 5.16 cycle :-)

> In any case, my only experiences with xlC I made in 1994-6 or so, and...
> no, don't make me think back. Things *must* have changed to the better
> since then!!

Yooooouuu arrrre geeeeettiiiinnnng sleeeepyyyy... you will completely forget 
about everything to do with xlC... now wake!

Did that work?  Happier? :-)

(If it worked, I'm submitting a patent on hypnosis - on the internet!)

> > (I've already seen that you're aware of how 5.15.9 and common::sense don't
> > see eye-to-eye under -w, which is, quite unfortunately, how tests are
> > run.)
> -w is simply beyond broken - however, common::sense has a workaround for
> perl 5.15 for two weeks now, are you sure you are using version 3.5 and
> not 3.4?

cpan still insists on installing 3.4.  Even 
https://metacpan.org/search?q=common%3A%3Asense or 
https://metacpan.org/module/common::sense seem to imply that 3.4 is the 
latest.  Are you sure you've released 3.5? :-)

> common::sense, no matter what, has to bend around -w, because in fact, the
> main purpose of common::sense is to work around -w.
> 
> > here and there, I'd be using C.  And I don't use C.  (I'd use C++, but
> > there goes huge swaths of memory savings, too.  More if I ever get around
> > to learning wx or Qt or some such behemoth.)
> 
> Try gtk+, because that has a working perl interface, so you can switch
> back to a language that is actually good at gui logic. OTOH, touching gtk+
> from C (and even C++) always has something heroic... :)

I do everything in kde, so I'm a little biased toward Qt, but you're right, it 
doesn't really support perl very well.  Or perl support Qt.  Whatever.  :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ev_aix.patch
Type: text/x-patch
Size: 1429 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/anyevent/attachments/20120323/81af3ded/attachment.bin>