[6635] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 260 Volume: 8

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 9 16:17:16 1997

Date: Wed, 9 Apr 97 13:00:20 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 9 Apr 1997     Volume: 8 Number: 260

Today's topics:
     Re: ?? PERL execution on client using <SCRIPT .....> <\ <gordon.leslie.mcdorman@sap-ag.de>
     bdf <naama@cpm.elex.co.il>
     Re: dbm oddity (Paul Marquess)
     Re: HELP: Need a little help on using PerlV5.003 with a (James A. Robinson)
     Is there a length limitation on CGI Posts (STDIN)? (Peter Baker)
     Kudos to Tom Christiansen and problems with OO <lpa@sysdeco.no>
     Re: Ousterhout and Tcl lost the plot with latest paper (Adam Sah)
     Re: Ousterhout and Tcl lost the plot with latest paper <nospam.fellowsd@cs.man.ac.uk>
     Re: Radius, a perl for your thoughts <abrigham@mail.foxnet.net>
     Re: Re: Head of mail.... <pucko@lysator.liu.se>
     Re: Reply to Ousterhout's reply (was Re: Ousterhout and <graham.matthews@maths.anu.edu.au>
     Re: running a loop foreach $ARGV? (c.l.p.m.)
     splitting and reading data in an elm mailbox (Rachel Polanskis)
     Re: Substitution Question (Andreas Schmidt)
     timelocal strangeness and my obvious insanity... :) <dohmp@lci.com>
     Re: Unix and ease of use  (WAS: Who makes more ...) (Martin Sohnius x24031)
     Vendor Support for Perl5 on SGI justin.lodge@telecom.co.nz
     Re: Who makes more $$ - Windows vs. Unix programmers? (H.P.Heidinger)
     Re: Who makes more $$ - Windows vs. Unix programmers? (Kaz Kylheku)
     Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 9 Apr 1997 09:53:59 GMT
From: "Gordon McDorman" <gordon.leslie.mcdorman@sap-ag.de>
Subject: Re: ?? PERL execution on client using <SCRIPT .....> <\SCRIPT> tag. ??
Message-Id: <01bc44cb$fedeb7b0$0df4389b@p23874>

Rhadji P <dharma@msys.net> wrote in article <5idf5f$e3m@lois.zippo.com>...
> Is there an effort underway to gain perl client support via the HTML
> script tag (for fictitious example)?....
> 
> <SCRIPT type="text/perl">
>    print "<H1>Hello world...Again</H1>";
>     </SCRIPT>

See <http://www.activeware.com> ... look, for example under
"What's Perl" for a brief description of their implementation of
"PerlScript". It's an ActiveX scripting engine, functioning on
Internet Explorer for Windows.

-- 
-------------------------------------------------------------- 
The opinions expressed above are mine, not my employer's.
      
gordon.leslie.mcdorman@sap-ag.de                               



------------------------------

Date: Wed, 9 Apr 1997 06:29:10 GMT
From: SHILUV Naama Westreich 5810 <naama@cpm.elex.co.il>
Subject: bdf
Message-Id: <Pine.HPP.3.95.970409092647.28612E-100000@tlhuph11.elex.co.il>

hi!
Is there a command in perl, similar to "bdf" in unix, so i can find
disk capacity?

   naama


   




------------------------------

Date: 9 Apr 1997 08:32:39 GMT
From: pmarquess@bfsec.bt.co.uk (Paul Marquess)
Subject: Re: dbm oddity
Message-Id: <5ifk77$odh@pheidippides.axion.bt.co.uk>

[ Posted & Mailed ]

David A. Enete (denete@coe.uga.edu) wrote:
: Hi all.  I've just started using dbm files, and have run into a big snag.
: I'm using dbm files to store the listing of a directory for use in another
: script, and can't seem to get the hash that is returned make sense.

: This is the fragment used alone (its own script) to create the dbm file.

: #################
: # BEGIN FRAGMENT

: $unitdir = '/full/path/to/directory/to/be/indexed/';
: $db_out_file = '/name/of/file/for/dbm';

: opendir DIRUNITS, "$unitdir" || die;
: @allunits = readdir DIRUNITS;
: closedir DIRUNITS;

: dbmopen(%UNITS, "$db_out_file", 0666)
:     || die "\nCan't open the file\n$db_out_file\n";
: for(@allunits) {
:     next if(/^\D/); # I just want files that begin with digits
:     push @{ $UNITS{(unpack("A2", $_))} }, "$_";
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This line is wrong. Try this instead:

      $UNITS{(unpack("A2", $_))} = "$_";

: }
: dbmclose %UNITS;

Paul


------------------------------

Date: 9 Apr 1997 10:33:14 -0700
From: jimr@aubrey.stanford.edu (James A. Robinson)
Subject: Re: HELP: Need a little help on using PerlV5.003 with a Sybase stored procedure
Message-Id: <5igjsq$j0@aubrey.stanford.edu>

In article <33395393.C70@FMR.com>, Alex Sokol  <Alex.Sokol@FMR.com> wrote:
>Hi,
>	i'm trying to call a Sybase stored procedure which
>	makes a select and returns a value in the output 
>	argument.
>
>	Here is what i have:
>
>	Stored procedure:
>		 pr_get_busday @cur_bus_day output
>
>	Perl script:
>		-- I'm using CTlib --
>		my(@cur_bus_day);
>		$sql_cmd = "exec pr_get_busday @cur_bus_day output";
>		$dbh->ct_sql($sql_cmd);
>		print "Cur_bus_day: @cur_bus_day\n";
>		-- cur_bus_day appears to be null --
>		-- next_row loop also got me nothing --

What I do is the following:

use Sybase::DBlib;
 ...
