lest talk a litle more about directories

[Charlton Wilbur]

RW> ... can laugh about you being so naive to try to 'contribute'
RW> something to 'an open source project' because your solution is
RW> better than the one the Really Important and Well-Connected
RW> Guy[tm] (who - coincidentally - makes a living by offering his
RW> 'superior Perl expertise' to the highest bidder) wrote.

I'm sure hundreds of thousands of lurkers support you in email, but you
sound like a crank and a loon here.

Charlton

 

[Keith Keller]

File:ath happens to be part of the Perl distribution because the guy
who happened to have written it happened to be on a sufficiently
friendly/ familiar footing with the guy (or guys) who made such
descisions at that time, as such things commonly happen in 'open
source land'.

The guy who originally authored the module is no longer the maintainer.

It certainly wasn't ever peer-reviewed by someone with
at least half a clue (eg, the outoging check for 'has another process
created the directory meanwhile is totally useless because said other
process could create it one microsecond after the check) and isn't a
particularly good implementation.

Did you submit a patch to the current maintainer?

If someone else either doesn't think so or
wants to spend some time with researching sensible solutions to a
particular problem, even a problem you really don't care about, it
would be appropriate to let him instead of demanding that he has to
make the same choices you happen to have made (even if you
encompasses the population of all of China) because you happen to
have made them.

I am not demanding that George use File:ath. I am suggesting that he
not suggest that others use his code, and instead offer patches to
File:ath, where much larger numbers of programmers can obtain it, and
where it can be maintained in a more, uh, maintainable fashion.

Do you have good, verifiable reason to think that these patches, if they
passed tests, would not be accepted? I strongly suspect not.

--keith

 

[Rainer Weikusat]

[...]

It certainly wasn't ever peer-reviewed by someone with
at least half a clue (eg, the outoging check for 'has another process
created the directory meanwhile is totally useless because said other
process could create it one microsecond after the check) and isn't a
particularly good implementation.

Did you submit a patch to the current maintainer?

I don't use this code. Hence, I don't modify it, either. And the only
sensible modification here would be a wholesale rewrite to get rid of
the recursion. Assuming I did that for some other reason than
'performing an experiment whose outcome interested me' (like the two
subroutines I posted in a related threat), I'd probably just use the
result. Interactions with open source projects tend to be longuish,
flame-happy (since you basically 'appear on the scene' telling one of
the established bigwigs that he did something wrong) and lead nowhere
(eg, I have DBD:g with fully-working support for asynchronous
interactions with Postgres. I tried to 'submit' some preliminary
patches to 'the maintainer' and he even accepted some of. As soon as it got
into 'I changed this because it was stupidly written' [in a very
slight way], that came to an end. Considering that I'm usually
strongly urged to spend as little time as possible on each individual
work task, why would I cleanup to async stuff to a degree where it
could be published, given that I know that it works, so that that can
be shelved [or - at best - rewritten by one of the 'core guys'] as
well?)

I am not demanding that George use File:ath. I am suggesting that he
not suggest that others use his code,

He didn't do that. He published some musings about 'directory creation'
which included two routines actually doing this.

and instead offer patches to File:ath,
[...]

Do you have good, verifiable reason to think that these patches, if they
passed tests, would not be accepted?

To be honest: So far, I submitted a single patch to something
maintained as part of perl and that got accepted, it was even
preferred over a similar one written by someone else. But that
happened indirectly through the Debian BTS. OTOH, I remember (all too
clearly) a period of time where I was trying to live on EUR 300/ month
(fixed rent cost of EUR 210) while expected to work. This was
ultimatively caused (or at least stimulated) by colliding with some
'Perl community' people who pulled some strings after drawing me into
a series of heated exchanges, something I absolutely couldn't deal with
ten years ago, on USENET. It is not difficult to find some of the
names in various 'Perl core' stuff and this is an experience I'm not
keen to repeat, especially considering that what people believe about
other people never changes, no matter how hard observable reality
contradicts it.

