[32732] in Perl-Users-Digest
Perl-Users Digest, Issue: 3996 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jul 21 21:09:27 2013
Date: Sun, 21 Jul 2013 18:09:06 -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, 21 Jul 2013 Volume: 11 Number: 3996
Today's topics:
Foo::Bar::Libfoobar vs. Libfoobar? <oneingray@gmail.com>
Re: names, values, boxes and microchips <ben@morrow.me.uk>
Re: names, values, boxes and microchips <rweikusat@mssgmbh.com>
Re: names, values, boxes and microchips <ben@morrow.me.uk>
Re: names, values, boxes and microchips <derykus@gmail.com>
Re: names, values, boxes and microchips <rweikusat@mssgmbh.com>
Re: names, values, boxes and microchips <rweikusat@mssgmbh.com>
Re: Restart Perl Application upon KDE Restart <ben@morrow.me.uk>
Re: Restart Perl Application upon KDE Restart <bjoern@hoehrmann.de>
Re: Restart Perl Application upon KDE Restart <hjp-usenet3@hjp.at>
Re: Restart Perl Application upon KDE Restart <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
using Exporter::export_fail <AndSiPerl@Arcor.De>
Re: using Exporter::export_fail <ben@morrow.me.uk>
Re: using Exporter::export_fail <AndSiPerl@Arcor.De>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 21 Jul 2013 22:41:56 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Foo::Bar::Libfoobar vs. Libfoobar?
Message-Id: <87li4ztu17.fsf@violet.siamics.net>
I'm curious, what's the current preferred naming scheme for Perl
bindings to C libraries? Given such modules as GD or
Image::Magick, I'd assume that the bindings for Libfoobar are
ought to live in a module named Libfoobar.
Somehow, however, I'd find it tempting to use a longer, yet more
descriptive, Foo::Bar::Libfoobar; especially if there's a
related Foo::Bar module already on CPAN, and that Foo::Bar would
be the "proper" name for Libfoobar, should it be (re)implemented
as a native Perl library.
Perhaps there's anything else to consider?
TIA.
--
FSF associate member #7257
------------------------------
Date: Sun, 21 Jul 2013 18:01:35 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: names, values, boxes and microchips
Message-Id: <fogtba-pi21.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rw@sapphire.mobileactivedefense.com>:
>
> I've used the catchup function of my newsreader to throw everything in
> this group away since my less-than-reasoned two postings of
> yesterday. While I've grown somewhat more accustomed to ordinary human
> meanness, the umount of totally irrational[*] vitriolic rage some
> people are capable of when being confronted with concepts alien to
> them
There was no vitriol aimed in your direction. If I had been genuinely
angry I would not have replied, you would simply have gone straight in
my killfile. It's not worth wasting anger on Usenet posters.
That said, if the way I expressed myself upset you, I apologise. That
was not my intention.
> (such as using 'lexically scoped subroutines' with meaningful
> names instead of duplicated code) is still a little bit too much for
> me. But there are two points I'd like to clear up a little.
>
> 1. 'Bubblesort': This is not, in fact, the bubblesort algortihm but an
> insertion sort variant, somewhat obscured by the need to work around
> behaviour built into the 'part' subroutine which isn't really useful
> for this case: It works by searching the place where the item on the
> filter list had to be inserted into the other if it was to be
> inserted. A somewhat less contorted implementation could look like
> this (uncompiled/ tested) example:
>
> my ($f, $i, $next, @out);
>
> for $f (@$filter) {
> $next = [];
>
> for $i (@$in) {
> given ($i->net_compare($f)) {
> when (R_AFTER) {
(Smartmatch and given/when are deprecated in 5.18, so it's probably not
a good idea to use them in new code.)
> push(@out, $i);
> }
>
> when ([R_BEFORE, R_SUB) {
> push(@$next, $i);
> }
> }
>
> $in = $next;
> }
>
> This is still rather bizarre, given that both input list are sorted
> and free of items which are a subset of other items on the list,
> because there's no reason to continue comparing $f with elements on
> @$in after its place in the list has been found, ie, after a
> comparison either returned '$f is in front of this' (R_BEFORE) or '$f
> is a subset of this' (R_SUB) since the result of all remaining
> invocations will be R_BEFORE. That's a direct result of the
> unfortunate choice to use a general purpose 'partition a list' routine
> for the inner loop: That's not quite what is really needed for an
> insertion sort
I agree, it's not ideal. However, even your implementation above still
obscures the most important assumption of the algorithm, which is that
the R_AFTER entries all come before the R_SAME entries which all come
before the R_BEFORE entries. You, I am sure, regard this as obvious,
since you wrote the code, but it's not at all clear to someone else
reading it.
How about something more like this (untested)?
use List::MoreUtils qw/firstidx any/;
sub shift_while {
my ($in, $f, @match) = @_;
my $ix = firstidx {
my ($rc) = $_->net_compare($f);
not any { $rc == $_ } @match;
} @$f;
splice @$in, 0, $ix - 1;
}
sub filter_against {
my ($in, $filter) = @_;
$in = [@$in]; # if you like
map {
my @out = shift_while $in, $f, R_AFTER:
p_alloc(...)
for shift_while $in, $f, R_SAME, R_SUPER;
@out;
} @$filter;
}
> but 'clarity of the implementation be damned,
> ('clarity' in the sense that all operations which are part of the
> algorithm are actually useful steps wrt accomplishing the desired
> end) we can Cleverly(!) save two lines of code here' ...
My aim is not to save lines of code, it's to make the algorithm as clear
as possible. My algorithm may not have been the best choice, but it took
me quite a bit of thought to work out what yours was in the first place.
Loops which iterate over two arrays at once are not easy to follow,
especially when the iteration and termination steps are hidden inside
callbacks.
> 2. __func__: That's a feature of C Perl unfortunately lacks, namely, a
> 'special expression' containing the name of the current
> subroutine. This is useful for diagnostic messages because it enables
> someone reading through the debug output to identify the code which
> produces a particular 'diagnostics statement' more easily than by
> grepping for the string. The equivalent Perl expression is
>
> (caller(1))[3]
>
> when invoked as an actual subroutine or
>
> (caller(0))[3]
>
> when the expression is 'inlined' instead. __func__ is defined as
> subroutine,
Yes, I understood what it was, and how you'd done it, and why. It's not
a bad idea, though I'd probably just use warn.
> [*] Eg, referring to use of an O(n) algorithm for merging two sorted
> lists as 'pointless microoptimization which would be better
> accomplished by using C instead of Perl' --- that's not 'an
> optimization' aka 'attempt to cover the well after the
> baby drowned' at all but the obvious 'textbook' choice.
The O() classifications refer to *limiting* complexity, so they are most
important in the limit; that is, when n is large. In this case n is
small.
Ben
------------------------------
Date: Sun, 21 Jul 2013 20:53:22 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: names, values, boxes and microchips
Message-Id: <87r4er1yh9.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rw@sapphire.mobileactivedefense.com>:
[...]
>> my ($f, $i, $next, @out);
>>
>> for $f (@$filter) {
>> $next = [];
>>
>> for $i (@$in) {
>> given ($i->net_compare($f)) {
>> when (R_AFTER) {
>
> (Smartmatch and given/when are deprecated in 5.18, so it's probably not
> a good idea to use them in new code.)
Not really. They're re-classified as 'experimental', mainly because
the 'smart match' operation is considered to be ill-defined/
confusing, something I wholeheartedly agree with: The problem with all
'do what I mean'-algorithms is that they're "Damn Warren's Infernal
Machine" for people other than the 'I' who wrote down what he meant.
[...]
> I agree, it's not ideal. However, even your implementation above still
> obscures the most important assumption of the algorithm, which is that
> the R_AFTER entries all come before the R_SAME entries which all come
> before the R_BEFORE entries. You, I am sure, regard this as obvious,
> since you wrote the code, but it's not at all clear to someone else
> reading it.
>
> How about something more like this (untested)?
There's something in here that you seemingly failed to get so far,
namely, the operation performed by the algorithm I posted is
(conceptually) a 'simple' single-pass merge operation of two sorted
lists. That's the 'merge' part of the mergesort algorithm invented
(according to Wikipedia) by John von Neuman in 1945. Abstractly
described, it works like this:
while neither input list is empty
compare the two items at the front
move the smaller one to the output list
elihw
This is slightly more complicated for the actual case because the
items I'm dealing with are IPv4 (sub-)networks, hence, the comparison
routine has five possible results (2nd operand comes after 1st, before
1st, is identical to 1st, is a subset of 1st or is a superset of 1st)
and 'duplicates' (input item is identical to or a subset of filter
item) are dropped instead of becoming part of the output. It also
deviates from a 'plain merge' because the items on the filter list
aren't really moved to the output list, just removed from filter as
soon as they become 'the smallest item'.
This is a simple, well-known algorithm which is part of an elementary
sorting algorithm first published 68 years ago and I absolutely don't
think inventing a more complicated 'new one', especially if that is
also very likely going to be 'less efficient' in the sense that it
does more comparisons and/or move operations is appropriate.
[...]
>> but 'clarity of the implementation be damned,
>> ('clarity' in the sense that all operations which are part of the
>> algorithm are actually useful steps wrt accomplishing the desired
>> end) we can Cleverly(!) save two lines of code here' ...
>
> My aim is not to save lines of code, it's to make the algorithm as clear
> as possible. My algorithm may not have been the best choice, but it took
> me quite a bit of thought to work out what yours was in the first
> place.
That should have been abundantly clear from the leading statement
which talked about 'processing two sorted input lists in order to
produce an output list' ('should have been' here meaning I expected
that the first thing anyobdy reading this would think of would be
"aha, a mergesort").
> Loops which iterate over two arrays at once are not easy to follow,
> especially when the iteration and termination steps are hidden inside
> callbacks.
These are not 'callbacks' as they're not passed to other code which
'calls back into the calling code', they're lexicially scoped
subroutines performing a part of the algorithm whose details don't
matter for 'the main loop', namely, "move to the next item in this
list if there is one, otherwise, terminate the loop" which exist so
that the same (or an 'almost same') code sequence isn't contained in
there in three different places. Instead, it is 'called upon'
using a sensible name, ie, 'step_in' for 'step the in list' or
'step_filter' for 'step the filter list'. The names may not be all
that sensible but if so, that's because of my lacking English, not
because of deficiencies of the idea itself.
[...]
>> [*] Eg, referring to use of an O(n) algorithm for merging two sorted
>> lists as 'pointless microoptimization which would be better
>> accomplished by using C instead of Perl' --- that's not 'an
>> optimization' aka 'attempt to cover the well after the
>> baby drowned' at all but the obvious 'textbook' choice.
>
> The O() classifications refer to *limiting* complexity, so they are most
> important in the limit; that is, when n is large. In this case n is
> small.
For the 'common case', this will still make 17 or 34 pointless
comparisons and as many copy operations. That's in itself no big deal
but they don't buy anything, considering that the merge algorithm is
both old and 'popular' despite it deals with two lists in one loop.
------------------------------
Date: Sun, 21 Jul 2013 22:51:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: names, values, boxes and microchips
Message-Id: <sn1uba-8851.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rw@sapphire.mobileactivedefense.com>:
>
> > I agree, it's not ideal. However, even your implementation above still
> > obscures the most important assumption of the algorithm, which is that
> > the R_AFTER entries all come before the R_SAME entries which all come
> > before the R_BEFORE entries. You, I am sure, regard this as obvious,
> > since you wrote the code, but it's not at all clear to someone else
> > reading it.
> >
> > How about something more like this (untested)?
>
> There's something in here that you seemingly failed to get so far,
> namely, the operation performed by the algorithm I posted is
> (conceptually) a 'simple' single-pass merge operation of two sorted
> lists. That's the 'merge' part of the mergesort algorithm invented
> (according to Wikipedia) by John von Neuman in 1945.
No, I understood that perfectly well, *eventually*. My point is that it
was far from obvious from the code.
> This is a simple, well-known algorithm which is part of an elementary
> sorting algorithm first published 68 years ago and I absolutely don't
> think inventing a more complicated 'new one', especially if that is
> also very likely going to be 'less efficient' in the sense that it
> does more comparisons and/or move operations is appropriate.
I have never questioned the appropriateness of the algorithm. My latest
example uses the *same* algorithm, it is just (IMHO) a great deal
clearer about what is happening.
> >> but 'clarity of the implementation be damned,
> >> ('clarity' in the sense that all operations which are part of the
> >> algorithm are actually useful steps wrt accomplishing the desired
> >> end) we can Cleverly(!) save two lines of code here' ...
> >
> > My aim is not to save lines of code, it's to make the algorithm as clear
> > as possible. My algorithm may not have been the best choice, but it took
> > me quite a bit of thought to work out what yours was in the first
> > place.
>
> That should have been abundantly clear from the leading statement
> which talked about 'processing two sorted input lists in order to
> produce an output list' ('should have been' here meaning I expected
> that the first thing anyobdy reading this would think of would be
> "aha, a mergesort").
Well, it wasn't. Possibly a comment explaining what was happening would
have helped, but I generally consider such comments (in Perl) to
indicate the code could be improved. In C I would probably have written
code equivalent to yours, with a comment explaining what was going on.
> > Loops which iterate over two arrays at once are not easy to follow,
> > especially when the iteration and termination steps are hidden inside
> > callbacks.
>
> These are not 'callbacks' as they're not passed to other code which
> 'calls back into the calling code', they're lexicially scoped
> subroutines performing a part of the algorithm whose details don't
> matter for 'the main loop', namely, "move to the next item in this
> list if there is one, otherwise, terminate the loop" which exist so
> that the same (or an 'almost same') code sequence isn't contained in
> there in three different places. Instead, it is 'called upon'
> using a sensible name, ie, 'step_in' for 'step the in list' or
> 'step_filter' for 'step the filter list'. The names may not be all
> that sensible but if so, that's because of my lacking English, not
> because of deficiencies of the idea itself.
Let's look at the main loop from your original post:
LOOP: {
($rc) = $in_item->net_compare($filter_item);
p_alloc('in %s, filter %s, rc %u',
$in_item, $filter_item, $rc);
given ($rc) {
when (R_AFTER) {
push(@out, $in_item);
&$step_in;
}
when ([R_BEFORE, R_SUB]) {
&$step_filter;
}
when ([R_SAME, R_SUPER]) {
p_alloc('%s: dropping %s (%s)', __func__,
$in_item, $filter_item);
&$step_in;
}
}
redo;
}
When does it terminate? How does it make progress? It's not even
immediately clear it's a *loop*: while (1) or for (;;) are the
conventional idioms.
Probably it would have helped to use an ordinary sub with arguments
rather than trying to be clever with closures, and a return value rather
than an implicit last. With a call like
step_array $in, \$in_pos, \$in_item
or last;
it's at least clear which variables are affected, and that this might be
an exit condition. As a bonus, you don't get two almost identical
closures. Even then, this is so close to just being 'shift' that it
seems like unnecessary reinvention; in fact, I think it's equivalent to
($in_pos, $in_item) = each @$in
or last;
Ben
------------------------------
Date: Sun, 21 Jul 2013 16:29:37 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: names, values, boxes and microchips
Message-Id: <kshqtl$u0r$1@speranza.aioe.org>
On 7/21/2013 2:51 PM, Ben Morrow wrote:
>
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
> ...
> Let's look at the main loop from your original post:
>
> LOOP: {
> ($rc) = $in_item->net_compare($filter_item);
>
> p_alloc('in %s, filter %s, rc %u',
> $in_item, $filter_item, $rc);
>
> given ($rc) {
> when (R_AFTER) {
> push(@out, $in_item);
> &$step_in;
> }
>
> when ([R_BEFORE, R_SUB]) {
> &$step_filter;
> }
>
> when ([R_SAME, R_SUPER]) {
> p_alloc('%s: dropping %s (%s)', __func__,
> $in_item, $filter_item);
>
> &$step_in;
> }
> }
>
> redo;
> }
>
> When does it terminate? How does it make progress? It's not even
> immediately clear it's a *loop*: while (1) or for (;;) are the
> conventional idioms.
> ...
Even a more expressive 'do' might help a dizzy brain:
do {
....
}
until $in_pos == @$in or $filter_pos == @$filter;
--
Charles DeRykus
------------------------------
Date: Mon, 22 Jul 2013 01:06:38 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: names, values, boxes and microchips
Message-Id: <87ppubsbjl.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> This is a simple, well-known algorithm which is part of an elementary
>> sorting algorithm first published 68 years ago and I absolutely don't
>> think inventing a more complicated 'new one', especially if that is
>> also very likely going to be 'less efficient' in the sense that it
>> does more comparisons and/or move operations is appropriate.
>
> I have never questioned the appropriateness of the algorithm. My latest
> example uses the *same* algorithm, it is just (IMHO) a great deal
> clearer about what is happening.
Including the 'shift_while' I counted no less than six loops or 'loopy
constructs' in there. I have - plainly - no idea what this code does
(or would do) and I'm not really interested in determining that,
either: It is exceedingly unlikely that it is an improvement of the von
Neumann algorithm and even if it was, all the complications in order
to avoid something as simple as an addition, a comparison and an
assignment would hardly be worth the effort.
[...]
>> These are not 'callbacks' as they're not passed to other code which
>> 'calls back into the calling code', they're lexicially scoped
>> subroutines performing a part of the algorithm whose details don't
>> matter for 'the main loop', namely, "move to the next item in this
>> list if there is one, otherwise, terminate the loop" which exist so
>> that the same (or an 'almost same') code sequence isn't contained in
>> there in three different places. Instead, it is 'called upon'
>> using a sensible name, ie, 'step_in' for 'step the in list' or
>> 'step_filter' for 'step the filter list'. The names may not be all
>> that sensible but if so, that's because of my lacking English, not
>> because of deficiencies of the idea itself.
>
> Let's look at the main loop from your original post:
>
> LOOP: {
> ($rc) = $in_item->net_compare($filter_item);
>
> p_alloc('in %s, filter %s, rc %u',
> $in_item, $filter_item, $rc);
>
> given ($rc) {
> when (R_AFTER) {
> push(@out, $in_item);
> &$step_in;
> }
>
> when ([R_BEFORE, R_SUB]) {
> &$step_filter;
> }
>
> when ([R_SAME, R_SUPER]) {
> p_alloc('%s: dropping %s (%s)', __func__,
> $in_item, $filter_item);
>
> &$step_in;
> }
> }
>
> redo;
> }
>
> When does it terminate? How does it make progress?
In the appropriate way, as indicated by the auxilary subroutines. The
details of 'the appropriate way' don't matter for this loop which is
closer to the abstract algorithm than it could have been when
repeating the mechanics three times.
> It's not even immediately clear it's a *loop*:
With a block label of 'LOOP:' that shouldn't be to difficult to guess.
> while (1) or for (;;) are the conventional idioms.
I've had people complaining about that in the past as well: "But
that's not the way how I would have done it!" is a powerful impediment
to understanding: The guy who always writes for (;;;) will freak out
when seeing 'while (1)' simply because it looks different. Actually,
the guy who always writes 'for (...)' will freak out upon encountering
a loop using while for the first time and will be more strongly inclined to
'fix' the code by bringing it in line with his style of writing than
come to the conclusion that his knowledge of $language is less
complete than it ought to be[*].
[*] I had an excursion into a Lisp implementation written by someone
to support his 'web application development' business a while ago
(incredible as it may sound) and this code was written in a completely
alien style to me. Nevertheless, after understanding what it was doing
for which reasons, I came to the conclusion that - while I would
never write anything in this way - there were no objective reasons for
doing so, just a set of radically different but equally sensible
conventions colliding with some of my (unjustified) prejudices.
> Probably it would have helped to use an ordinary sub with arguments
> rather than trying to be clever with closures, and a return value rather
> than an implicit last. With a call like
>
> step_array $in, \$in_pos, \$in_item
> or last;
These aren't closures, either: They exist inside a certain, lexical
environment but don't 'capture' any part of it beyond its 'natural
lifetime'. The fact that the lists this algorithm works with are
represented as arrays are as irrelevant to it as the names of the
variables used to step through them: This is the 'abstraction' you've
repeatedly judged me of being incapable of understanding. It means
leaving out irrelevant details in favor of concentrating on a
higher-level description of what is going on: &$step_in instead of
last LOOP if ++$in_pos == @$in;
$in_item = $in->[$in_pos]
Perl 5.18 adds explicit support for lexically-scoped subroutines
without having to resort to references to anonymous subroutines so
constructs of this kind should become more common in future (IMHO,
they're rarely useful but this case happens to be one of the
exceptions).
[...]
> Even then, this is so close to just being 'shift' that it
> seems like unnecessary reinvention;
'shift' destroys the arrays it works with. I have to keep them intact.
> in fact, I think it's equivalent to
>
> ($in_pos, $in_item) = each @$in
> or last;
For the perl I'm mostly interested in (5.10.1), this complains loudly
about the fact that @$in is not a hash. Also, the index variables are
solely used to step through the arrays in a non-destructive way and
since they do make the implementation more complicated, being able to
get rid of them would be good.
------------------------------
Date: Mon, 22 Jul 2013 01:20:27 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: names, values, boxes and microchips
Message-Id: <87li4zsawk.fsf@sapphire.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 7/21/2013 2:51 PM, Ben Morrow wrote:
>>
>> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>> Ben Morrow <ben@morrow.me.uk> writes:
>> ...
>> Let's look at the main loop from your original post:
>>
>> LOOP: {
[...]
>> given ($rc) {
>> when (R_AFTER) {
>> push(@out, $in_item);
>> &$step_in;
>> }
[...]
>> redo;
>> }
>>
>> When does it terminate? How does it make progress? It's not even
>> immediately clear it's a *loop*: while (1) or for (;;) are the
>> conventional idioms.
>> ...
>
> Even a more expressive 'do' might help a dizzy brain:
>
>
> do {
> ....
> }
> until $in_pos == @$in or $filter_pos == @$filter;
That's what I originally did. But I didn't like the fact that I had to
assign something to the 'top of the list' variable after the
termination condition for the loop became true only to postpone the
check for that to the 'more conventional' location, especially
considering that I also write code in languages (PL/Pgsql) where the
most basic looping construct is really just
loop
-- do something
end loop
Loops with multiple termination conditions 'trueness' of which
becomes available as the 'loop body' processing proceeds are not that
uncommon and I thought it might be clearer to omit the 'mock loop
condition' at all since 'blocks are just single-iteration loops' (but
they don't have to be single-iteration). I haven't yet come to some
final opinion on this.
------------------------------
Date: Sun, 21 Jul 2013 17:13:58 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <6vdtba-7721.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <ks9i9d$1bf8$1@news.ntua.gr>, on 07/18/2013
> at 11:13 PM, "George Mpouras"
> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>
> >Content-Type: text/plain;
> > format=flowed;
> > charset="iso-8859-1";
> > reply-type=original
> >Content-Transfer-Encoding: 7bit
>
> !
Well, strictly speaking CTE isn't valid on Usenet, so it's just a
meaningless header...
Ben
------------------------------
Date: Sun, 21 Jul 2013 20:21:39 +0200
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <mj9ou8ld3g979vuj2dbfmgafgja416mrsl@hive.bjoern.hoehrmann.de>
* Ben Morrow wrote in comp.lang.perl.misc:
>Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>> In <ks9i9d$1bf8$1@news.ntua.gr>, on 07/18/2013
>> at 11:13 PM, "George Mpouras"
>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>>
>> >Content-Type: text/plain;
>> > format=flowed;
>> > charset="iso-8859-1";
>> > reply-type=original
>> >Content-Transfer-Encoding: 7bit
>>
>> !
>
>Well, strictly speaking CTE isn't valid on Usenet, so it's just a
>meaningless header...
<http://tools.ietf.org/html/rfc5536>:
The MIME header fields MIME-Version, Content-Type, Content-Transfer-
Encoding, Content-Disposition, and Content-Language are used in
Netnews articles in the same circumstances and with the same meanings
as those specified in [RFC2045], [RFC2183], and [RFC3282], with the
added restrictions detailed above in Section 2.2.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
Date: Sun, 21 Jul 2013 20:22:41 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <slrnkuo9nh.1ju.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-21 16:13, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>> In <ks9i9d$1bf8$1@news.ntua.gr>, on 07/18/2013
>> at 11:13 PM, "George Mpouras"
>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> said:
>>
>> >Content-Type: text/plain;
>> > format=flowed;
>> > charset="iso-8859-1";
>> > reply-type=original
>> >Content-Transfer-Encoding: 7bit
>>
>> !
>
> Well, strictly speaking CTE isn't valid on Usenet, so it's just a
> meaningless header...
RFC 5536, section 2.3:
| 2.3. MIME Conformance
|
| User agents MUST meet the definition of MIME conformance in [RFC2049]
| and MUST also support [RFC2231].
RFC 2049, section 2:
| 2. MIME Conformance
[...]
| A mail user agent that is MIME-conformant MUST:
[...]
| (2) Recognize the Content-Transfer-Encoding header field
| and decode all received data encoded by either quoted-
| printable or base64 implementations. The identity
| transformations 7bit, 8bit, and binary must also be
| recognized.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | 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: Mon, 22 Jul 2013 02:14:03 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: Restart Perl Application upon KDE Restart
Message-Id: <kshq0d$2nsa$1@news.ntua.gr>
http://imageshack.us/a/img5/2825/a7t5.jpg
------------------------------
Date: Sun, 21 Jul 2013 21:31:09 +0200
From: "A. Sicken" <AndSiPerl@Arcor.De>
Subject: using Exporter::export_fail
Message-Id: <51ec36ff$0$6548$9b4e6d93@newsspool4.arcor-online.net>
Hello,
I want to use the Exporter::export_fail-method to set some internal
debugging vars like:
use MyModul qw/enable_debug/; # to enable debugging messages
in following code example:
# --- CODE ---
use strict;
use 5.008; # and/or above version
package MyModul;
use Exporter;
our @ISA = qw/Exporter/; # to avoid namespace pollution
our @EXPORT_OK = qw/Some Symbols go here/;
our @EXPORT_FAIL = qw/enable_debug/;
our %EXPORT_TAGS = ( 'tag' => [@EXPORT_OK] };
our $VERSION = 1;
sub export_fail {
my $class = shift;
my $sym_name;
my @sym_fail;
while ($sym_name = shift) {
if ($sym_name eq 'enable_debug') {
# set var to use it later in module code
}else{
push @sym_fail, sym_name;
}#end_if
}#end_while
@sym_fail;
}#end_sub export_fail
# some module code goes hereafter
1;
__END__
# --- CODE ---
Now my questions: Is there a way to use the export_fail method without
declaring it within my module MyModul (or to destroy it after its first
invokation), because this means anyone can call this method as if it would
be a real method?
To clarify: I'm writing an oo-style framework/library and it seems
unnesseccary to me to provide this method as a real method for objects.
Maybe there is an easy way around this problem that takes inheritance into
account?
Thank you for your help and please excuse bad english.
A. Sicken
------------------------------
Date: Sun, 21 Jul 2013 21:23:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: using Exporter::export_fail
Message-Id: <pjstba-u641.ln1@anubis.morrow.me.uk>
Quoth "A. Sicken" <AndSiPerl@Arcor.De>:
> Hello,
>
> I want to use the Exporter::export_fail-method to set some internal
> debugging vars like:
>
> use MyModul qw/enable_debug/; # to enable debugging messages
>
> in following code example:
[...]
>
> Now my questions: Is there a way to use the export_fail method without
> declaring it within my module MyModul (or to destroy it after its first
> invokation), because this means anyone can call this method as if it would
> be a real method?
No. If you must, you can get rid of the method on it's first invocation
by deleting the glob from the symbol table, but I wouldn't recommend
doing that.
You could alternatively write your own import method, which removes
enable_debug from the symbol list and calls Exporter->export_to_level to
do the actual exporting.
Ben
------------------------------
Date: Mon, 22 Jul 2013 00:02:32 +0200
From: "A. Sicken" <AndSiPerl@Arcor.De>
Subject: Re: using Exporter::export_fail
Message-Id: <51ec5a7b$0$6562$9b4e6d93@newsspool4.arcor-online.net>
Ben Morrow wrote:
> No. If you must, you can get rid of the method on it's first invocation
> by deleting the glob from the symbol table, but I wouldn't recommend
> doing that.
>
> You could alternatively write your own import method, which removes
> enable_debug from the symbol list and calls Exporter->export_to_level to
> do the actual exporting.
>
Ok. The method I want to get rid of is the export_fail-method (not the local
tied enable_debug var or the symbol) because you can call it on every object
created through this modul. Manipulation of the glob-table is a messy job
and very error prone; and it does not take modul inheritance into account.
The other way around (for inheritance only) I guess would be to write
export_fail-stubs for every single modul (currently about 20) which is also
a messy job :-( - and it would make it worse - because then every modul
would need to have an export_fail method which is completely unneccessary
for the object stuff.
Somehow I was hoping to scope the usage to a BEGIN{} block, so it will
invoked only once and then goes out of scope. The real annoying thing is
that the objects itself have debugging capability for their state and
contents whereas the debugging I reffered to is to trace the methods in a
certain module itself and I need this functionallity because of the very
nature of frameworks and their deep nested calling stack.
To use the export_to_level method isn't an option so far to me because I do
not know where to export; a caller based reference doesn't work all the
time, so I have to inspect @ISA to find the modul where to export to.
It seems a long way to go und feels frustrating.
Do you have any knowlege about fitting cpan modules or maybe
references/links where I can search for.
Thanx for your help.
Andreas
> Ben
EDIT: Maybe I am thinking in the wrong direction! When is the export_fail
method called? Before or after any BEGIN-block? Or is there any run-state
that can be called right after export_fail (as hook for example)?
------------------------------
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 3996
***************************************