my $db = new Sybase::DBlib($user, $passphrase, $server);
$db->dbuse($database) if $db;

    # Do a select.
    my $cmd = <<"go";
select row1, row2 from table1
go

@rows = $dbsa->sql($cmd);

if (scalar(@rows) <= 0) {
	print("Database returned nothing\n");
}

foreach $i (0..$#rows) {
	print("$rows[$i][0]\n",		# print row1
	      "$rows[$i][1]\n");	# print row2
}


Good luck!

Jim
-- 
Jim Robinson <jim.robinson@stanford.edu> - http://highwire.stanford.edu/~jimr/
HighWire Press -- Stanford University


------------------------------

Date: Wed, 9 Apr 1997 10:32:08 -0700
From: pbaker@nwcs.net (Peter Baker)
Subject: Is there a length limitation on CGI Posts (STDIN)?
Message-Id: <MPG.db572752a9850be989691@area1.news.internex.net>

I have UnixWare 2.1 running Apache 1.2b7.  

On this I am running a script that when sent post the complete form consist of about 2k worth 
of data.

The script is handled via perl 5.002 and CGI.pm.  When it runs on the command line and CGI.pm 
is piped the form results all is ok.  Now when I run this off the server, the perl script 
dumps core and there is no error in the logs.

I am wondering if this is a problem with CGI.pm, STDIN or what?!

Any ideas out there?

-Peter


------------------------------

Date: Wed, 09 Apr 1997 12:29:55 +0200
From: Luca Passani <lpa@sysdeco.no>
Subject: Kudos to Tom Christiansen and problems with OO
Message-Id: <334B6FA3.59F1@sysdeco.no>

Hallo,

 a couple of days ago, I posted a question about a problem I was having