Consequently, I wouldn't want to try and would advise others to treat
very carefully in this area.

 

[Rainer Weikusat]

perl seems a little schizophrenic in this respect since it both
includes File::Spec which provided 'portable pathname manipulation' in
an IMHO sensible way[*] by delegateing all actual work to a
system-specific implementation module and File::Basename (used by
File:ath) which employs if - elsif - else-cascades to select the
code to execute for a particular system at runtime.

Yes, I agree, it's a bit peculiar. However, they both work, and have
been thoroughly tested on many systems over many years, so I suppose
noone thinks it's worth changing them.

File::Basename consists of a system-dependant part, namely, the regexes
& associated handling code dealing with the actual pathnames, and the
'pure Perl' switching logic. And I doubt that there was ever a perl
port where if - elsif - elsif - else didn't work because of inherent
'portability problems' in this Perl code. Consequently, the 'tested on
many systems' part doesn't really apply to that.

[*] Mostly. It still relies on a hardcoded 'system list' in order to
determine which module to load,

What else would you do?

uses @ISA for forwarding calls to 'implementation modules' and loads
these via require. Ideally, it should select a module based on 'system
name' only (possibly with an override facility)

System names are too whimsical to use like that; they need to be
normalised to something sensible. That's all the list of 'known systems'
is doing.

There are two lists of 'known systems', one in Basename.pm and one in
Spec.pm and they don't only differ but even treat the same system in
different ways, at least seemingly. I wouldn't be suprised if there
some more different 'lists of known systems' (handling seemingly
identical systems in different ways) in the Perl core and I'm certain
that there will be n more (with n possibly being large) 'different
lists of known systems' (handling ...) all over CPAN. That's an
unmaintainable mess and bound to cause problems (eg, will someone
fixing a bug in File::Spec always remember or even know that
File::Basename needs to be changed as well and how much additional
work is it to make a semantically equivalent change to both which
correct within the constraints of either?).

Also, I wouldn't be surprised when people who actually need 'portable
filename manipulation' would usually end up trying n different modules
in turn until they found one which works for their problem and that
forget about the issue, IOW, in the end, bugs won't ever or won't
usually get fixed.

[...]

The File::Spec::Functions

[...]

uses

foreach my $meth (@EXPORT, @EXPORT_OK) {
my $sub = File::Spec->can($meth);
no strict 'refs';
*{$meth} = sub {&$sub('File::Spec', @_)};
}

at runtime in order to generate proxy subs. The 'double call' is
necessary to work around the IMHO totally weird descision to use
'method calls' for this in the first place (explanation why this could
make any sense greatly apprecicated) ...

The method implementation is indeed bizarre. I think the only reason it
works like that is that the module was written in the very early days of
Perl OO, before any sort of best practices had emerged, and someone
thought it would be a clever idea. (IMHO the same applies to Exporter
and Dynaloader, neither of which ought to use inheritance. AutoLoader
used to do the same, apparently, but has been changed.)

OTOH, does it matter? The code's there, it's tested, it works, and it's
reliable.

It matters to me: I wouldn't mind using 'portable pathname
manipulation code' if Perl offered a sensible implementation. Since it
IMHO doesn't, I'll stick to using 'regexes for UNIX(*)'. That's all I
usually care for and even if I had to support 'weird filesystems', I
would rather lift the filesystem-specific bits from one of the modules
and (in the most 'complicated' case), integrate them with some
'selection logic' which doesn't unduly 'penalize' my code.

If a library 'wants' to be used, it should offer something better than
'this may save you an hour of work' --- 'Oh me Gawd, how can I get
this done at all!" is not a universal problem.

 

[George Mpouras]

Στις 29/7/2013 11:55, ο/η Rainer Weikusat έγÏαψε:

[...]

It certainly wasn't ever peer-reviewed by someone with
at least half a clue (eg, the outoging check for 'has another process
created the directory meanwhile is totally useless because said other
process could create it one microsecond after the check) and isn't a
particularly good implementation.

