[33098] in Perl-Users-Digest
Perl-Users Digest, Issue: 4374 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 18 09:09:19 2015
Date: Wed, 18 Feb 2015 06:09:03 -0800 (PST)
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, 18 Feb 2015 Volume: 11 Number: 4374
Today's topics:
[Completely OT ] Re: Why can I get away with this? <m@rtij.nl.invlalid>
Re: [Completely OT ] Re: Why can I get away with this? <lionslair@consolidated.net>
Re: use Storable: failed example from Intermediate Perl <hjp-usenet3@hjp.at>
Re: Whitespace in code <kaz@kylheku.com>
Re: Whitespace in code <kaz@kylheku.com>
Re: Whitespace in code <kaz@kylheku.com>
Re: Whitespace in code <bauhaus@futureapps.invalid>
Re: Whitespace in code <rweikusat@mobileactivedefense.com>
Re: Why can I get away with this? <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Feb 2015 10:34:26 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: [Completely OT ] Re: Why can I get away with this?
Message-Id: <2iebrb-lag.ln1@news.rtij.nl>
On Mon, 16 Feb 2015 20:50:42 -0600, Martin Eastburn wrote:
> The 32 and 33 were floating drums machines - think of the IBM floating
> ball - in a barrel. They were TTY's I have a 33 today. With manuals.
With an 8 bit papertape reader?
M4
------------------------------
Date: Tue, 17 Feb 2015 16:10:18 -0600
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: [Completely OT ] Re: Why can I get away with this?
Message-Id: <u%OEw.2505053$Rp.2133846@fx23.iad>
On 2/17/2015 3:34 AM, Martijn Lievaart wrote:
> On Mon, 16 Feb 2015 20:50:42 -0600, Martin Eastburn wrote:
>
>> The 32 and 33 were floating drums machines - think of the IBM floating
>> ball - in a barrel. They were TTY's I have a 33 today. With manuals.
>
> With an 8 bit papertape reader?
>
> M4
>
The 33 the 32 was a 5 level pink tape.
Martin
------------------------------
Date: Tue, 17 Feb 2015 15:24:31 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: use Storable: failed example from Intermediate Perl
Message-Id: <slrnme6jov.fhq.hjp-usenet3@hrunkner.hjp.at>
On 2015-02-17 02:11, senorsmile <senorsmile@gmail.com> wrote:
> On Monday, February 16, 2015 at 4:12:06 AM UTC-8, Justin C wrote:
>> On 2015-02-16, senorsmile wrote:
>> > use Storable;
[...]
>> > my $frozen = freeze [\@data1, \@data2];
>> >
>> > which gives me a syntax error. I have simplified it to the point
>> > where I get a more useful error:
>> >
>> > use Storable;
>> > my @data1 = qw(one won);
>> > my $frozen = freeze \@data1;
>> >
>> > Backslash found where operator expected at -e line 4, near "freeze \"
>> > (Do you need to predeclare freeze?)
>> >
>> >
>> > If I use the "fully qualified" form of freeze
>> > Storable::freeze
>> > it works fine. I shouldn't have to do this though, right?
>>
>> Storable doesn't export 'freeze' by default. Either do what you're
>> doing now or change the 'use' line:
>>
>> use Storable qw/freeze/;
>>
>> and import freeze.
>
> Thanks guys. I realize now after rereading the docs on metacpan for
> Storable that this is indeed the case. So, I have two (hopefully not
> too annoying) followup questions:
>
> 1. Is this how it's supposed to be? (And thus, the example in the book
> is incomplete?)
Yes. Modules should export very few, if any, symbols by default. Let the
user explicitely import those that they want to use.
> 2. What is the best way, without examining the source of the .pm to
> figure out what is imported from a module by default? i.e. How would
> YOU go figure it out in the most time efficient manner?
1. Read the docs. The synopsis says:
use Storable;
store \%table, 'file';
$hashref = retrieve('file');
use Storable qw(nstore store_fd nstore_fd freeze thaw dclone);
[... more examples ...]
This is very terse, but it gives you a hint that only store and retrieve
work with a plain „use Storable“, all the other functions need to be
explicitely imported. (I agree that this should be explicitely mentioned
in the text, too.)
2. „use strict; use warnings;“ and add parentheses around function
arguments (i.e., write „freeze(\@data)“, not „freeze \@data“). Then you
get the error
Undefined subroutine &main::freeze called at senorsmile2 line 9.
which is a much better hint of what's going on than "syntax error".
(Although „Do you need to predeclare freeze?“ is IMHO quite good as
an error message)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 17 Feb 2015 07:05:54 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Whitespace in code
Message-Id: <20150216223442.383@kylheku.com>
On 2015-02-16, G.B. <bauhaus@futureapps.invalid> wrote:
> On 15.02.15 23:03, Peter J. Holzer wrote:
>> Or maybe an IDE like Eclipse.
>
> For me, a big problem with learning vi is caused by authors
> of tutorials using this approach: NOT starting it with
> everything that really is intuitive (mnemonic) in vi,
> once accepted:
> d for delete, r for replace, w for word, e for end,
> ) for end of sentence, } for end of paragraph, / for RE,
> % for matching bracket etc., BUT to start from hysterical
> raisins like h j k l! This degree of unintuitive operation
> can drive anyone away, I think.
The hjkl group isn't mnemonic by association with English words; their
association is obviously spatial, and they are all in a row; if you remember
that h is left, and your index finger is used, the rest follow.
It's not obvious whether j is up or l, but you know those two are the up/down
pair. With just a little practice, it becomes second nature.
Using hjkl is an important vi skill, because it keeps your fingers near the
home row.
You would not want these commands to be laid out mnemonically, by association
with the first letters of English words. That might help you for the first
five minutes, and hurt you forever after.
------------------------------
Date: Tue, 17 Feb 2015 07:31:00 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Whitespace in code
Message-Id: <20150216230617.990@kylheku.com>
On 2015-02-16, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
> On 2015-02-16 10:43, G.B. <bauhaus@futureapps.invalid> wrote:
>> On 15.02.15 23:03, Peter J. Holzer wrote:
>>> Or maybe an IDE like Eclipse.
>>
>> For me, a big problem with learning vi is caused by authors
>> of tutorials using this approach: NOT starting it with
>> everything that really is intuitive (mnemonic) in vi,
>> once accepted:
>> d for delete, r for replace, w for word, e for end,
>> ) for end of sentence, } for end of paragraph, / for RE,
>> % for matching bracket etc., BUT to start from hysterical
>> raisins like h j k l! This degree of unintuitive operation
>> can drive anyone away, I think.
>
> Sturgeon's law: 90% of everything is crud.
>
> This is doubly true for tutorials in the web. And probably thrice true
> for vi tutorials. I'm not sure if I have ever read a really good vi
> tutorial, although pieces of several tutorials helped me tremendously.
>
> I think the most important rules with vi are:
>
> 1) vi is not a typewriter emulator. It is an editor, i.e. a tool
> for editing (= changing) text. As a programmer (and probably also as
> an author) you spend most of your time changing existing text, not
> writing new text, so that's what it is optimized for.
>
> 2) vi knows two types of commands: Actions and Movements. They
> are orthogonal and you can combine them.
They are not completely orthogonal.
Example: the w motion spans a certain amount of text, and dw deletes the
text that is spanned by the motion. Likewise for e and de.
But, whereas ce orthogonally changes the text spanned by e (the same text that
would be deleted by de), cw does not change the text spanned by w; cw behaves
non-orthogonally. If the cursor is on a word, it behaves like ce. If the cursor
is not on a word, then it behaves like c combined with the w motion.
> 3) vi doesn't have "modes". What is described as the "insert mode"
> in most tutorials is really just the argument to one of the insert
> commands. (Unfortunately this isn't really true in most vi clones
> including vim any more)
Rather, the claim that vi has modes but other editors do not is an
inconsitent viewpoint.
Any program which implements a state machine with more that one state has
modes.
If we look into just about any editing program, we will find modes.
The letter 'a' for instance cannot unconditionally have the action of
inserting itself into the buffer in a reasonably featured editor.
Sometimes you need to invoke a "Save as ..." type of command, and in that
command you want to be able to use 'a' as the constituent character of a file
name, such as the second letter of "parser.c". While you are typing "parser.c",
the 'a' that you type suddenly isn't going into the document buffer like it did
before. That can only be because, doh, you're in a file-name-entering mode!
The so-called "non-modal" editors in which most inputs have the action of
inserting a character and remaining in the initial state are intuitive, but
badly suited for making numerous small, precise changes in numerous places.
They are best suited for writing stream-of-consciousness prose where the main
editing tool is the backspace or simple cut-and-paste.
------------------------------
Date: Tue, 17 Feb 2015 07:54:00 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Whitespace in code
Message-Id: <20150216233411.976@kylheku.com>
On 2015-02-16, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
> On 2015-02-16 02:22, Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2015-02-15, Robbie Hatley <see.my.sig@for.my.address> wrote:
>>> On 2/9/2015 9:50 PM, $Bill wrote:
>>>> On 2/9/2015 09:57, Robbie Hatley wrote:
>>>> >
>>>> > Since then, I've switched to a different text editor on my Win8.1
>>>> > notebook, "Notepad++" ...
>>>>
>>>> Haven't tried it, but I would suggest you try a Win32 native port of
>>>> Vim or Emacs - I've been using vim (gvim) the entire time I've been
>>>> using a PC and it's predecessor (vi) the entire time I was on UNIX.
>>>
>>> I find the learning curve for vi to be more time-consuming than
>>> I can afford.
>>
>> For me, that learning curve was some long-forgotten week in 1995 when I
>> switched to Vim. Actually, at that time, I downloaded and compiled every open
>> source clone of Vi I could get my hands on.
>
> So you obviously already knew vi. Was that your learning curve for
> switching from vi to vim?
No, I didn't know vi. At the time I was using Emacs. Suddenly, out of the blue,
I decided to get into vi. So that's when I ended up switching to Vim (in the
end). I compiled and installed all the implementations I could get my hands
on: xvi, elvis, ... and used them all. After a week, I was just using Vim
though, and I was proficient enough that that was all I used.
I drank the full Kool-Aid, including hjkl. It reminded me of the ijkm editing
"cross" on the Apple II, but with a smarter layout.
By the way, I seem to recall that "vimtutor" existed already and that I went
through it. When I fire up "vimtutor" today, it seems eerily familiar. :)
> For me the learning curve for vi was probably the better part of a
> semester. The basics I had within 2 hours or so (but then I already knew
> the UCSD p-System editor, which was also command based), but to get
> really familiar took a long time (using the damn thing on a VT102
> terminal with probably not ideal termcap settings had something to do
> with it. Having used KEDIT (a PC clone of the extremely powerful IBM
> host XEDIT, not the KDE editor) before that was also not exactly
> motivating).
I had been a big user of SemWare's QEdit on DOS. I had used WordStar (on
CP/M, run on a Z80 co-processor card for Apple II! So text editors
with WS-like key mappings worked for me.)
It's all a very distant memory. Vim wiped it all out. :)
------------------------------
Date: Tue, 17 Feb 2015 11:52:35 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: Whitespace in code
Message-Id: <mbv6ga$cd6$1@dont-email.me>
On 17.02.15 08:05, Kaz Kylheku wrote:
> Using hjkl is an important vi skill, because it keeps your fingers near the
> home row.
>
> You would not want these commands to be laid out mnemonically,
I wouldn't want these commands at all in a programmers'
editor ;-) Rather, all commands should be referring to parts
of text instead of to mere directions! This doesn't always
work.(*) E.g. when there is no suitable text, when columns
do matter, as in the tabular layout of crontab files and
the like which use whitespace syntactically.
Perl's split function is reminiscent of these hacks,
inspired by typewriters and still working.
Your arguments indicate that there are (persuasive?) ways to make
any interested student of vi remember any keys for motions that
follow the "arrow directions" and that there are other things
to say in their favor. But the point is that a vi _tutorial_
that starts with h j k l misses one important thing, namely
first impressions!
If, instead, plain vi appears as a logical, intuitive,
consistent, and focused thing from the very beginning,
then one can defer arguments in favor of h j k l.
__
(*) Even excluding situations that let programmers, tired and
under pressure, nervously operate vi's "arrow keys" h j k l
in order to get some job done, the first or second time.
------------------------------
Date: Tue, 17 Feb 2015 20:35:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Whitespace in code
Message-Id: <87egpowa1j.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
[...]
> They are best suited for writing stream-of-consciousness prose where
> the main editing tool is the backspace or simple cut-and-paste.
I realize I should be ignoring this so I'm going to ignore the 'editor'
part: 'Stream of consciousness' is the name of a certain, narrative
mode, IOW, it doesn't mean "keep babbling without rhyme or reason" (that
would be "twitter of consciousness" :->) and the structure of a text
employing this mode is no different from the structure of 'prose' texts
in general (ie, "anything which is not verse").
------------------------------
Date: Tue, 17 Feb 2015 14:52:22 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why can I get away with this?
Message-Id: <87fva4h9p5.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2015-02-16 15:56, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
[...]
>> No. It is to say that the C language doesn't define a data type 'string'
>> (it has string literals but these are specifically not required to
>> adhere to the library convention)
>
> This is a rather bold statement.
>
> There are some library functions which don't expect or produce
> null-terminated strings. There is also one[1] circumstance in which a
> string literal will not result in a null-terminated sequence of bytes.
> But in general the rule for string literals and library functions is the
> same: A string literal is translated to a sequence of bytes terminated
> with '\0', and library functions dealing with "strings" expect and
> produce the same.
A 'character string literal' is defined as
A character string literal is a sequence of zero or more multibyte
characters enclosed in double-quotes.
It is further said that
In translation phase 7, a byte or code of value zero is appended
to each multibyte character sequence that results from a string
literal or literals.
And this doesn't say (or imply) anything about other occurrences of
'null characters' between the "". This
"\0abc\0def"
is a perfectly valid C 'character string literal' (not totally unlike
Perl scalars which can also contain bytes with value 0 and which are
also always terminated with one not accounted for in the length).
> Indeed this is the very definition of a "string" in
> the standard: "A string is a contiguous sequence of characters
> terminated by and including the first null character." (Oh, wait, that
> was already posted by some "Rainer Weikusat". Are you sure there aren't
> two people using that name?)
As I already wrote there: This definition resides at the beginning of
chapter 7 titled "Library", while the previous one (containing the
definition of 'string literal') is named "Language" (strings are also
mentioned without a prior definition in the 'program startup'
section). Hence, 'string' is a construct defined for the purposes of
the C standard library but not by the C language definition.
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4374
***************************************