with Perl 5 Object Oriented features (which I'm trying to learn).
 Tom was the only one who cared to answer, even though many here could
have taken a moment to take a look at my original question and given the
answer. That is why I would like to thank him publicly. 
 I post the answer since I think it will be useful for someone in the
future.

keywords: perl, object-oriented, @ISA, strict, explicit package

My original problem was understanding why this simple packages did not
compile:

### perl -c Component.pm
Component.pm syntax OK
### perl -c Block.pm    
Global symbol "ISA" requires explicit package name at Block.pm line 5.
Block.pm had compilation errors.


Where  Block.pm
___________________________________________________
package Block;
use strict;

use Component;
@ISA = qw("Component");

=head1 NAME

Block - bla
____________________________________________________

The answer was actually very simple:

if you use strict.pm, you are supposed to explicitly declare which
global variable you will be using. This also holds for @ISA:

   use vars qw(@ISA);

This problem, even though simple for gurus, can result deadly for
newbie. Didn't such a question deserve an answer on the newsgroup?
Is there anything like "idiot guide to perl5"?

Luca

-- 
Luca Passani.          | Sysdeco  AS, http://www.sysdeco.no
Email: lpa@sysdeco.no  | Trondheimsveien 184, 0570 Oslo, Norway


------------------------------

Date: 06 Apr 1997 06:21:18 -0700
From: asah@CS.Berkeley.EDU (Adam Sah)
To: ouster@tcl.eng.sun.com (John Ousterhout)
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <up0u3lk8eyz.fsf@ginsberg.CS.Berkeley.EDU>

Dear John,

   I just finishing reading the scripting paper -- it's *really* good, imho.
   I especially liked the app examples and the decision questions -- they're
   dead on!

   The USENET rebuttal definitely adds a lot.  I also noticed a few things
   that would be nice for draft 2:

 - It would be nice to more rigorously define "typeless", "weakly
   vs. strongly typed", "statically vs. dynamically typed" and "string
   oriented".  It should be easy enough to do, and it'll shut up a lot of
   the whining.

 - regexps in Perl, traces in Tcl, etc. are all examples of advanced language
   features.  In this vein, Java provides garbage collection, exceptions,
   objects, safety, convenient concurrency primitives, etc.  I think it's
   pretty hard to (objectively) toss Java into the "systems language" camp,
   at least without more rigorous definitions.  A really useful chart would
   be one that said what kinds of features are found in scripting languages.
   For example, portability of scripts is probably very important.

 - imho, a killer example of why you need dynamic code generation is "send".
   Other things (ie. widget bindings) can be done with closures, as evidenced
   by the various Scheme<-->Tk bindings.  Closures can be easier to use than
   string eval's because they avoid quoting hell.

 - minor nit: Visual Basic is strongly typed and is probably not
   "string-oriented" (depending on your definition).  You have to declare the
   types of all variables.  Sure, it has a Dynamic data type, but so do
   many ML implementations -- and you wouldn't call them dynamically typed.
   Not sure if this hurts the argument.

 - minor nit: "I am not aware of any RAD environments for GUIs based on
   system programming languages." -- actually, Microsoft's Visual C and C++,
   Borland's Turbo C and Pascal, and Symantec's Visual Cafe are all examples
   of RADs for GUIs.  I still agree with the basic argument, however.

adam
                     | Mariposa Database Res. Group   | Technical Director
Adam Sah             | 419 Soda Hall                  | Inktomi Corp.
asah@cs.Berkeley.EDU | UC Berkeley Dept of Comp. Sci. | http://www.inktomi.com
510-642-8072         | Berkeley, CA  94720-1776       | asah@inktomi.com

 ..tear.along.dotted.line......................................................

In article <5i7euq$cmg@engnews2.Eng.Sun.COM> ouster@tcl.eng.sun.com (John Ousterhout) writes:

   From: ouster@tcl.eng.sun.com (John Ousterhout)
   Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
   Date: 6 Apr 1997 06:13:46 GMT
   Organization: Sun Microsystems, Inc.
   Path: agate!newsfeed.kornet.nm.kr!howland.erols.net!cam-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!venus.sun.com!news2me.EBay.Sun.COM!engnews2.Eng.Sun.COM!tcl!ouster
   Lines: 261
   Sender: ouster@tcl (John Ousterhout)
   Distribution: world
   References: <rcybba5k9c.fsf@redwood.skiles.gatech.edu> <199703271612.LAA06438@menhaden.adi.com> <s6y208um0ey.fsf_-_@aalh02.alcatel.com.au> <334412fb.7359993@news.demon.co.uk>
   NNTP-Posting-Host: tcl.eng.sun.com
   Xref: agate comp.lang.scheme:19397 comp.lang.scheme.scsh:474 comp.lang.lisp:26449 comp.lang.tcl:66129 comp.lang.functional:8719 comp.lang.c++:259329 comp.lang.perl.misc:72693 comp.lang.python:20580 comp.lang.eiffel:19437

   Wow, there's been quite a party going on over here on comp.lang.scheme!
   I'd like to respond to a few of the comments about my white paper on
   scripting, but first a couple of introductory remarks:

   1. The paper is not intended to be a complete taxonomy of all programming
	  languages nor is it intended to discuss every factor that contributes
	  to the usefulness of a language.  The paper has a very narrow focus,
	  namely to explain what scripting is and why it's important.  I
	  intentionally limited the discussion to a few issues such as system
	  programming vs. scripting, components vs. glue, and strongly typed
	  vs. untyped.  Of course there are other issues in programming language
	  design.  At the same time, I think that the issues in the paper explain
	  a lot about what's going on in real-world programming.

   2. Many people objected to the fact that their favorite programming
	  was left out of the white paper.  Yes, I have heard of Scheme,
	  Smalltalk, ML, etc.  I left these languages out because they
	  didn't seem particularly relevant for the discussion.  No offense
	  intended...

   3. It's very hard to settle arguments about programming languages
	  because it's hard to produce meaningful quantitative evidence about
	  things like programmer productivity.  I tried to illustrate my points
	  with historical examples and a few quantitative anecdotes, but I
	  admit that these are soft.  I'd be delighted to see better
	  quantitative evidence either supporting or contradicting my
	  arguments.  For example, if you know of any quantitative measurements
	  of productivity improvements caused by object-oriented programming,
	  please let me know.

   When Alaric Williams told me about the flame-fest on comp.lang.scheme,
   he proposed a set of counter-arguments for me to respond to.  Here
   they are, along with my responses.

		- Typlessness, as evident in TCL, is not necessarily the best solution.
	   Dynamic typing is generally agreed to be far more powerful and safe.

   Actually, I think Tcl is dynamically typed: everything is checked
   at runtime for at least syntactic validity.  I used a slightly offbeat
   definition of "typing" in the paper: by my definition, "typing" means
   declaring the nature of something in advance in order to restrict its
   usage.  You would probably call this "static typing", no?

		- TCL does not scale well to large systems; it is fine for small
	   "glueing" applications, but in the "real world", such applications
	   are expected to grow with time, and soon proper typing becomes
	   necessary, more efficiency becomes necessary, etc.

   When I started on Tcl I thought this would be true, but in fact many
   people have built surprisingly large programs in Tcl.  For example,
   there is a real-time Tcl application containing several hundred thousand
   lines of code that controls a $5 billion oil well platform and (much to
   my shock) it seems to be quite maintainable.  Sybase has something like
   a million lines of Tcl code in their test suite.

   I think it depends a lot on the application.  The oil well application
   actually subdivides into a whole bunch of small tasks, so it's really
   more like 500 smaller programs.  Also, if the application is
   fundamentally gluing (i.e. the complexity is in the interconnections)
   then switching to a more strongly typed language will just make things
   worse.  One final argument: suppose that Tcl code is harder to maintain,
   line for line, than code in a more strongly typed language (I suspect
   this is true).  But if a Tcl application has only 1/5 or 1/10 the lines
   of code of the equivalent program in a strongly typed language, it may
   still be easier to maintain overall.

   That said, I still suspect that as scripting applications grow it makes
   more and more sense to implement parts of them in a system programming
   language.  The great thing about scripting languages is that this is
   easy to do.  You can take the performance-critical kernel of a Tcl
   application and implement it in C or C++; ditto for any complicated data
   structures or algorithms.  The simple, non-performance-critical parts
   can be left in Tcl.  I knew when I started on Tcl that it wouldn't be
   appropriate for all problems, so I designed it to work smoothly with
   other languages.  In contrast, most languages are egotistical: they
   expect you to do *everything* in that language and make it very hard to
   split the functionality of an application between multiple languages.
   For example, I've been involved with several attempts to make C and Lisp
   work together, and they all failed.

		- It is possible to make languages with execution speeds like C or C++,
	   that use dynamic typing successfully, whilst being high-level enough
	   in the creation of abstractions to "glue" things together quite
	   nicely and easily.

   Can you point to a specific language and identify a large community of
   users who agree with this assessment?   Many people have made claims like
   this to me, but no one has been able to point to a good real-world
   example.  The white paper argues that you can't have a jack-of-all-trades
   language.  Either you have a strongly typed language, which gives high
   speed and manageability but makes gluing hard, or you have a weakly
   typed language with the opposite properties.

		- Do you really think that object orientation has failed? C++ is a bad
	   OO
	   language, indeed, but what about Self, Java, and other such OO success
	   stories from... Sun Labs? Do I detect interdepartmental rivalry?

   I overstated the arguments against OO programming in the paper and I'll
   probably soften them a bit in the next draft.  I actually think that
   there are some good aspects of OO programming, and I use them myself
   even when I'm not programming in an OO language.  But I stand by the two
   main points in the paper, which are that (a) OO programming hasn't
   increased productivity dramatically because it doesn't raise the level of
   programming significantly (it may improve things 20-30%, but I doubt
   there's even a factor of 2, let alone 10) and (b) implementation
   inheritance really truly is a bad idea that tends to reduce reuse and
   productivity.  I think you'll see substantial support for the second
   claim even among OO enthusiasts.

   As for Java, it's hard not to be envious of its success (aren't you
   guys a bit envious too?), but Tcl is really symbiotic with Java, just
   as Tcl is symbiotic with C.  I look on Java as a better system
   programming language that's particularly well-suited for creating
   portable Internet components.  Tcl is moving to the Internet itself,
   and C isn't a good component language in that domain, so I'm delighted
   to have Java around for implementing Internet components that Tcl
   can then glue together.

   By the time I found out about the discussion on comp.lang.scheme my news
   server had already flushed some of the earlier articles, so I've missed
   some of the arguments.  I trolled the articles that were left for
   comments to discuss, but didn't find a lot.  Most of the articles seemed
   to be discussing my motives and ancestors more than the ideas in the
   paper;  I'm not sure how to respond to a comment such as "he obviously
   doesn't have a clue" except by saying "Hmmm, let me see... wait ...
   here's one in my wallet!  Whew..."  You guys seem to have more
   ad-hominem arguments than we do on comp.lang.tcl.

   However, I did find a few comments that I'd like to respond to; here
   they are (indented), along with my responses:

	   > I have only skimmed the article so far, but one thing struck me
	   > immediately.  At one point he gives an "anecdotal" table where
	   > something is programmed originally in C or C++, at enormous expense
	   > in programmer hours, and then re-implemented in Tcl/Perl/whatever
	   > in ten or fifteen minutes. It would be interesting to see if the
	   > same skew existed for programs that were written in scripting
	   > languages (or for that matter, Lisp or Scheme or Python) first,
	   > and then re-implemented in C or C++. It's hard to believe the ratios
	   > would be as large.

   Look carefully at the "Comments" column in the table: some of the
   applications were written in C/C++ first, while others were written in
   Tcl/Perl first.  Indeed, scripting appears to have less benefit in the
   cases where the scripting implementation was first.  I believe the
   caption in the table mentions this, and the 5-10x advantage I claimed
   for scripting is the middle range of the table to try to compensate
   for learning effects in the second implementation.

	   His arguments on "typeless" languages is useless.
	   You don't need a "scripting language" to
	   get usable abstractions without the need
	   to deal with low-level issues.

	   button .b -text Hello! -font {Times 16} -command {puts hello}

	   In Macintosh Common Lisp I'll write this as:

	   (make-instance 'button-dialog-item
		 :dialog-item-text "Hello"
		 :view-font '("Times" 16)
		 :dialog-item-action (lambda (item) (print "hello")))

   I think this example supports my claim that scripting languages are a
   lot easier to use when you need to mix and match lots of things of
   different types.  The MCL example is a lot more verbose and complicated
   than the Tcl example.

	   He also gets confused when he talks about object oriented programming
	   being a failure. He attributes the short comings of one implementation
	   (C++) to the whole approach, much like people who reject Lisp/Scheme
	   because of one particular implementation.

   Time will tell on this issue.  Personally I think that the problems with
   OO programming go beyond just C++.

	   >The button example requires about 25 lines of code in three procedures
	   >when implemented in C++ with Microsoft Foundation Classes. Just
	   >setting the font requires 7 lines of code:
	   >
	   >LOGFONT lf;
	   >
	   >memset(&lf, 0, sizeof(lf));
	   >
	   >lf.lfHeight = -16;
	   >
	   >strcpy(lf.lfFaceName, "Times New Roman");
	   >
	   >CFont *fontPtr = new CFont();
	   >
	   >fontPtr->CreateFontIndirect(&lf);
	   >
	   >buttonPtr->SetFont(fontPtr);

	   Come on! All this shows is the inconveniece of using the MFC
	   classes. An interface exactly the same as the Tcl one could easily be
	   written in C++.

   I invite anyone who believes this to try to do it, and post the results.
   I've had this argument before, and when people do this, one of two things
   happens: either they eventually concede that this is hard to do in C++, or
   they define new C++ APIs that are essentially untyped (e.g. they use
   strings for everything).  This just supports my arguments that types get
   in the way of gluing.  You can build untyped APIs in strongly typed
   languages, but they tend to be clumsy because the languages are designed
   to encourage strong typing.  If you need an untyped approach, you might
   as well use a language designed for that.

	   > >The button example requires about 25 lines of code in three procedures
	   > >when implemented in C++ with Microsoft Foundation Classes. Just
	   > >setting the font requires 7 lines of code:
	   > >
	   > >LOGFONT lf;
	   > >
	   > >memset(&lf, 0, sizeof(lf));
	   > >
	   > >lf.lfHeight = -16;
	   > >
	   > >strcpy(lf.lfFaceName, "Times New Roman");
	   > >
	   > >CFont *fontPtr = new CFont();
	   > >
	   > >fontPtr->CreateFontIndirect(&lf);
	   > >
	   > >buttonPtr->SetFont(fontPtr);


	   CButton* button1;
	   CButton* button2;
	   button1 = new CButton();
	   button1->Create("Push me", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
	   101)
	   button2 = new CButton();
	   button2->Create("Pull you", WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON, r, this,
	   102)
	   font = new CFont;
	   font->CreateFont(16,0,0,0,700,0,0,0,ANSI_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,
		   DEFAULT_QUALITY,DEFAULT_PITCH|FF_DONTCARE,"times");
	   button1->SetFont(font)
	   button2->SetFont(font)

	   Basically 3 lines to create a font (reusable assuming you only 
	   what a few types of fonts, set up a function to handle size changes
	   if it's the same, you can also create a simple function to handle
	   defaults for everything but the size and type.

	   3 lines to create a Button.

	   I don't know where Oesterhout's reference on MFC comes from
	   (I'm just looking at Brain & Lovette's book).

   I'm not an MFC expert, so I asked someone else, whom I consider to be
   a good Windows programmer, to write this for me.  Perhaps there is a
   shorter way than the code I included.  However, the 6 lines above
   don't seem to be equivalent to the Tcl script.  For example, there is
   no code to respond to the button press, and I believe additional code is
   needed to free resources when the button is deleted.  Suppose that the
   MFC code I used is off by a factor of two, and that it really only takes
   12 lines of C++ to duplicate the functionality of one line of Tcl.  Doesn't
   that still illustrate my point?
-- 
Thanks again,
Adam Sah             | Mariposa Database Research Group
                     | 419 Soda Hall
asah@cs.Berkeley.EDU | UC Berkeley Dept of Computer Science
510-642-8072         | Berkeley, CA  94720-1776


------------------------------

Date: 9 Apr 1997 10:39:38 GMT
From: Donal K. Fellows <nospam.fellowsd@cs.man.ac.uk>
Subject: Re: Ousterhout and Tcl lost the plot with latest paper
Message-Id: <5ifrla$op6@m1.cs.man.ac.uk>

In article <87d8s8jqck.fsf@A-abe.resnet.ucsb.edu>,
Graham C. Hughes <graham.hughes@resnet.ucsb.edu> wrote:
> Donald Syme <drs1004@cl.cam.ac.uk> writes:
>> Trash.  Show me C++ which is as succinct and I may believe
>> you.
> 
> How much do you want?  I've found that STL makes my code incredibly
> brief, and with the correct toolkit (I like Qt), windowing isn't that
> hard, either.  Better, you can subclass existing components so you can
> create a new widget, something you can't do in Tcl/Tk without
> resorting to C extensions.

What exactly do you mean by "subclassing"?  How can you be sure that
you need a C extension to do it with Tcl/Tk?  I have made Tcl/Tk-only
labelled frames, comboboxes and progress meters quite easily, so it is
entirely possible that you are simply mistaken in your assertion.

> This is an aside, however; the real issue is that Tcl/Tk is a
> glorified macro processor, full of weird tricks.  Try explaining why
> you can't pass an array, or why 'set $$foo bar' doesn't work some
> time.  *This* is the reason why Tcl/Tk is ``concise''; everything is a
> string.  Where else can we find:
> 
> 	- lists where accessing anything is an O(n) operation

What version are you talking about?  This (a long-standing complaint
of many Tcl entheusiasts) is no longer true in Tcl8.

> 	- numbers that autoconvert when you don't want them to (on
> 		east coast area codes, for example)

I believe this (another moan of great age) is fixed too.

> 	- non-extensible mathematical expressions (think expr here)

Fair enough, though I'd add that putting in your own stuff (which does
admittedly have a different syntax) is still not hard.