Did you submit a patch to the current maintainer?

I don't use this code. Hence, I don't modify it, either. And the only
sensible modification here would be a wholesale rewrite to get rid of
the recursion. Assuming I did that for some other reason than
'performing an experiment whose outcome interested me' (like the two
subroutines I posted in a related threat), I'd probably just use the
result. Interactions with open source projects tend to be longuish,
flame-happy (since you basically 'appear on the scene' telling one of
the established bigwigs that he did something wrong) and lead nowhere
(eg, I have DBD:g with fully-working support for asynchronous
interactions with Postgres. I tried to 'submit' some preliminary
patches to 'the maintainer' and he even accepted some of. As soon as it got
into 'I changed this because it was stupidly written' [in a very
slight way], that came to an end. Considering that I'm usually
strongly urged to spend as little time as possible on each individual
work task, why would I cleanup to async stuff to a degree where it
could be published, given that I know that it works, so that that can
be shelved [or - at best - rewritten by one of the 'core guys'] as
well?)

I am not demanding that George use File:ath. I am suggesting that he
not suggest that others use his code,

He didn't do that. He published some musings about 'directory creation'
which included two routines actually doing this.

and instead offer patches to File:ath,
[...]

Do you have good, verifiable reason to think that these patches, if they
passed tests, would not be accepted?

To be honest: So far, I submitted a single patch to something
maintained as part of perl and that got accepted, it was even
preferred over a similar one written by someone else. But that
happened indirectly through the Debian BTS. OTOH, I remember (all too
clearly) a period of time where I was trying to live on EUR 300/ month
(fixed rent cost of EUR 210) while expected to work. This was
ultimatively caused (or at least stimulated) by colliding with some
'Perl community' people who pulled some strings after drawing me into
a series of heated exchanges, something I absolutely couldn't deal with
ten years ago, on USENET. It is not difficult to find some of the
names in various 'Perl core' stuff and this is an experience I'm not
keen to repeat, especially considering that what people believe about
other people never changes, no matter how hard observable reality
contradicts it.

Consequently, I wouldn't want to try and would advise others to treat
very carefully in this area.

I like your thinking Rainer. For every day work I have to solve
difficult practical problems, so in order to catch the deadlines I do
not reinvent the wheel and use as match modules I can, in order to be as
effective/fast is possible.

When I have some time at work, I like to think about some points that
looks interesting, and I had the (wrong) idea that here is a good place
for discussion.

As many guys have put me in their blacklist , maybe I will not heart
them to talk a little more.

the record insertion on a data structure is an interesting issue in
general. The dir creation, is the same problem of how to make the ~~
operator faster.
I mean what Perl is doing at "... if ('foo' ~~ @Array') { .... "


When we are talking about directories, the upper directory of course
must exist. So the problem is not symmetrical . I mean there is greater
probability for a directory to exist at the left half than the right. So
there is a way to make the algorithm even faster.

Thats all ... only some ideas; I do not want to patch any module either.

 

[Charlton Wilbur]

RW> Interactions with open source projects tend to be longuish,
RW> flame-happy (since you basically 'appear on the scene' telling
RW> one of the established bigwigs that he did something wrong) and
RW> lead nowhere (eg, I have DBD:g with fully-working support for
RW> asynchronous interactions with Postgres. I tried to 'submit'
RW> some preliminary patches to 'the maintainer' and he even
RW> accepted some of. As soon as it got into 'I changed this because
RW> it was stupidly written' [in a very slight way], that came to an
RW> end.

If you enter into communication assuming it will go badly, it usually
does; if you enter into communication assuming it will go well, it
usually does. I tend to be fairly direct and frequently abrasive, and I
haven't had anywhere near the level of difficulty you report.

And I am far from an "established bigwig"; for roughly the past year,
Perl has been a hobby interest of mine rather than a profession, due to
many tech companies being trend-following sheep.

Charlton