somian's Journal

Dysfunctional communities and pretenses about them

somian — 2007-03-28T03:45:09+00:00

Things we tell ourselves aren't always true.

I fled Perlmonks.org towards the end of last year, as many others have before me, and found myself trying out IRC for a time, specifically the Freenode network and its #perl channel. What I like about having an online chat open during long periods while I hack at some project or other is the sense of life out there in the mental/spiritual sphere that I am occupying. The sense that other symbolic analysts "out there" are simultaneously engaged in similar pursuits, struggles and joys is an antidote for me to tedium or fatigue, one that I have come to feel is beneficial. But how far will one go to possess such a benefit? I recently had to ask myself that question when reality came up in my face with the alarming force and speed of a derailed train headed for a stone wall.

#perl on Freenode typically has at least 500 users listed as present in the channel. With that many users, there is bound to be a large variety of people with different opinions to express, or so you'd think. But the truth is that there are not so many different opinions being expressed, and I think I know why. I don't have all the answers, but I have some.

Of late, at any given time, maybe 6 or so people might be actually speaking. Most readers here will realize that having even 10% of 500 users - 50 people - all talking at once is totally unmanagable in any sense. No possible coherence can be made out of such a jumble of voices. So, it's a good thing that so few people generally speak at any given time. And since there are only so many slices of time - say 2 minute slices - in a 24 hour period, in reality in any given day or week, only a fraction of the 500 users are heard from. This poses a question I have never seen a (convincing) answer for: what exactly are the 450-odd people that I never see send anything to the channel, doing there? What are they getting out of it? Finally I can only guess that they are getting a benefit similar to what I described in my opening paragraph: briefly put, the chat keeps them company on some level. Perhaps for some more than others, loneliness or a sense of being disconnected from whatever people they have around them is a constant condition.

That's all been analyzed (probably to death) already in other places by writers with more skill and insight than I possess. What I was enjoying about #perl on Freenode was not merely the sensation of having a conversation going on nearby, however, but also I enjoy being active in the channel and discussing things with some of the participants. I don't represent myself as a helpful guy. In fact, I've been very vocal about not being there to help people with arbitrary requests for support of some sort (I word it this way because it is clear that some people are there with needs other than the supposed purpose of the channel - some want hand-holding; some want an argument to participate in; some want scripts written for them; etc) ... instead, I am vocally honest about the fact that I am there to discuss things that I am interested in (and fortunately for me that includes a lot of different areas); and if helping someone is a by-product or side effect of my conversing with others, I am extra happy.

People like us

People who are "like us" (hackers, programmers, technologists) who blog or do online journals have commented on a large number of occasions, that I have seen, about how IRC (and related forms of online realtime conferencing) can hurt their personal productivity, and how they had to make changes in their habits about it. Some have had to give it up entirely, others have made themselves allot only short spans in any given day to IRC. For myself, and I am a very addictive type of personality, I felt that I had finally reached a nice balance. I was doing IRC on Freenode's #perl with a continual sense of awareness of how many minutes were being given to any one conversation or topic or request for help from a user. That allowed me to feel that the long-term prospects of being a positively contributing participant on #perl were good. With that sense of balance, I offered to the channel owner, my services as an IRC chanop. So for the last 3 months I've been not only a regular participant but also someone charged with some responsibility to provide for maintaining order and a modicum of peaceful enjoyment for the users of the channel.

A lot of past experience had prepared me, I felt, for this role. I had been an active participant - sometimes a notoriously opinionated one - on Perlmonk's chatterbox since joining the site shortly after its beginning (since June 2000, to be precise). I'd spent plenty of time on IRC before and during that time. My time using realtime online conferencing media extends back to the days of CompuServe and its Forums.

I am finally coming to the realization, however, that the negative aspects of online chat "communities" extend beyond harm to personal productivity or even to one's physical health (lack of sleep, neglect of healthy lifestyle activities) or to one's family dynamics or social life. They seem to me to foster a number of different kinds of passivity combined with a willingness to submit to "groupthink" and a deadening of sensitivity to and even awareness of the wider realms of human existence outside of a small subset of humanity that programmer/computer geeks think of as "their type of people". And there is another kind of damage that is being done as well.

The #perl channel is perhaps one of the sicker communities I have ever come across, and if the reader's experience is not closely similar to mine, they may think I am either exaggerating or, conversely, unaware of how bizarre some channel on Network X that they have been in is. Rest assured that I am aware of Network X, and rest assured that I am on the other hand, not exaggerating.

Hypocrisy and self-delusion

A reader may well argue that online chat communities are simply a microcosm of what is prevalent in the post-industrial civilization which we are part of. And they would be right. What is strongly characteristic of #perl and channels similar to it is, however, that active participants rarely seem to achieve awareness of this. They clearly find it most congenial to speak in world-weary tones of how stupid the larger population is as a mass; of how idiotic the leaders of countries are, of what a shame it is that the world is such a mess. They thereby apply a sheen of superiority to themselves and each other as special ... a superior breed, perhaps forced unfairly to exist in this world of doltish ignorant cretins and liars with selfish motives. Trying to speak in positive, hopeful terms about the world at large and what its destiny might be, is a surefire way to make ones' self the immediate target of derision. That's pretty sick. But the negativity does not stop there.