> 	- call by name
> 	- dynamic scoping

These two are construable as a feature (though I would like the other
kind of semantics AS WELL... :^)

> and other assorted nastiness.  Even Perl is a breath of fresh air
> compared to this.

For some things.

> I have nothing but good things to say about Tk.  Its incarnation in
> other languages like Scheme, Python, Perl, and O'Caml are very nice,
> and in the correct language (I know Python does this, not sure about
> the others) you can even subclass widgets.  Tcl, however, is something
> else entirely, and I reject it for anything except trivial programs
> out of hand.

I suppose it all depends on your definition of trivial, but there are
commercial applications out there written in Tcl/Tk with over a
million lines of code.  I do admit that systems of that size (whatever
written it) boggle my mind a bit though... :^)

Donal.
--
Donal K. Fellows   http://r8h.cs.man.ac.uk:8000/  (SAY NO TO COMMERCIAL SPAMS!)
(work) fellowsd@cs.man.ac.uk     Dept. Comp. Sci, Univ. Manchester, U.K.
 |     donal@ugglan.demon.co.uk  6,Randall Place, Heaton, Bradford, U.K. (home)
 +-> ++44-161-275-6137  Send correspondence to my office  ++44-1274-401017 <-+


------------------------------

Date: Wed, 09 Apr 1997 01:30:23 -0400
From: Andrew Brigham <abrigham@mail.foxnet.net>
Subject: Re: Radius, a perl for your thoughts
Message-Id: <334B296F.7072@mail.foxnet.net>

