[28370] in Perl-Users-Digest
Perl-Users Digest, Issue: 9734 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 17 09:05:53 2006
Date: Sun, 17 Sep 2006 06:05:03 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 17 Sep 2006 Volume: 10 Number: 9734
Today's topics:
Re: Complex extensions in C xhoster@gmail.com
Re: Complex extensions in C <benmorrow@tiscali.co.uk>
Re: Complex extensions in C <sisyphus1@nomail.afraid.org>
Re: Learning perl - for experienced programmers cartercc@gmail.com
Re: Learning perl - for experienced programmers <john@castleamber.com>
Re: Learning perl - for experienced programmers <dha@panix.com>
Re: Learning perl - for experienced programmers cartercc@gmail.com
Re: Learning perl - for experienced programmers anno4000@radom.zrz.tu-berlin.de
Re: Learning perl - for experienced programmers <hjp-usenet2@hjp.at>
new CPAN modules on Sun Sep 17 2006 (Randal Schwartz)
Re: Perl compiler <sisyphus1@nomail.afraid.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 17 Sep 2006 00:03:13 GMT
From: xhoster@gmail.com
Subject: Re: Complex extensions in C
Message-Id: <20060916200422.203$8t@newsreader.com>
arne.muller@gmail.com wrote:
> Hello,
>
> I'm looking for some resources (books, web-sites, docs ...) on how to
> write complex perl extensions in C. I've read the perlxstut, but still
> don't understand how to convert complex types.
>
> Specificly, my C-routine needs a pointer to a structure, some members
> of this structure are pointers to type double arrays. On the perl side
> this structure is an object.
A Perl object or merely an opaque object held in Perl? I.E. does Perl have
to do anything with it, other than just pass the root pointer back into C?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Sat, 16 Sep 2006 19:28:37 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: Complex extensions in C
Message-Id: <lbstt3-nb1.ln1@osiris.mauzo.dyndns.org>
Quoth anno4000@radom.zrz.tu-berlin.de:
> <arne.muller@gmail.com> wrote in comp.lang.perl.misc:
> > Hello,
> >
> > I'm looking for some resources (books, web-sites, docs ...) on how to
> > write complex perl extensions in C. I've read the perlxstut, but still
> > don't understand how to convert complex types.
> >
> > Specificly, my C-routine needs a pointer to a structure, some members
> > of this structure are pointers to type double arrays. On the perl side
> > this structure is an object. The return value of the C function is a
> > different type of structure, but again containing pointers to array (on
> > the perl side this is an object).
>
> So you want to translate Perl objects (which presumably contain lists of
> numbers) into C structs for consumption by XS routines. The basic
> method is to use pack() to build the struct in a string. You pass the
> string to the XS routine as such and cast it to a (pointer to) the type
> of struct you have built. If you have got it right (which will be
> non-trivial), you'll find a workable struct in your XS program.
>
> You'll have to use the cumbersome "p" template to create pointers
> from one part of the string to another.
Note that there are nontrivial issues regarding struct packing and the
like (you will likely need a little C program to construct the pack
template for you using offsetof). You can also pass a hash to an XS
routine that then builds the struct by pulling the members out of the
hash in C.
It may be easier to make the Perl side properly OO, or implement a tied
hash/array, and keep the data in 'C format' all the time.
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
benmorrow@tiscali.co.uk
------------------------------
Date: Sun, 17 Sep 2006 13:21:34 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Complex extensions in C
Message-Id: <450cd331$0$22937$afc38c87@news.optusnet.com.au>
<arne.muller@gmail.com> wrote in message
.
.
>
> Specificly, my C-routine needs a pointer to a structure, some members
> of this structure are pointers to type double arrays. On the perl side
> this structure is an object.
For some basics on objects see
http://search.cpan.org/~ingy/Inline-0.44/C/C-Cookbook.pod#Object_Oriented_Inline .
There might be some other basic information on the same page that's useful,
too.
Cheers,
Rob
------------------------------
Date: 16 Sep 2006 18:56:50 -0700
From: cartercc@gmail.com
Subject: Re: Learning perl - for experienced programmers
Message-Id: <1158458210.425182.265900@d34g2000cwd.googlegroups.com>
Matt Garrish wrote:
> I'm not trying to convince you that Perl is the best language for every
> problem, I'm simply pointing out that your assertion that Perl is only
> good for x number of lines is naive.
I offered my opinion. You might consider it naive. That's okay, it
doesn't bother me in the slightest.
> I have two Perl web apps, one that
> exceeds 5000 lines of code in total in all the modules and the other
> that's probably well over 15000, and both are incredibly easy to
> maintain and extend as needed.
And I have six years of Perl web apps, and I was very explicit in what
I said: if all you're doing is filling a web page with content from a
database, a special purpose tool (like ColdFusion) is ideal for the
job. I certainly wouldn't say that all web applications are the same.
I'll also confess that I have written a number of web apps in Perl that
are totally en-extensible and impossible to maintain. Writing
maintainable code takes a certain amount of experience and maturity,
and I don't think any programmer starts off with experience and
maturity.
> Lines of code is not something I
> consider when choosing Perl over another language (except that I can
> usually write a similar application in far less than if I use Java or
> C#), nor is maintenance, because if you can't write maintainable code
> in one language it's unlikely you can do it in another as the
> principles aren't language specific.
Why, then, do you think that Java has become so popular for big
industrial applications, in contrast to Perl? If you look at job sites
(e.g., dice.com) you can form an opinion as to which languages are
being used for what. What does the industry use Java for, and what does
it use Perl for? Some languages are better for some things, and other
languages are better for other things. I totally agree with you about
the terseness of Perl, but Java incorporates some things that appeal to
the software sweatshops (or factories, if you prefer that term) like
jar, javadoc, single inheritance, strict variable typing, different
access modifiers, etc. Yes, these things are a pain in the arse, but
being able to forward engineer from UML diagrams (for example) is a
nice thing to have in your toolkit.
I don't really disagree with anything you've said. I think an IT
professional needs to be proficient in several languages. To me, a
person that takes the position that one language is The Silver Bullet
isn't leveraging the different technologies available to him.
CC
------------------------------
Date: 17 Sep 2006 02:55:05 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <Xns9840DEF624F05castleamber@130.133.1.4>
cartercc@gmail.com wrote:
> Why, then, do you think that Java has become so popular for big
> industrial applications, in contrast to Perl? If you look at job sites
> (e.g., dice.com) you can form an opinion as to which languages are
> being used for what. What does the industry use Java for, and what does
> it use Perl for? Some languages are better for some things, and other
> languages are better for other things. I totally agree with you about
> the terseness of Perl, but Java incorporates some things that appeal to
> the software sweatshops (or factories, if you prefer that term) like
> jar, javadoc, single inheritance, strict variable typing, different
> access modifiers, etc.
My oh my, weren't you the one who wasn't aware of POD? If you think that
"the industry" selects a language because it's well fitted for the tasks
at hand you are more then naive.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: Sun, 17 Sep 2006 06:06:48 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <slrnegppfo.or8.dha@panix2.panix.com>
On 2006-09-16, John Bokma <john@castleamber.com> wrote:
> "David H. Adler" <dha@panix.com> wrote:
>
>> On 2006-09-15, John Bokma <john@castleamber.com> wrote:
>>> Dan Stromberg <strombrg@dcs.nac.uci.edu> wrote:
>>>
>>>
>>>> book - is there something like that for perl? It might even come
>>>> under the name of a reference, perhaps.
>>>>
>>>> Is such a resource available?
>>>
>>> Programming Perl, 3rd edition. It's a tough read, but worth it and
>>> IMO matches exactly your description (been there, done that, only
>>> with the purple version).
>>
>> That's MAUVE, thank you very much. :-)
>
> http://www.answers.com/MAUVE
>
> It certainly doesn't match the colour from the Wikipedia article though
>:-)
>
> CC0099 (too "grey)/FF0099 (too pink) [1] comes closest but that's based
> on the memory I have of the book and the settings of my monitor :-D.
>
> BTW, not saying your wrong, but names of colors, and perception of
> colors is a hard thing :-) (I often describe colors as: a kind of
> purple, with some grey mixed into, and too much green, now that confuses
> people).
>
> http://www.oreilly.com/catalog/wdnut/excerpt/web_palette.html
My fingers played a trick on me. I meant "magenta". And before you tell
me *that*'s wrong too, my memory is that O'Reilly tended to
differentiate between the first two editions of the Camel/Llama by
referring to them as "magenta" and "teal".
I will, however, steadfastly maintain that the original editions were
NOT purple. :-)
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
Honk if you love Perl! (or strawberries!) - Larry Wall
------------------------------
Date: 17 Sep 2006 02:22:01 -0700
From: cartercc@gmail.com
Subject: Re: Learning perl - for experienced programmers
Message-Id: <1158484921.286049.257540@d34g2000cwd.googlegroups.com>
John Bokma wrote:
> My oh my, weren't you the one who wasn't aware of POD? If you think that
> "the industry" selects a language because it's well fitted for the tasks
> at hand you are more then naive.
John, I don't want this to sound ugly. I had decided to ignore your
remark. I formed the conclusion that you had no idea what you were
talking about. Please let me explain myself, and then maybe you will
understand what I am talking about.
Many times, software and software products have what is called an
application programming interface, or API. The API constitutes the
public interface of the language or application. 'Interface' consists
of the properties and methods of the product, that is, the public and
private members of the product, the public and private methods of the
interface, the different kinds of constructors, detailed information
including since, deprecated, version, return values, parameters, and so
on. This is what is known as external documentation. For the Java API,
see http://java.sun.com/reference/api/.
There is also what is called internal documentation. Internal
documentation consists of the programmer written comments embedded with
within the source code, or contained in separate text or README files
included with the application. Both external and internal documentation
are important, because they serve different purposes. The overall
purpose is the same, to document the code, but an API is more specific
and standardized than POD.
The javadoc utility produces a Java API of your code. You can write an
application, run javadoc, and WITHOUT ANY FURTHER EFFORT ON THE
PROGRAMMER'S PART have a full API of your application. POD is an HTML
type of utility which, by contrast with javadoc, requires the
programmer to document his code. As an example, with a Perl module, the
programmer typically would have his lexical variables at the top of the
script, the dispatch logic next, and his user defined subs at the
bottom. The programmer, in order to use POD, would have to separately
document each variable and each sub. By contrast, in a Java pacakge,
the utility produces documentation which describes each variable, its
access and type, each method, its type and return value, the
constructors of the instantiable classes, and so on.
I am very well aware of the Perl criticisms of a compiled, strongly
typed language like Java, or C, or C++, and you don't have to lecture
me about these differences. My point is that Java and Perl are
different languages, with different advantages and weaknesses. In some
ways, Perl is superior to Java, and in other ways, Java is superior to
Perl. One of the advantages to Java is the utility to automatically
generate an API with no effort on the programmer's part. Yes, I know
that the programmer is required to declare the type of the variable or
reference, and the type and return values of each method, can only
return one value from a method, and so on. I'm not going to takes sides
in this debate. I think the effort is similar, Java requires it up
front while Perl leaves the programmer free to neglect it if he
chooses.
"The industry" selects, usually, the best tools at hand for any
particular job. "The industry" is not a monolithic structure, but the
sum of all the parts. I am part of the industry, you are part of the
industry, we all are part, just like we are all part of "the economy."
Just as you can look at all the individual transactions and talk about
"the economy" or "the market" you can look at all the software
architects, engineers, and programmers, and make statements about "the
industry."
I live in an area where there are a lot of technology jobs in banking
and insurance. Many of these use COBOL. The schools, colleges, and
universities in my area still churn out COBOL programmers. I know COBOL
programmers, and even though I don't know COBOL, I understand why 'the
industry' uses COBOL -- it's the best tool for the job at hand. Not
Java, and not Perl.
I hope I didn't insult you by this explanation. If you don't know about
APIs, you might want to investigate. One last thing -- Java has tools
that let you draw UML diagrams, such as class diagrams, and generate
code. I teach OO programming in Java at a local university (hence my
verbosity) and I see a lot of harm in using these kinds of tools in
learning a language. I see a lot of managers who have been taught OO
development, but don't have the programming background to understand
the nuts and bolts. HOWEVER, these kinds of foward engineering tools
(as in Rational Rose or Eclipse, for example) can be great timesavers
for the journeyman programmer. With Perl, I think this kind of tool
would be impossible, because of the free from nature of the language. I
don't see this as either a detriment or an advantage, but simply an
aspect of the tool which makes it better or worse for some particular
job.
Best, Charles Carter.
------------------------------
Date: 17 Sep 2006 09:55:39 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Learning perl - for experienced programmers
Message-Id: <4n4kcrF8ovhaU1@news.dfncis.de>
<cartercc@gmail.com> wrote in comp.lang.perl.misc:
[big snip, just picking one paragraph]
> I live in an area where there are a lot of technology jobs in banking
> and insurance. Many of these use COBOL. The schools, colleges, and
> universities in my area still churn out COBOL programmers. I know COBOL
> programmers, and even though I don't know COBOL, I understand why 'the
> industry' uses COBOL -- it's the best tool for the job at hand. Not
> Java, and not Perl.
No, COBOL is the best tool for no job on earth except for maintaining
COBOL programs.
For many years, COBOL was the *only* tool for certain IO-heavy and
table-oriented tasks that come up in financial and administrative
computing. At least it was the only COmmon Business Oriented
Language and claimed to be specially fit for these purposes. People
believed it and developed large code bases in COBOL. In reality,
the FORTRAN of the day would have worked as well, if not better.
Now people are stuck with it. The language offers nothing that modern
languages don't implement in much more convenient ways.
For similar reasons the scientific community is largely still using
and maintaining FORTRAN, not because anyone believes it is the *best*
language but because for a long time it was *the* language.
Anno
------------------------------
Date: Sun, 17 Sep 2006 13:32:23 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <slrnegqci7.jqi.hjp-usenet2@yoyo.hjp.at>
On 2006-09-17 09:22, cartercc@gmail.com <cartercc@gmail.com> wrote:
> Many times, software and software products have what is called an
> application programming interface, or API. The API constitutes the
> public interface of the language or application. 'Interface' consists
> of the properties and methods of the product, that is, the public and
> private members of the product, the public and private methods of the
> interface, the different kinds of constructors, detailed information
> including since, deprecated, version, return values, parameters, and so
> on.
Correct so far.
> This is what is known as external documentation.
Not to anyone I've ever talked to. The documentation is a description of
the API, not the API itself. The method "boolean delete()" of the class
java.io.File is part of of the J2SE core API. The text "boolean
delete(): Deletes the file or directory denoted by this abstract
pathname." is not part of the API, it is part of the description (or, in
this case, specification) of the API. You can change the description
without changing the API (or vice versa).
> For the Java API, see http://java.sun.com/reference/api/.
You will notice that it says "This document is the API specification of
..." not "This document is the API of ..."
> There is also what is called internal documentation. Internal
> documentation consists of the programmer written comments embedded with
> within the source code, or contained in separate text or README files
> included with the application. Both external and internal documentation
> are important, because they serve different purposes. The overall
> purpose is the same, to document the code, but an API is more specific
> and standardized than POD.
>
> The javadoc utility produces a Java API of your code. You can write an
> application, run javadoc, and WITHOUT ANY FURTHER EFFORT ON THE
> PROGRAMMER'S PART have a full API of your application.
I have an API by coding it. What Javadoc does - and this is very useful
- is creating a framework of documentation from the source code, by
simply listing all the fields and methods of the class.
> POD is an HTML type of utility which, by contrast with javadoc,
> requires the programmer to document his code.
I strongly debate that Javadoc doesn't require the programmer to
document his code. It can extract some interesting facts about the API
from the source code (such as parameters and return type of methods or
the super class of a class), but that's not much more than you can get
with grep. The most interesting questions ("what does it do?" and "why
does it do that?") have to be documented by the programmer.
What Javadoc does very well (and pod doesn't do at all) is that it makes
it glaringly obvious if the programmer neglected to document something.
There's a big empty rectangle in his manager's browser, and the manager
will say to the programmer "Fill this rectangle, or you will be fired."
> "The industry" selects, usually, the best tools at hand for any
> particular job.
I don't believe this. "The industry" seldom selects the best tools. It
selects tools which are good enough and require little change.
As to why Java was widely accepted, I don't think it was because it was
the best tool for any particular job. I believe some of the reasons
were:
* It was touted as a simpler version of C++. C++ was already used a lot,
so that was little change.
* It promised platform independence.
* Applets were seen as possibility to distribute feature-rich
applications to users over the web.
* There was a big player (Sun) behind it. A respectable company, not
some long-haired academic.
* It's a statically typed language. Statically typed languages are seen
as more professional than dynamically typed languages. In any case,
"the industry" is used to them (COBOL, FORTRAN, Pascal, C, C++, ...)
* It has separate compiler/interpreter stages: You can deliver some
binary ".class" files to your customers and don't have to show them
the source code. Just like you delivered binary executables and
libraries from your C programs.
hp
--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
------------------------------
Date: Sun, 17 Sep 2006 04:42:09 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Sun Sep 17 2006
Message-Id: <J5pzq9.1J1@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
ASNMTAP-3.000.011
http://search.cpan.org/~asnmtap/ASNMTAP-3.000.011/
----
Bio-Phylo-0.15
http://search.cpan.org/~rvosa/Bio-Phylo-0.15/
Phylogenetic analysis using perl.
----
Business-USPS-WebTools-0.10_01
http://search.cpan.org/~bdfoy/Business-USPS-WebTools-0.10_01/
This is the description
----
CGI-Application-Plugin-QueryHash-1.01
http://search.cpan.org/~gtermars/CGI-Application-Plugin-QueryHash-1.01/
Get back query params as hash(ref)
----
CPAN-1.87_64
http://search.cpan.org/~andk/CPAN-1.87_64/
query, download and build perl modules from CPAN sites
----
Catalyst-Plugin-LogWarnings-0.02
http://search.cpan.org/~jrockway/Catalyst-Plugin-LogWarnings-0.02/
Log perl warnings to your Catalyst log object
----
Catalyst-Plugin-Session-Store-DBIC-0.06
http://search.cpan.org/~danieltwc/Catalyst-Plugin-Session-Store-DBIC-0.06/
Store your sessions via DBIx::Class
----
Crypt-Lite-0.82.07
http://search.cpan.org/~retoh/Crypt-Lite-0.82.07/
Easy to use symmetric data encryption and decryption
----
Crypt-Lite-0.82.08
http://search.cpan.org/~retoh/Crypt-Lite-0.82.08/
Easy to use symmetric data encryption and decryption
----
Data-ICal-0.08
http://search.cpan.org/~jesse/Data-ICal-0.08/
Generates iCalendar (RFC 2445) calendar files
----
Dunce-0.03
http://search.cpan.org/~mschwern/Dunce-0.03/
----
ExtUtils-ParseXS-2.16
http://search.cpan.org/~kwilliams/ExtUtils-ParseXS-2.16/
converts Perl XS code into C code
----
File-Next-OO-0.01_04
http://search.cpan.org/~borisz/File-Next-OO-0.01_04/
File-finding iterator Wrapper for File::Next::files function
----
File-Wildcard-0.09
http://search.cpan.org/~ivorw/File-Wildcard-0.09/
Enhanced glob processing
----
Geo-CountryFlags-1.00
http://search.cpan.org/~miker/Geo-CountryFlags-1.00/
dynamically fetch flag gif's from CIA
----
HTML-KhatGallery-Plugin-SortNaturally-0.01
http://search.cpan.org/~rubykat/HTML-KhatGallery-Plugin-SortNaturally-0.01/
Plugin for khatgallery to use Natural sort for index lists.
----
Image-Compare-0.3
http://search.cpan.org/~avif/Image-Compare-0.3/
Compare two images in a variety of ways.
----
Net-Server-Mail-ESMTP-XFORWARD-0.01
http://search.cpan.org/~guimard/Net-Server-Mail-ESMTP-XFORWARD-0.01/
A module to add support to the XFORWARD command in Net::Server::Mail::ESMTP
----
POE-Component-IRC-5.03
http://search.cpan.org/~bingos/POE-Component-IRC-5.03/
a fully event-driven IRC client module.
----
POE-Session-YieldCC-0.200
http://search.cpan.org/~bsmith/POE-Session-YieldCC-0.200/
POE::Session extension for using continuations
----
Template-Plugin-Capture-0.01
http://search.cpan.org/~jiro/Template-Plugin-Capture-0.01/
TT Plugin to capture FILTER block
----
Text-NSP-1.03
http://search.cpan.org/~tpederse/Text-NSP-1.03/
The Ngram Statistic Package allows a user to count sequences of words in large corpora of text, and measure their association.
----
Tie-FTP-0.02
http://search.cpan.org/~ivorw/Tie-FTP-0.02/
A module to open files on FTP servers as filehandles
----
WWW-Facebook-API-REST-Client-v0.0.2
http://search.cpan.org/~unobe/WWW-Facebook-API-REST-Client-v0.0.2/
Facebook API implementation
----
WWW-Facebook-API-REST-Client-v0.0.3
http://search.cpan.org/~unobe/WWW-Facebook-API-REST-Client-v0.0.3/
Facebook API implementation
----
WWW-Gazetteer-HeavensAbove-0.16
http://search.cpan.org/~book/WWW-Gazetteer-HeavensAbove-0.16/
Find location of world towns and cities
----
WWW-Myspace-0.57
http://search.cpan.org/~grantg/WWW-Myspace-0.57/
Access MySpace.com profile information from Perl
----
classes-0.941
http://search.cpan.org/~rmuhle/classes-0.941/
conventional Perl 5 classes
----
khatgallery-0.02
http://search.cpan.org/~rubykat/khatgallery-0.02/
generate a HTML photo-gallery.
----
podlators-2.0.5
http://search.cpan.org/~rra/podlators-2.0.5/
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Sun, 17 Sep 2006 11:32:41 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Perl compiler
Message-Id: <450ca6c5$0$17214$afc38c87@news.optusnet.com.au>
"Bill H" <bill@ts1000.us> wrote in message
news:1158424157.465990.313280@h48g2000cwc.googlegroups.com...
> Can anyone recommend a good perl compiler for creating .exe files
> running under Dos?
>
The PAR module has a very good perl2exe utility called 'pp.bat'. There's
usually a windows ppm for it at the uwinnipeg repository (among other
places).
Cheers,
Rob
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9734
***************************************