I've written before in this Journal about groupthink and the fearsome phenomenon of mob behavior, the selection of those "different" as scapegoats, etc. The irony is that that people I meet online in such places as Perlmonks or #perl on Freenode do not understand to what degree they are part of a group and, over time, being influenced in their attitudes and shaped in their outlook by that group. The myth of staunch individualism and the sense that each is an entity unto itself, with only a loose affiliation to the others that they spend (in some cases) hours each day with, reigns over each participants' understanding of themselves. This sense of solitary independence of thought only disperses briefly when an external threat appears - typically either an Internet/IRC troll or a person egregiously breaking the rules of conduct of the channel in some unambiguous, unequivocal manner. At those times, the hidden, latent herd instinct or pack dynamic or multicellular organism reality becomes briefly revealed, and then goes back into hiding once the "threat" or disturbance is removed. It boggles the mind to realize that this collective delusion, this total disconnect between what people think their conciousness is up to, in contrast to what is really going on ... is repeated 10s of thousands of times over each and every day, to one degree or another, on IRC networks and in other chatrooms across the Internet. Day in, day out. 24/7/365, as we technogeeks like to say.

But rather than rehash that topic, as pertinent as it might be to #perl on Freenode, I am going to talk about how I think that such online chat locations actually damage the future of Free Software as a movement and an ideal, and how the hypocrisy of the typical chatroom/channel participant is coming to be reflected in the continuing narrow range of ethnicities and genders that comprise the "Open" Source world as seen both online and at conferences and conventions. Next time.

The hell you sed

somian — 2007-03-14T05:33:18+00:00

Just to be perverse, I'll post my little cli sed program ... written to snag a couple much-liked fonts from the FONTS directory of one of my MS Windows machines, so I can use it on GNU/Linux.
ls -1 \ /cdv/c/winnt/fonts/{Min,Myr}*.[Tt][Tt][Ff] | sed -n '{s^$.\+$\.ttf$^\1^;h;s^ ^_^g;s:.\+/$[^/]\+$:./\1.ttf:;x;s:\n: :g;s: :\\ :g;s:$:.ttf:;G;s:\n: :g;p;s:.*::;h}' | xargs -L 1 install -vm 0664

Isn't that beautiful? ;-P

Make me more portable!

somian — 2006-11-22T15:12:24+00:00

The scenario, in brief:

One has a removable media device (say, like a USB (thumb|key)drive); and one wants to carry a bunch of Perl modules around on it, mounting it to a workstation as needed, and including the path to the modules in @INC (via the $PERL5LIB mechanism). This could involve use on a UNIX workstation or an MS Windows one, for example; it does not matter.

Installing modules to this (USB?) removable (thumb|key)drive in the normal manner involves setting a PREFIX= and possibly LIB= parameters for ExtUtils::MakeMaker -based module build-infrastructure supported modules, or the parallel means for a Module::Build -based one. Then you just go do the make ; make test ; make install or Module::Build analog as you would for any module installation. I guess for some readers this is going to sound like an exotic thing to envision, but for the author this is not. I've been doing things like this with the manual installation of modules for years. I understand all the mechanisms and gotchas involved, and IMHO the support for this in Perl is very good and the results I get are very satisfying.

The Problem:

When the build host is UNIX (i.e. GNU/Linux) the make process will create man pages for all detected *.pm *.pl and *.pod files. This is "normal" for the architecture / os type and I like and want the manpages to be installed to the file hierarchy on the removable media drive. However, the filenames of man files produced from the POD in modules are like Module::Kewl::Excelsior.pm3 on a UNIX system. Note the double-colons (::).

The filesystem of a USB (thumb|key)drive is (nearly ?) invariably FAT32 as shipped by the manufacturer (and for my purposes, for maximum portability, needs to be kept that way). A FAT-ish filesystem, having originated from MS DOS, does not accept colons : as part of filenames. They are (obviously) barred from the set of ascii characters allowed because of the special semantic meaning they have on an MS DOS-ish / Windows-ish system. The result is that the manpages cannot be written to the removable FAT/FAT32 media at make install time, possibly generating error messages or possibly just failing silently (the error message will be the ubiquitous and vastly informative MS Windows error No such file or directory).

I like manpages (or the moral equivalent like info pages). Manpages are goodness to me. They give me a feeling of reassurance that I have the proper up to date documentation (assuming the module dist maintainer is keeping the documentation in sync with the changes ;-) for the code I am using. Bare-bones Debian and Debian-based systems don't ship with a perldoc command (one is available as a separate Debian package), so that's an instance where having manpages built is substantially important to having the POD accessible to me as the user. This is about personal preference anyway.

Possible solutions:

On Cygwin (http://www.cygwin.com/), which is UNIX but lives within the special needs of the MS Win filesystem semantics WRT special characters and filenames (AUX, PRN, NUL, etc), the manpages are usable and are built. The EU::MM_Cygwin (http://cpan.uwinnipeg.ca/htdocs/ExtUtils-MakeMaker/ExtUtils/MM_Cygwin.pm.html) module overrides the default EU::MM method which generates make recipes to build manpages from module or script files; it provides a . (dot) in place of the :: (double-colon) in creating the filenames for the man pages that will be copied into place when everything installed.

A solution like the one used by Cygwin(perl) is great and is what I think I want, but it requires one to make some change to the files included in the module distribution; either some hand-editing or some addition of files or both. Can anyone think of a way to achieve this manipulation of EU::MM (or M::B) operations that doesn't require that kind of a tedious manual operation for each module to be built/installed to the removable media drive? Or does anyone have a suggestion for a new method or parameter or functionality for EU::MM or M::B that would allow for changing the manpage filename namespace delimiter to be compatible with FAT filename semantics?

I can envision for example a $PERL_MM_USE_MANFILE_SEP=. environ var that if present would trigger the desired overidding.

If you are a Perlmonks reader, then yes, you've seen this topic posted there as node id 585526 : "manpages file naming - a filesystem difference dilemma" in the SoPW section of the Monastery.

Housecleaning CygwinPerl's build-time config

somian — 2006-11-13T16:17:38+00:00

I've been working for about 10 days now on renovating the
build configuration for the production of perl5 (5.8) on the
Cygwin platform. In order to not lose what I've learned in
doing this, I'm going to make some notes here.

One of the first things that comes to mind is that the entire
process has been like peeling away layers of an onion -- and
finding that the bad spots just go deeper and deeper. The more
peeled away, the worse the onion looks. The fact is that
cygperl's build works (where "works" could be defined as
"produces a final perl for installation that is more or less
viable") only (partly) by accident.

The absurd amount of time and CPU is takes to build and
install an average module for cygwinperl was part of the
reason for undertaking this housekeeping project. I don't have
figures to cite (atm), but what takes a few seconds on
a typical gnu/linux machine takes many minutes with cygperl,
and if the module is an extention (involves C compilation), it
is far worse.

Many files are involved in Perl's strange build configuration
mechanism. A few that impact this specific build are listed
here:

Makefile.SH
Policy.SH
hints/cygwin.sh
ExtUtils/MakeMaker/MM_Cygwin.pm
cygwin/Makefile.SHs
cygwin/perlld.in
cygwin/ld2.in

As I've been drawn further and further into trying to get
everything "right" in the final product of the build process,
I have realized that apparently, successive contributors to
cygperl have never read or never read and thought much about
the principles and explanations contained in Porting/Glossary
or hints/README.hints. These files contain essential
information about how things actually work, that people doing
this kind of project really need to know. One of the amazing
facts spotted by reading hints/README.hints, for example, is:

* the hints/[architecturename].sh file is not actually
evaluated as a shell script! It may be called a shell
script, have a shebang line at the top, and may have
an .sh extention, but these files are actually read
by Configure using simple line-by-line sed processing!

The result is (as explained in hints/README.hints) that such
things as an sh 'case' statement to set a variable value based
on some condition will not do what the hintsfile writer thinks
it will do. Yet cygperl's hintsfile had several such case
statements.

[To Be Continued]

Stalkerazzi Solution

somian — 2006-04-12T03:58:24+00:00

Watching the antics of stalkerazzi on VH1 TV recently, I came up with a fevered notion that seems nevertheless rather good to me.

The fan clubs for performers seem to be basically a mechanism by which people can get some kind of chance to feel like they are touching the lives of people they feel have touched them through their art. So why not give fans a way to make a real difference in the lives of the performers they are so madly fond of ...

Fan clubs could set up a Net-based mechanism to accept anonymous donations. Maybe those would have to be handled through offshore bank accounts, etc. These donation -- $5, $15, $25 at a time -- could be allowed to accumulate until a couple thousand dollars was available (more or less -- not having any contacts in the underworld, I have no idea really what people need for the kind of illegal services I'm proposing).

The club then could arrange to contract (secretly) with a "security company" to stalk stalkerazzi. Wherever the celebrity performer goes, there are the stalkerazzi, and there are the operatives taking photos, recording sound, and noting license plates of these subhuman fungi. Then when background research has been done, the worst offending stalkerazzi is selected and made the target of a vicious, medically severe beating that puts them into the hospital for weeks and possibly costs them permanent loss of some manual dexterity, eyesight, or hearing. This encounter with the operatives executing the administration of corrective violence would of course take place outside the stalkerazzi's home, or a bar they frequent, or anywhere else and in any other circumstance where they can be confronted alone and the performer they've been stalking is miles and miles away.

The professionalism of the "security company" is the weak link here, as far as I can see it. Unfortunately it seems that illegal drug addiction and other forms of mentally handicapping situation often go along with the professional vocation of being "muscle". But just one or two really professionalistic and careful outfits that could execute such a contract perfectly on several occasions might make a large part of the stalkerazzi problem "just go away".

Sorry if you, the reader, experiences unpleasant nervous system reactions (shock) to reading this purely conjectural proposal. If you have, I'll ask you to remember that you'll be over it in about 5 minutes. Try now to imagine the shock of having strangers confront you, of having lenses thrust towards you, over and over again, day after day, week after week, month after month, at the most unexpected and private moments when your guard is down ... try to imagine what that might do to the general condition of your nervous system, and to your outlook on life.

A tough critter: Net::Pcap on cygwin

somian — 2005-11-10T07:27:14+00:00

A fellow Perler asked me recently if I had ever installed the module Net::Pcap on a cygwinperl system. I had not and decided to look into what might might be going wrong for her.

As an interface to the external pcap library (written in C) the module uses XS and requires compilation. It is a fairly complex build and the authors have gone to a lot of trouble to write a very long Makefile.PL with elaborate "detection" routines. It still seems not to work (and as of this writing, no Net::Pcap release has ever passed on the cygwin platform, according to cpan-testers).

After setting up the WinPcap developers' pack and using the location of its lib and include files as arguments to 'perl Makefile.PL' I saw first errors relating to the detection code (which I'll detail later). After adjusting code in the Makefile.PL to fix them, I got into the test-compilation phase of the Makefile.PL routines and saw a torrent of C compiler errors and warnings flood the console screen. Those errors are thus (filtered through the following pipeline to make them more readable and succinct)

perl Makefile.PL LIBS="-L$W32LIB -lwpcap" INC=-I$W32INCL 2>&1 | perl -naF: -MCwd=realpath -le 'next unless /error/; $pn=$F[0]; $F[1]=~s{/DOCUME~1/SORENS~1/MYDOCU~1/}{/};print "",($pn =~m ? realpath(shift @F):join ":"=>splice(@F,0,2)), join(":"=>"",@F)'

ERRORS

C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:271: error: redefinition of `struct timespec' C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:503: error: conflicting types for 'pthread_t' /usr/include/cygwin/types.h:208: error: previous declaration of 'pthread_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:504: error: conflicting types for 'pthread_attr_t' /usr/include/cygwin/types.h:212: error: previous declaration of 'pthread_attr_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:505: error: conflicting types for 'pthread_once_t' /usr/include/cygwin/types.h:223: error: previous declaration of 'pthread_once_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:506: error: conflicting types for 'pthread_key_t' /usr/include/cygwin/types.h:211: error: previous declaration of 'pthread_key_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:507: error: conflicting types for 'pthread_mutex_t' /usr/include/cygwin/types.h:209: error: previous declaration of 'pthread_mutex_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:508: error: conflicting types for 'pthread_mutexattr_t' /usr/include/cygwin/types.h:213: error: previous declaration of 'pthread_mutexattr_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:509: error: conflicting types for 'pthread_cond_t' /usr/include/cygwin/types.h:215: error: previous declaration of 'pthread_cond_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:510: error: conflicting types for 'pthread_condattr_t' /usr/include/cygwin/types.h:214: error: previous declaration of 'pthread_condattr_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:512: error: conflicting types for 'pthread_rwlock_t' /usr/include/cygwin/types.h:224: error: previous declaration of 'pthread_rwlock_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:513: error: conflicting types for 'pthread_rwlockattr_t' /usr/include/cygwin/types.h:225: error: previous declaration of 'pthread_rwlockattr_t' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:1082: error: conflicting types for 'pthread_kill' /usr/include/sys/signal.h:163: error: previous declaration of 'pthread_kill' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/pthread.h:1082: error: conflicting types for 'pthread_kill' /usr/include/sys/signal.h:163: error: previous declaration of 'pthread_kill' was here /usr/include/w32api/winsock2.h:101: error: redefinition of `struct timeval' /usr/include/w32api/winsock2.h:112: error: redefinition of `struct hostent' /usr/include/w32api/winsock2.h:120: error: redefinition of `struct linger' /usr/include/w32api/winsock2.h:147: error: redefinition of `struct netent' /usr/include/w32api/winsock2.h:153: error: redefinition of `struct servent' /usr/include/w32api/winsock2.h:159: error: redefinition of `struct protoent' /usr/include/w32api/winsock2.h:215: error: redefinition of `struct in_addr' /usr/include/w32api/winsock2.h:246: error: redefinition of `struct sockaddr_in' /usr/include/w32api/winsock2.h:327: error: redefinition of `struct sockaddr' /usr/include/w32api/winsock2.h:515: error: conflicting types for 'accept' /usr/include/sys/socket.h:29: error: previous declaration of 'accept' was here /usr/include/w32api/winsock2.h:515: error: conflicting types for 'accept' /usr/include/sys/socket.h:29: error: previous declaration of 'accept' was here /usr/include/w32api/winsock2.h:516: error: conflicting types for 'bind' /usr/include/sys/socket.h:30: error: previous declaration of 'bind' was here /usr/include/w32api/winsock2.h:516: error: conflicting types for 'bind' /usr/include/sys/socket.h:30: error: previous declaration of 'bind' was here /usr/include/w32api/winsock2.h:518: error: conflicting types for 'connect' /usr/include/sys/socket.h:31: error: previous declaration of 'connect' was here /usr/include/w32api/winsock2.h:518: error: conflicting types for 'connect' /usr/include/sys/socket.h:31: error: previous declaration of 'connect' was here /usr/include/w32api/winsock2.h:520: error: conflicting types for 'getpeername' /usr/include/sys/socket.h:32: error: previous declaration of 'getpeername' was here /usr/include/w32api/winsock2.h:520: error: conflicting types for 'getpeername' /usr/include/sys/socket.h:32: error: previous declaration of 'getpeername' was here /usr/include/w32api/winsock2.h:521: error: conflicting types for 'getsockname' /usr/include/sys/socket.h:33: error: previous declaration of 'getsockname' was here /usr/include/w32api/winsock2.h:521: error: conflicting types for 'getsockname' /usr/include/sys/socket.h:33: error: previous declaration of 'getsockname' was here /usr/include/w32api/winsock2.h:522: error: conflicting types for 'getsockopt' /usr/include/sys/socket.h:44: error: previous declaration of 'getsockopt' was here /usr/include/w32api/winsock2.h:522: error: conflicting types for 'getsockopt' /usr/include/sys/socket.h:44: error: previous declaration of 'getsockopt' was here /usr/include/w32api/winsock2.h:523: error: conflicting types for 'inet_addr' /usr/include/arpa/inet.h:22: error: previous declaration of 'inet_addr' was here /usr/include/w32api/winsock2.h:523: error: conflicting types for 'inet_addr' /usr/include/arpa/inet.h:22: error: previous declaration of 'inet_addr' was here /usr/include/w32api/winsock2.h:524: error: conflicting types for 'inet_ntoa' /usr/include/arpa/inet.h:28: error: previous declaration of 'inet_ntoa' was here /usr/include/w32api/winsock2.h:524: error: conflicting types for 'inet_ntoa' /usr/include/arpa/inet.h:28: error: previous declaration of 'inet_ntoa' was here /usr/include/w32api/winsock2.h:525: error: conflicting types for 'listen' /usr/include/sys/socket.h:34: error: previous declaration of 'listen' was here /usr/include/w32api/winsock2.h:525: error: conflicting types for 'listen' /usr/include/sys/socket.h:34: error: previous declaration of 'listen' was here /usr/include/w32api/winsock2.h:526: error: conflicting types for 'recv' /usr/include/sys/socket.h:35: error: previous declaration of 'recv' was here /usr/include/w32api/winsock2.h:526: error: conflicting types for 'recv' /usr/include/sys/socket.h:35: error: previous declaration of 'recv' was here /usr/include/w32api/winsock2.h:527: error: conflicting types for 'recvfrom' /usr/include/sys/socket.h:37: error: previous declaration of 'recvfrom' was here /usr/include/w32api/winsock2.h:527: error: conflicting types for 'recvfrom' /usr/include/sys/socket.h:37: error: previous declaration of 'recvfrom' was here /usr/include/w32api/winsock2.h:528: error: conflicting types for 'send' /usr/include/sys/socket.h:39: error: previous declaration of 'send' was here /usr/include/w32api/winsock2.h:528: error: conflicting types for 'send' /usr/include/sys/socket.h:39: error: previous declaration of 'send' was here /usr/include/w32api/winsock2.h:529: error: conflicting types for 'sendto' /usr/include/sys/socket.h:42: error: previous declaration of 'sendto' was here /usr/include/w32api/winsock2.h:529: error: conflicting types for 'sendto' /usr/include/sys/socket.h:42: error: previous declaration of 'sendto' was here /usr/include/w32api/winsock2.h:530: error: conflicting types for 'setsockopt' /usr/include/sys/socket.h:43: error: previous declaration of 'setsockopt' was here /usr/include/w32api/winsock2.h:530: error: conflicting types for 'setsockopt' /usr/include/sys/socket.h:43: error: previous declaration of 'setsockopt' was here /usr/include/w32api/winsock2.h:531: error: conflicting types for 'shutdown' /usr/include/sys/socket.h:45: error: previous declaration of 'shutdown' was here /usr/include/w32api/winsock2.h:531: error: conflicting types for 'shutdown' /usr/include/sys/socket.h:45: error: previous declaration of 'shutdown' was here /usr/include/w32api/winsock2.h:532: error: conflicting types for 'socket' /usr/include/sys/socket.h:46: error: previous declaration of 'socket' was here /usr/include/w32api/winsock2.h:532: error: conflicting types for 'socket' /usr/include/sys/socket.h:46: error: previous declaration of 'socket' was here /usr/include/w32api/winsock2.h:533: error: conflicting types for 'gethostbyaddr' /usr/include/netdb.h:139: error: previous declaration of 'gethostbyaddr' was here /usr/include/w32api/winsock2.h:533: error: conflicting types for 'gethostbyaddr' /usr/include/netdb.h:139: error: previous declaration of 'gethostbyaddr' was here /usr/include/w32api/winsock2.h:534: error: conflicting types for 'gethostbyname' /usr/include/netdb.h:140: error: previous declaration of 'gethostbyname' was here /usr/include/w32api/winsock2.h:534: error: conflicting types for 'gethostbyname' /usr/include/netdb.h:140: error: previous declaration of 'gethostbyname' was here /usr/include/w32api/winsock2.h:535: error: conflicting types for 'getservbyport' /usr/include/netdb.h:149: error: previous declaration of 'getservbyport' was here /usr/include/w32api/winsock2.h:535: error: conflicting types for 'getservbyport' /usr/include/netdb.h:149: error: previous declaration of 'getservbyport' was here /usr/include/w32api/winsock2.h:536: error: conflicting types for 'getservbyname' /usr/include/netdb.h:148: error: previous declaration of 'getservbyname' was here /usr/include/w32api/winsock2.h:536: error: conflicting types for 'getservbyname' /usr/include/netdb.h:148: error: previous declaration of 'getservbyname' was here /usr/include/w32api/winsock2.h:537: error: conflicting types for 'getprotobynumber' /usr/include/netdb.h:146: error: previous declaration of 'getprotobynumber' was here /usr/include/w32api/winsock2.h:537: error: conflicting types for 'getprotobynumber' /usr/include/netdb.h:146: error: previous declaration of 'getprotobynumber' was here /usr/include/w32api/winsock2.h:538: error: conflicting types for 'getprotobyname' /usr/include/netdb.h:145: error: previous declaration of 'getprotobyname' was here /usr/include/w32api/winsock2.h:538: error: conflicting types for 'getprotobyname' /usr/include/netdb.h:145: error: previous declaration of 'getprotobyname' was here /usr/include/w32api/winsock2.h:607: error: parse error before '(' token /usr/include/w32api/winsock2.h:607: error: parse error before '?' token /usr/include/w32api/winsock2.h:608: error: parse error before '(' token /usr/include/w32api/winsock2.h:608: error: parse error before '?' token /usr/include/w32api/winsock2.h:609: error: parse error before '(' token /usr/include/w32api/winsock2.h:609: error: parse error before '?' token /usr/include/w32api/winsock2.h:610: error: parse error before '(' token /usr/include/w32api/winsock2.h:610: error: parse error before '?' token /usr/include/w32api/winsock2.h:611: error: conflicting types for 'select' /usr/include/sys/select.h:31: error: previous declaration of 'select' was here /usr/include/w32api/winsock2.h:611: error: conflicting types for 'select' /usr/include/sys/select.h:31: error: previous declaration of 'select' was here /usr/include/w32api/winsock2.h:614: error: conflicting types for 'gethostname' /usr/include/sys/unistd.h:206: error: previous declaration of 'gethostname' was here /usr/include/w32api/winsock2.h:614: error: conflicting types for 'gethostname' /usr/include/sys/unistd.h:206: error: previous declaration of 'gethostname' was here C:/PROJEC~1/CVS_SR~1/WinPcap/include/bittypes.h:71: error: conflicting types for 'int32_t' /usr/include/stdint.h:20: error: previous declaration of 'int32_t' was here /usr/include/w32api/ws2tcpip.h:124: error: redefinition of `struct ip_mreq'

That's a pretty discouraging output.

Perlmonks Haunted by the Ghost of Wassercrats

somian — 2005-10-19T04:44:54+00:00

A reminder: the author of this Journal is known over at Perlmonks.org as Intrepid.

There is a haunting going on over at Perlmonks.org, and I thought I should say something about it, although what effect my doing so could have on the situation, I do not know.

A former participant at Perlmonks named himself with the decidely odd handle "Wassercrats" and proceeded to become an active poster in the Perlmonks community. During his rather brief period of activity there (in 2004), he did not endear himself to the general user community by posting nodes such as http://www.perlmonks.org/?node_id=386089 or this http://www.perlmonks.org/?node_id=323102 ... to say he was eager in his presentation of extremely unpopular opinions would be, uhhh, a mild understatement. His manner both in the Perlmonks Chatterbox (site chat facility) and in his nodes (writeups) was one that brought him notoriety beyond that of any participant before or since, despite the truth that many Monks would have preferred that he be forgotten as quickly as possible. In fact his negative fame is of such magnitude and persistance that just this evening, before composing this entry, he was brought up in the Chatterbox by one of the regulars.

It has occured to me both this evening and at other times in the past that "Wassercrats" haunts Perlmonks with a tenacity that bears noting for its cautionary import.

"Wassercrats" left Perlmonks in a cloud of acrimony and a stench of bitterness. He became more and more defiant over the course of his history there, "shouting" much invective against the wall of community opinion that was his subjective experience at Perlmonks. That written invective (much of which is now, to my understanding, in nodes that have been put "away" by editorial staff) always seemed to be calculated to make those reading more inclined to regard him with contempt, rather than to win friends or even make people slightly more inclined to tolerate him.

However, I myself was present at times late in "Wassercrats" brief tenure when I witnessed him in the Chatterbox behaving in a mild, friendly and jovial manner with those present, or attempting to (I'd add in explanation that although I have been a participant at Perlmonks since only shortly after its unveiling, I have taken periods of varying duration "off" and had not been attentive continuously for this accounted timespan). I noticed with a considerable degree of personal discomfort that his attempts to enjoy chatting amiably with others were met with a constant rebuff of attacks and mean-spirited put-downs, attempts to pull him back into past disputes, and similar bad-intentioned attempts at emotional manipulation on the part of nearly every Chatterbox-monk who was reacting to his presence in any way.

I was personally disconcerted by the degree of antagonism shown a person who was, in my perception, clearly weary of being at odds with an entire user community and longing for a little simple company ... but I was even more disturbed by the fact that not one speaker at a time, but several in tandem were exibiting this aggressive hostility. It simply wasn't possible to witness without there being a vision of a bunch of little boys standing around a single skinny (or overweight) kid taunting and throwing things at him.

I have absolutely no doubt in my mind that a considerably number of persons at Perlmonks, manyof them still regulars there, behaved in a really despicable fashion towards "Wassercrats". His penchant for self-promotion, for making broad characterizations of the Perlmonks community, his abrasive, confrontational style, his attempts to "critique" the Perl language and its cultural conventions without establishing any "cred" for himself first: yes, all these things made his poor reception inevitable. But these alone do not excuse a part of a community of people for becoming a mob and behaving in the manner that they did.

I hope the knowledgable reader will forgive my doing a brief bit of tangential prose at this point. I am afraid that the extremely underdeveloped ethical sense of some of the potential readers of this journal make it seem necessary to me.

In the study of human social history and literature, the study of the mind and of symbol and metaphor throughout known human history, we come upon a phenomenon which has come to be known (in English) as the scapegoat. A scapegoat is a person who is made to suffer by a village or community; and whose being made a sacrifice by that community somehow sooths the anxieties or fears of the mass of members of that community. The part of the word that is "goat" readily summons to mind the image of domesticated livestock being tied to a post and killed with a sharp knife or a dull club.

"Wassercrats" was a scapegoat. The "Monks" over there at Perlmonks who became thirsty to see his blood (which is to say, in the non-metaphorical sense, to quit ever using Perlmonks again, preferably accompanied by a parting blast of hurt and anger - all my readers have seen such a "flame-out" and know what I am describing) ... these folks became inebriated with one of the most ancient and malevolent of humanity's intoxicants: the drive to "kill" the most self-despised flaws in one's own inner/spiritual/moral being (one's "heart") by "killing" an external symbol of those flaws.

Make no mistake abut it. "Wassercrats" failings were no different in kind from those of many other Perlmonks ; they only differed in the degree to which they were flagrantly expressed. I witness the same mental warts surfacing on a daily basis (during a bad week), now that Wassercrats is long "dead": the premature arrogance of those who have learned half or 3/4 of what there is to know about some computer technology, but speak as if they know it all; the utter ruthlessless in the ego of those who feel challenged on a technical point (causing them to try any argumentative ploy they think will work, displaying no regard for whether the truth is being forgotten in the process); the inability to self-reflect and see with any clarity that something is clouding their perceptions of others' intent or meaning. Wassercrats displayed all these foibles to such an absurdly exaggerated degree that he allowed the onlookers at Perlmonks to fall under the completely deluded miscomprehension that they themselves were completely or even mostly free of them.

There are those who may read this entry with no thought other than how to discourage anything remotely like it from issuing forth from my not-so-nimble fingers in the future, or how to provoke (if given the chance) a reaction from me that they think, in a calculating sense, would lessen my credibility as a witness and describer of this little morality tale from Perlmonk's recent past. Those are the people who are in fact not only haunted by the ghost of Wassercrats, but truly possessed by it.

Those who are most quick to feel a prickle of self-doubt upon reading this, maybe a touch of shame, are the ones least in need of entertaining the company of such feelings for any length of time.

Arrogance is apparently widely misunderstood amongst the part of the Perlmonks community which I've come to know as "the thick-headed lot." Arrogance is understood as a deceiver in the Buddhist traditions, those traditions which have made a systematic and thorough investigation of the different phenomena of human conciousness for a very long time. Arrogance causes itself to disappear from the sight of those afflicted by it, so that it can do its chosen work of undermining the perceptual accuracy as well as the moral standing of those under its sway. It is a huge blind spot right in front of the faces of the afflicted, that they cannot see at all. The reason that Arrogance possesses this capability and manifests this function in human conciousness is that it is quite vulnerable to human volition, free will and genuine intellect when it begins to be exposed. There is no more effective way to raise the ire of the truly arrogance-bespelled person than to sharply point out the malfunction in their conciousnesss at this time, that is being caused by the dominance of Arrogance. The outlashings of rage (sometimes hot but often cold) that are often witnessed are the flailings of the threatened disease - they are the infection in the ego of the afflicted person expressing its urgent need to, beyond all else, avoid having its name spoken aloud, its existence recognized to its host and victim.

Arrogance is not merely a minor character defect of the overly-confident or the perpetually insecure. It is actually a serious, self-perpetuating, chronic illness that undermines the health of the victim's relationships with those around him. Many people can smell the rot of that infection on the afflicted person from a long way off (and avoid the bearer like they would a plague carrier). Those who are themselves fairly to severely afflicted cannot, however, in many cases; they instead often band together for mutual protection, for the cover that membership in a group provides to them.

Wassercrats provided a part of the Perlmonks community a chance to project upon a person (in whose defense it was clear that no voices would be raised) ... that group pathology that plagues the intellectually self-congratulatory and socially insecure. The irony abounds, because some of the Perlmonks I know from the Chatterbox are Gay, some are lifelong-overweight, some have speech impediments or learning disabilities, some belong to ethnic minorities: this is a group of people that taken in toto really ought to have known better and done better. Not all Perlmonks are "geeks" (and surely not all are "nerds": some are married to beautiful spouses, some are beautiful themselves - some are beauty pageant queens!) ... but after all it *does* take a different sort of person to land in a job administrating a UNIX system all day long, or writing code until 4am every morning, or working hard enough to grasp what's up with polymorphic inheritance or lexical closures ;-) ... a person who is a bit out of the ordinary, anyway.

To those readers from Perlmonks who still mention Wassercrats with a sneer of prideful contempt, as I saw tonight, I'd just like to remind you that you really ought to be seriously and non-transiently ASHAMED of yourselves. When you speak Wassercrat's name, you ought do so in hushed tones, and with eyes cast downwards. You may be a Perlmonk now, but the need for you to be a human being is going to last a lot longer. You need to disengage your overfed head for a moment and engage your malnourished gut. No victory was accomplished for or by anyone when Wassercrats left under those conditions.

Subverting ActivePerl Part II

somian — 2005-10-13T01:04:31+00:00

This continues an informal account of what I have done to have full access to CPAN modules under ActiveState's Perl for Win32 distribution (binary build package). Part 1 was published to my Journal previously.

In the first installment I mentioned that `make' plays a crucial role in the building of Perl modules from CPAN source tarballs. I have a personal aversion to the approach to installation of software on my system that regards the installation infrastructure (a.k.a. build apparatus) as a "black box" that I am foolish to want to open or know about. Some Perlers seem to regard module installation this way, but I do not. If the reader is one of those people who finds it religiously necessary to view the module installation process as "need to know only", or cannot grok just examining a thing simply out of a desire to understand how it works, I suggest that reader stop now and go find something else to do.

Since `make' is integral to the build-install process (it is assumed all readers know the canonical Perl installation quatrain and I won't cite it here) with any module employing the traditional MakeMaker utility system, I expect it to understand (parse and successfully execute) the Makefile that MakeMaker generates; but I also expect that sometimes it won't "just work." In the cases where it doesn't, I want to be able to fix the problem myself. I develop in C as well as in perl, and I build packages created by other developers in C; so I use the `make' tool in those other contexts as well. I see no sense or reason why I must submit to being force to use a different `make' tool for building Perl modules than the one I use ordinarily for general compilation tasks. In particular, the notion of using the `nmake' tool from MS is noxious and backwards to me. I will not do it.

Both the BSD make (a.k.a `pmake') and the GNU make (a.k.a. `gmake') are good, full-featured tools that are capable of managing highly complex systems of dependencies. So also is the `dmake' tool, which has suffered from not having very much documentation until rather recently. The OpenOffice.org people are using dmake to build OpenOffice on Win32 systems and are maintaining the source and documentation for it now; it can be obtained from their anonymous CVS repository. The other `pmake', the pure perl implementation mentioned in the first installment, isn't being developed any further, but might still suit some needs of some users.

So I strongly prefer, in fact, demand, to be able to use the `make' I am used to, to do the job of building CPAN modules. GNU `make' fits the bill nicely for me, and of course Cygwin supplies it. If one does not want to use Cygwin for some reason, there is also a GNU `make' provided by MinGW. See the following note, however, for why you might not want to go this route.

Note: The MinGW make requires a little bit of further discussion. At the time of this writing the MinGW-supplied make is somewhat "deprecated" by being named mingw32-make.exe and is not up to the task of building Perl modules under ActivePerl without some help. The codebase for Cygwin's make and the MinGW make are different; mingw32-make.exe is probably based on the upstream (standard) GNU make source,I guess, whereas Cygwin changes theirs. There are issues with unpatched GNU make (at this time: 3.80) on Win32 which have yet to be worked out. These are mostly related to the handling of pathnames in the Win/DOS style.

I am working on the CVS development source for GNU make, as are other people, and maybe within the foreseeable future the note above will no longer apply.

I will be adding to this journal sequence at the earliest available opportunity.

A manpage for `dmake' is available online http://intrepid.perlmonk.org/mswin32perl/dmake/dmake-man.html if you happen to need some info on that tool.

Subverting ActivePerl ;-P

somian — 2005-06-03T12:08:20+00:00

This is an informal account of what I have done to have full access to CPAN modules under ActiveState's Perl for Win32 distribution (binary build package).

Here are some pre-existing niceties I have set up on my systems

The cygwin BASH shell

Everyone has heard of Cygwin, I'd think (although most don't mispronounce it as I do: I say "Sigh-Gwin" but most say "Cig-Win" ;-). The BASH shell is just like that which comes standard on most any Linux. I use both Linux (and *BSD) and MS Windows. I fail to see, although some have tried to convince me otherwise, why I must shift mental gears, readjust to a wholly different (and grossly inferior) cli environment, just because I've switched for a moment to MS Windows.

Since Cygwin is a comprehensive collection of ports of GNU software to MS Windows systems (that is, by installing the core of Cygwin you can then run many different packages that might not otherwise be available to MS Windows users), it naturally includes Perl. However, I do not regard it as necessary to limit one's self to using only CygPerl from the Cygwin bash shell. It might seem unnatural to some, but this is only a result of drawing artificial barriers in one's mind between the different complexities of MS Windows. So I run the native Win32 Perl by invoking scripts from the BASH shell as freely as I might do with the CygPerl interpreter.

The MinGW GCC suite

Not as many people have heard of MinGW, although it is certainly mentioned in the Perl documentation. It isn't generally necessary to have MinGW if you have Cygwin; the two have overlap (some of what is provided by Cygwin is also provided by MinGW, or vice-versa). The gcc available with Cygwin can be "run in MinGW mode" so to speak (by which is meant "run in such a way that only Windows API and and Windows native C-runtime library functions are called; none of what's changed or added by Cygwin is"). Exclusion of cygwin functionality is accomplished by using the -mno-cygwin flag for the gcc invocation commandline. To be complete, here I'll mention flags related to the flexibility of the "cygming" gcc port in how it builds code:

-mwin32

bring in the Windows header defines (the "Windows realm")
-mno-win32

the converse of above — exclude Windows realm.
-mconsole

select the Console sub-system of MS Windows OS's.
-mwindows

select the GUI sub-system.
-mcygwin

select the Cygwin realm
-mno-cygwin

the converse of above — exclude the Cygwin realm

make

The next piece of software plays a key role in installing all modules that use the traditional ExtUtils::MakeMaker -generated Makefile to direct the steps required. There are 4 possible flavours of `make' utility that could be found on an MS Windows system; none of them will be found on a plain, out of the box Windows.

dmake
make from GNU, also (better, in this case) found as gmake
pmake, unfortunately named, could mean two things: either a "pure Perl make" implementation done by Nick Ing-Simmons (http://search.cpan.org/~ni-s/Make-1.00/pmake), or a BSD make, although whether any port of the BSD make to Windows has been done, I do not actually know.
nmake from MS which can come with MSVC++ / Visual Studio or be downloaded (for $0, gratis).

It's my opinion that it might be better for working with Perl on MS Windows to run GNU make under the name "gmake", or would be if new entries for this were made in some few key places in the Perl source files (reason: because it disambiguates which of the many possible `make's we have available).

The Config parameter for ActivePerl is of course to use the MS nmake (since ActivePerl is built using MS tools). This can, however, be changed (which will be covered in the next posting of this journal series).

I will be adding to this journal sequence at the earliest available opportunity.