In response... below you see a sample of the output created by radius...

This is the Start Paragraph... nothing very usefull

Sat Mar 22 09:34:38 1997
        User-Name = "rward"
        Service-Type = Framed
        Framed-Protocol = PPP
        NAS-IP-Address = "204.138.179.1"
        NAS-Port = 9
        Acct-Status-Type = Start
        Acct-Session-Id = "40000304"
        Acct-Authentic = RADIUS
        User-Id = "rward"
        NAS-Identifier = "tbcentral.foxnet.net"


This is the Stop paragraph.... lots of usefull stuff...
I want to get the  username and the  Acct-Session-Time...

Sat Mar 22 09:43:39 1997
        User-Name = "rward"
        Service-Type = Framed
        Framed-Protocol = PPP
        NAS-IP-Address = "204.138.179.1"
        NAS-Port = 9
        Acct-Status-Type = Stop
        Acct-Session-Id = "40000304"
        Acct-Input-Octets = 1065
        Acct-Output-Octets = 1332
        Acct-Input-Packets = 21
        Acct-Output-Packets = 19
        Acct-Session-Time = 542
        Acct-Authentic = RADIUS
        User-Id = "rward"
        NAS-Identifier = "tbcentral.foxnet.net"

The basic jist of my script is listed below.... however it outputs total
time online over the course of the log...
I want
Username,Month, Day,TotalTimeOnline for user for day,NumberOfLogins for
day
something like this
Username

User 		Date          Time On     Logins
janderson	Mar 14        128434       5
abrigham	Mar 15        65643        2
janderson	Mar 15        43874        2
	

$/ = '';             

while (<FILE>) {
        next if /Acct-Session-Id = "00000000"/;
        if (/Acct-Status-Type = Stop/) {
                if (/Acct-Session-Id = "([^"]+)"/) {
                        $id = $1;
                        if (/NAS-IP-Address = (\S+)/ ||
                            /Client-Id = (\S+)/) {
                                $nas = $1;
                                $id .= '@'.$nas;
                                if ($seen{$id}++) {
                                        $dup++;
                                        next;
                                }
                        }
                } else {
                        $err{'No ID'}++;
                        next;
                }


#       Get the Username and elapsed time (in seconds) and add 1 for
logins

                if (/User-Name = "([^"]+)"/) {
                        $user = $1;
                        if (/Acct-Session-Time = (\d+)/) {
                                $elapsed = $1;
                                if ($elapsed > 0) {
                                        $uses{$user}++;
                                        $used{$user} += $elapsed;
                                }
                        }
                }
            
        }
}

print "# $dup duplicates\n" if $dup;
print "# $err{'No ID'} stop records without Acct-Session-ID\n" if
$err{'No Id'};

# print usage by user
foreach $user (keys %used) {


        printf
DATA"%s;%s;%s\n",$user,&hms($used{$user}),$uses{$user};
}


__________________________________
Andrew Brigham

abrigham@foxnet.net


------------------------------

Date: Wed, 09 Apr 1997 20:22:11 +0200
From: Magnus Holmberg <pucko@lysator.liu.se>
Subject: Re: Re: Head of mail....
Message-Id: <334BDE53.46AF@lysator.liu.se>

Douglas Seay wrote:
> 
> Magnus Holmberg wrote:
> >
> > I like so sort the Subject, From,Date, .... Field of a mail-file and
> > store those in to variabels $dubject, $from, .....
> >
> > This work, but I have a feelin that this is not so clever.
> > Can someone tell me how to do this i a better way???
> >
> > ======================
> > open(IS, $file);
> > @EMAIL=<IS>;
> > close(IS);
> > foreach $line (@EMAIL)
> >       {
> >          ($name, $value) = split(/:/, $line);
> >          $LIST{$name}=$value;
> >       }
> > subject=$LIST{'Subject'};
> > chomp($subject);
> > $from=$LIST{'From'};
> > chomp($from);
> > $to=$LIST{'To'};
> > chomp($to);
> > $date=$LIST{'Date'};
> > chomp($date);
> 
> I think that Mail::Internet.pm will do this for you.  But I don't see
> anything wrong with what you're doing other than:
> 
> do the chomp() of $value at the top instead of each variable
> 
> make the assignment look like check for non-existance
>         $to = $LIST{'To'} || '';
> 
> look for the blank line after the header lines before the body
>         last unless ( $line );
> 
> - doug
Where at the top should I do the chomp($value);
I tried it in the foreach-loop, but I got the "Use of uninitialized
value at...


------------------------------

Date: Wed, 09 Apr 1997 20:01:16 +1000
From: Graham Matthews <graham.matthews@maths.anu.edu.au>
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
Message-Id: <334B68EC.3F66@maths.anu.edu.au>

Smiljan Grmek wrote:
> Tcl is an ugly duckling, to be sure - but all real-world langugages of
> any impact are: COBOL, FORTRAN, C, C++, (awk, perl ... and the
> unmentionable VB) with possible exceptions of PASCAL and ADA. For
> contrast we can look at the elegant ones: Algol, LISP, Smalltalk, Scheme
> (and here I refuse to name the recent ones, studies having shown that
> most of the people earning their bread by programming are incapable of
> understanding and using them). They are orthogonal, concise, clear - but
> used mostly by the academe and as test-beds for extensions 

The argument is flawed. Smalltalk is in fact widely used in commercial
programming. So your nice separation into "ugly but used" vs "elegant
and academic" is false. Moreover Java is taking off commercially and yet
it is essentially a subset of Smalltalk.

Smiljan Grmek wrote:
> Is it possible that languages with bumps and rough surfaces are somehow
> easier to remember and decode when reading than quicksilver smooth
> theoretical ones? Is it perhaps easier to interpret an ad-hoc construct
> than to reconstruct semantics from first principles?

There is a much simpler reason why all these ugly languages about -- its
called intertia. There was a lot of code written in the 70s in ugly
languages -- written before we knew how to make good languages. All that
code has to be supported, interfaced to, etc, so all the ugly languges
it is written in are now the standard. Simple.

graham
-- 
                 well alas we've seen it all before
                   knights in armour, days of yore
             the same old fears and the same old crimes 
               we haven't changed since ancient times


------------------------------

Date: 07 Apr 1997 14:02:15 -0400
From: lmichael@gdc.com (c.l.p.m.)
Subject: Re: running a loop foreach $ARGV?
Message-Id: <bhqencmyamw.fsf@gdc.com>

bart.mediamind@tornado.be (Bart Lateur) writes:

> >  I need to do a bunch of stuff with every file from the command line.
> 
> > foreach (@ARGV) {
> >     open(FILE, "$_") || die("Can't open $_: $!");
> >     while(<FILE>) {
> >         print;
> >     }
> >     close(FILE);
> > }
> 
> The construct I use most in the last months is this:
> 
> while ($file=shift) {
>    open(IN,$file);
>    while(<IN>) {
>       #do stuff with line
>    }
> }

How about the usual

while (<>) {
  #do stuff with line
  if (eof) {
	#Do stuff at end of each file
  }
  if (eof()) {
	#Do stuff at the end of the last file
  }
}

Handles multiple files on command line, or even STDIN (typed in or piped).

YMMV,
-- 
Laurence Michaels <lmichael@gdc.com>
Spam will be bounced.  You have been warned.


------------------------------

Date: 9 Apr 1997 06:32:56 GMT
From: rachel@juno.virago.org.au (Rachel Polanskis)
Subject: splitting and reading data in an elm mailbox
Message-Id: <5ifd6o$bvr@janis.virago.org.au>
Keywords: perl, email, array, mailbox, sort, split

Hello,

I am trying to write a program to scan an elm mailbox 
and then print out stats based on the data contained in the "From " envelope
header, the Subject: and the body of the message.

What I want is for my program to first split the messages up into 
a "virtual file" so I can massage the data and then proceed to the next message 
in the mailbox.

I can do this for a single message, (since it is the total content of the 
file) but not for a bunch of messages.

I looked at some perl5 modules in CPAN to do this, but they looked like 
overkill, and I found the examples with the modules extremely cryptic
and they did not seem to do what I wanted anyway.

How can I grab each message, using the "From " envelope header as 
my delimiter, and massage the data in it, then proceed to the next message?

I guess what I am looking for is "split()" for a whole block of 
text, using "From " as the delimiter, so I can work on each message's
data individually.

Can anyone help, with some examples on how to do this?

thanks

rachel





                 defghijklmnopqrstuvwxyz:  What? No ABC?
--
Rachel Polanskis                 Kingswood, Greater Western Sydney, Australia 
grove@zeta.org.au                http://www.zeta.org.au/~grove/grove.html
r.polanskis@nepean.uws.edu.au    http://www.nepean.uws.edu.au/ccd/
                Witty comment revoked due to funding cuts


------------------------------

Date: 9 Apr 1997 10:27:12 GMT
From: schmidt@misun13.iai.fzk.de (Andreas Schmidt)
Subject: Re: Substitution Question
Message-Id: <5ifqu0$aa5$1@nz12.rz.uni-karlsruhe.de>

In article <334AA7A4.41C6@vnet.ibm.com>, Thomas Parker <thpr@vnet.ibm.com> writes:
 |> Pardon my question on "Substitution" and "Quoting" (I think!), I've read
 |> the FAQs and such, and have a solution (see below) but would like to
 |> know from the more experienced people out there if there is a better way
 |> to solve this problem.
 |> 
 |> Thanks!
 |> 
 |> If I have:
 |> 
 |> $temp_item = "A+B";
 |> $master_item = "((A+B)/C)+((A+B)-D)";
 |> 
 |> how do I get $master_item to be:
 | > 
 |> ((E)/C)+((E)-D)
 |> 
 |> I have tried:
 |> 
 |> $master_item =~ s/$temp_item/E/g;
 |> 
 |> But this fails because $temp_item contains a "+" which seems to be
 |> evaluated as a regular expression.
 |> 
 |> I know
 |> 
 |> $master_item =~ s'$temp_item'E'g;
 |> 
 |> will not work because it does not expand $temp_item.
 |> 
 |> Do I have to [i.e. my current solution]
 |> 
 |> ($replace_item = $temp_item) =~ s/([^\w\s])/\\$1/g;
 |> $master_item =~ s/$replace_item/E/g;
 |> 
 |> ??
 |> 
 |> Thanks.
 |> 

hello peter,

you must escape the '+' sign. this is done by writing
$temp_item="A\\+B"; then it works. 

print $temp_item prints:

A\+B

what exactly is what you want

hope that helps
smiff
========================================================================
andreas schmidt                                email: schmidt@iai.fzk.de 
institut fuer angewandte informatik (iai)        phone: +49 7247 82 5714
forschungszentrum karlsruhe gmbh
    - technik und umwelt -       
postfach 3640                                  76021 karlsruhe (germany)



------------------------------

Date: 8 Apr 1997 19:46:08 GMT
From: "Peter Dohm" <dohmp@lci.com>
Subject: timelocal strangeness and my obvious insanity... :)
Message-Id: <01bc4455$33aee4a0$ccc69f96@dunt0008>

hello all.

i'm having the strangest problem and would appreciate someone confirming my
sanity... :)

try this:
------------
require "timelocal.pl"

$scalar1 = timegm(59,59,23,31,3,97);
$scalar2 = timegm(0,0,0,1,4,97);

print "below we should see a result of one second:\n";
print "scalar2 - scalar1 =";
print $scalar2-$scalar1;
print "\n";
------------

when i do this, i expect to see scalar2 - scalar1 to be "1" second.

instead, i get scalar2 to be 1 second short of one day **LESS/EARLIER**
than scalar1...

strange indeed.

anyone have any good insight?

i've been poking into timelocal and haven't noticed anything obvious wrong
with it...
(but am continuing in my playing...  i can't believe that this thing
(timelocal.pl)
would have a bug that *I* am finding after it's not been changed since
4.0.36...)

Pete
dohmp@lci.com



------------------------------

Date: Tue, 8 Apr 1997 20:33:41 GMT
From: msohnius@novell.co.uk (Martin Sohnius x24031)
Subject: Re: Unix and ease of use  (WAS: Who makes more ...)
Message-Id: <E8C6G5.BB0@ukb.novell.com>

Kaz Kylheku (kaz@vision.crest.nt.com) wrote:
: In article <01bc43a7$0c0cdbe0$87ee6fce@timpent.a-sis.com>,
: Tim Behrendsen <tim@a-sis.com> wrote:
: >BTW, no offense, but *why* do people post PGP signatures?  Is it just
: >me, or is it completely ridiculous?

: It's so that when they post something completely idiotic, they can be
: nailed beyond the shadow of a doubt. Stupid, if you ask me.

: I have a PGP key floating around the servers somewhere, but I'll be
: darned if I go through the trouble of signing every damn e-mail or posting.
: It's a complete waste of bandwidth to authenticate yourself without first
: being challenged to do so. You only need the authentication if someone doesn't
: believe that you wrote the text. In that case, you can respond to the challenge
: by privately forwarding a copy of the text along with your digital signature.

Well, yes and no.  It may be easy in retrospect to prove that you did write
something, or at least that you agree with what was written, but it is very
difficult to prove that you have *not* written something.  That's what
these keys are really for.

They show that someone is so convinced of his own importance, that
he is sure someone else would want to fake his postings.

begin PGP key

hey man, I didn't this crap!

end PGP key

--
*******************************************************************
Martin F. Sohnius                             msohnius@novell.co.uk
Novell IS & T, Bracknell, England             +44-1344-724031 
*******************************************************************
*        if (status = UNDER_NUCLEAR_ATTACK)                       *
*               launch_full_counterstrike();                      *
*******************************************************************
(C) 1997 M.F.Sohnius -- free distribution on USENET
       (Not a spokesperson  -- just a cyclist!)


------------------------------

Date: Tue, 08 Apr 1997 21:11:08 -0600
From: justin.lodge@telecom.co.nz
To: scotth@sgi.com
Subject: Vendor Support for Perl5 on SGI
Message-Id: <860551393.27229@dejanews.com>

I want to write automatic file transfer scripts in Perl5 to run on SGI

The operations people won't accept this because we are still running IRIX
5.x here on our production SGI's and Perl5 isn't supported by SGI unless
we upgrade to IRIX 6.4 (see http://reality.sgi.com/scotth/info/perl5) -
Our upgrades aren't likely before Dec'97 and my file transfers won't wait
that long.....

So does anyone know of a ***reputable*** vendor that will take easy ;-)
money off our operations dept. for supporting Perl5 on all of the various
flavours of IRIX until version 6.4?

Don't you just love the people who don't trust something unless they've
paid through the nose for it.

Help please

Justin

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet


------------------------------

Date: Tue, 8 Apr 1997 15:20:33 GMT
From: hph@hphbbs.localnet (H.P.Heidinger)
Subject: Re: Who makes more $$ - Windows vs. Unix programmers?
Message-Id: <E8BryA.6Fq@hphbbs.ruhr.de>

In article <860344556snz@genesis.demon.co.uk>,
	fred@genesis.demon.co.uk (Lawrence Kirby) writes:
# In article <E844tC.I6p@hphbbs.ruhr.de> hph@hphbbs.ruhr.de "H.P.Heidinger" writes:
# 
>>  `Unix' stands for `UNIfied eXecutive' and is nothing but a
>>  philosophy for a unified executive
# 
# False - Unix doesn't stand for anything. It is a pun on the name of OS from
# which it was derived - Multics. Check the relevant FAQs.

  Come on -- gimme a break with that urban legend ... this was far
  before V7 and is dark history nowadays. The foundation of X/Open
  has set other pointers.

  Unix is what it is ... a ``UNIfied eXecutive'' -- an so it should
  be understood ... Amen! But if you wish, go fondeling your FAQ ...



# Lawrence Kirby | fred@genesis.demon.co.uk

Regards, Peter
-- 
#--------- H.P. Heidinger, Steeler Str. 121, 45138 Essen /Germany ----------#
# Call: +49-201: 8903091 (ISDN)  # 287802 (voice) # 287803 (analog data/FAX)
# A supercomputer is a machine, that runs an endless loop in just 2 seconds #


------------------------------

Date: 9 Apr 1997 09:26:37 GMT
From: kaz@vision.crest.nt.com (Kaz Kylheku)
Subject: Re: Who makes more $$ - Windows vs. Unix programmers?
Message-Id: <5ifncd$okb@bcrkh13.bnr.ca>

In article <E8BryA.6Fq@hphbbs.ruhr.de>,
H.P.Heidinger <hph@hphbbs.ruhr.de> wrote:
>In article <860344556snz@genesis.demon.co.uk>,
>	fred@genesis.demon.co.uk (Lawrence Kirby) writes:
># In article <E844tC.I6p@hphbbs.ruhr.de> hph@hphbbs.ruhr.de "H.P.Heidinger" writes:
># 
>>>  `Unix' stands for `UNIfied eXecutive' and is nothing but a
>>>  philosophy for a unified executive
># 
># False - Unix doesn't stand for anything. It is a pun on the name of OS from
># which it was derived - Multics. Check the relevant FAQs.
>
>  Come on -- gimme a break with that urban legend ... this was far
>  before V7 and is dark history nowadays. The foundation of X/Open
>  has set other pointers.

Char pointers or void pointers? :) What do pointers have to do with
the UNIX name?

>  Unix is what it is ... a ``UNIfied eXecutive'' -- an so it should
>  be understood ... Amen! But if you wish, go fondeling your FAQ ...

Oh I see. So it's ok to revise history as long as it's sufficiently
dark and before V7? What bullshit you going to say next? That hamburgers are
named after ham? Cheeseburgers are named after cheese, after all, right?

Sorry, your silly insistence that UNIX stands for ``UNIfied eXecutive'' (ha ha)
doesn't make it so.

The fact that UNIX is a pun on Multics is no urban legend, but a simple
historic fact. If you don't believe Lawrence Kirby, please write mail to
Brian Kernighan.


------------------------------

Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.  

To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.

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.

The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.

The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.

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 V8 Issue 260
*************************************

home help back first fref pref prev next nref lref last post