I do not have the up to date skill set to do quite a lot of what you
suggest. I'm much more an applications programmer than a perl
maintainer. I too have provided code for free, but I fail to see the substance in the point you are making. Perhaps the principle reward for
programming (cooking, writing, painting, making music) is an audience, an
appreciative audience. <br><br>The oppotunity for a larger appreciative audience is certainly lost. By far the most people who have S:S on their computers who have tried to use it must just think it is rubbish. The only widely visible versions of S:S do not work. Why this is a matter of indifference to those involved in S:S escapes me. Could it be (mischievous quetion warning) that some would rather be in charge of something small and seemingly broken than be swept aside in the stampede of eager users turned maintainers?<br>
<br>
One of the things that you think we should do, encouraging distro
maintainers to include later versions of SQL::Statement, is best done
by allowing me to post a critical bug at CPAN against the version of
SQL::Statement they all include in their distro's. That would flag the issue to them. I ask you to intercede and to ask Jens to leave my bug report alone, if he won't address it.<br>
<br>
You *do* have the environment available to run my test code. It's very
short and sweet. Please do so, it's attached to the bug report.<br>
<br>
Paul Beardsell<br>Paul@Beardsell.com<br><br><div class="gmail_quote">2009/10/26 H.Merijn Brand <span dir="ltr"><<a href="mailto:h.m.brand@xs4all.nl">h.m.brand@xs4all.nl</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 26 Oct 2009 09:05:01 +0000, Paul Beardsell <paul@Beardsell.com><br>
wrote:<br>
<div class="im"><br>
> Please see sql-statement bug 50788 which<br>
> shows several versions of SQL::Statement to be<br>
> unusable. E.g. version 1.15. It is this version<br>
> of SQL::Statement which exists in many GNU/Linux<br>
> distributions including Debian oldstable, stable and<br>
> testing (and derivatives); Hardy, Intrepid, Jaunty<br>
> and Karmic (i.e. all recent and current and the<br>
> forthcoming releases of) Ubuntu (and derivatives);<br>
> the more recent releases of Redhat (and derivatives)<br>
> and Suse (and derivatives).<br>
<br>
</div>SQL::Statement 1.15 is dead. Dead as a doornail, and will not be<br>
referred to for fixes. Forget *anything* below 1.22 unless you can<br>
prove something still worked in 1.15 and does not in 1.22 and you<br>
have both code and data to show us why.<br>
<br>
If you tell the module maintainers that the distributions you mention<br>
do not update to more recent versions of your favourite modules,<br>
contact the distribution managers to update their modules. We, as<br>
module authors, already fixed things, and we certainly do not control<br>
the behaviour of those that make distribution updates available.<br>
<br>
Sorry. You cannot blame us.<br>
<br>
OpenSuSE indeed still ships perl-SQL-Statement-1.15-1.72, but it is not<br>
up to us to *force* them to make the decision to replace that with what<br>
we already fixed. We should not be your target of complaint!<br>
<br>
<br>
I personally use SQL::Statement-1.22 + DBD::CSV-0.25 on<br>
DBI-1.609 on a *DAILY* basis in *PRODUCTION* code for<br>
converting CSV to Postgres. So statements as "unusable"<br>
do not apply. BTW I am on OpenSUSE 11.0 and 11.1, but for<br>
the reasons you mention, I never use system perl (neither<br>
on other distributions of *nix like HP-UX or AIX)<br>
<br>
$ perl -MV=DBI,DBD::CSV,SQL::Statement<br>
DBI<br>
/pro/lib/perl5/site_perl/5.10.1/x86_64-linux/DBI.pm: 1.609<br>
DBD::CSV<br>
/pro/lib/perl5/site_perl/5.10.1/DBD/CSV.pm: 0.25<br>
SQL::Statement<br>
/pro/lib/perl5/site_perl/5.10.1/SQL/Statement.pm: 1.22<br>
<br>
CSV as a database is not the way to create applications<br>
that need speed or need low memory footprints or need<br>
full ANSI-SQL support. If you need either of those, do<br>
convert CSV to SQLite or postgresql (or another database<br>
of your preference that does support all of your needs).<br>
<br>
In the DBI/DBD world,<br>
* CSV does not support types (beyond NULL, integer and char)<br>
* CSV does not support links (referential integrity)<br>
* CSV does not support speed<br>
* CSV does not support data dictionary persistence<br>
<div class="im"><br>
> The later versions of SQL::Statement are not available<br>
> for ready installation into any of these Linux<br>
<br>
</div>There are a lot of references on the internet on how to install modules<br>
in your *own* userspace that overrule modules in system space<br>
<br>
$PERL5LIB is your friend<br>
<div class="im"><br>
> environments by ordinarily competent Linux users.<br>
<br>
</div>"competent" implies people know how to set a single environment variable<br>
<div class="im"><br>
> Even for the distro maintainers these latest releases<br>
> are very disruptive (ripple on effects etc) to install<br>
> owing to numerous dependencies on very new code.<br>
<br>
</div>so?<br>
<div class="im"><br>
> Similarly older versions of SQL::Statement known not<br>
> to suffer from bug 50788 are also not available for<br>
> anything but very difficult if not nearly impossible<br>
> installation into any recent release of these Linux<br>
> distro. E.g. 0.1020 does not suffer from this bug<br>
> and 0.1020 was std in Debian Woody but Woody is no<br>
> longer readily downloadable.<br>
<br>
</div>We do not refer to anything older than 1.22 thanks<br>
<div class="im"><br>
> Consequently, to all intents and purposes<br>
> SQL::Statement is *dead* in the Linux (distro)<br>
<br>
</div>far from ...<br>
<div class="im"><br>
> world as it can not have any serious use in its<br>
> currently (readily) available incarnations owing to<br>
> the existence of at least one critical bug in S:S.<br>
><br>
> Why? Why is there no usable version of SQL::Statement<br>
> out there for (less-than-uber-techie) (common) Linux<br>
> (distro) users?<br>
<br>
</div>Again, don't ask us, ask the linux distribution people.<br>
<div class="im"><br>
> For a package to be used it must be reliable and<br>
> available.<br>
<br>
</div>From our perspective it is.<br>
<div class="im"><br>
> If(!) there are reliable versions they are not (easily)<br>
> available.<br>
<br>
</div>Not our problem, as we think CPAN *is* easy.<br>
<br>
$ cpan SQL::Statement<br>
<div class="im"><br>
> What a pity! SQL::Statement was a great package<br>
<br>
</div>it still is. Better even, as Jens took over, functionality grew.<br>
<div class="im"><br>
> uniquely allowing SQL to be used on CSV files.<br>
<br>
</div>Better, I worked together with Jens to make SQL::Statement<br>
support the new needs for DBD::CSV so *I* could use it for my daily<br>
work. We will admit there are still a few black spots or minor nags and<br>
inconveniences, but it does meet my needs now.<br>
<br>
The toolchain for DBD::CSV is more complicated than for say DBD::Pg,<br>
but I can say I am proud on what we have achieved. The fact that you<br>
need newer versions of modules than what you have readily available<br>
only proves that we work (very) hard to make it work as it should work.<br>
<div class="im"><br>
> Was. Now it is broken.<br>
<br>
</div>Was. Now it is fixed.<br>
<div class="im"><br>
> The world needs, we need, *I* need SQL on CSV files.<br>
<br>
</div>Then install DBI-1.609 or newer, SQL::Statement 1.22 or newer and<br>
DBD::CSV 0.25 or newer. We cannot help you if you decide to keep living<br>
in the past.<br>
<div class="im"><br>
> I very strongly suggest that one of three things<br>
> be done.<br>
><br>
> (1) If there exists a stable and usable version of<br>
> SQL::Statement after the known-to-be-broken 1.15 then<br>
> this must be pushed at the Linux distro maintainers.<br>
<br>
</div>I urge you to take actions to make this happen!<br>
<div class="im"><br>
> There must be reasons why *no* popular Linux distro<br>
> has accepted any version after 1.15.<br>
<br>
</div>We'd like to know. They never contacted us.<br>
<div class="im"><br>
> I know not what all<br>
> these may be but I suggest but I suggest the<br>
> very recent version 1.22 is very difficult to install<br>
> into a working environment or into current Linux<br>
> distros because of numerous dependencies on some very<br>
> new code. Because 1.22 is difficult to install it<br>
> has practically zero users and I suggest therefore we<br>
> do not actually know for sure it is a good version!<br>
> A backport of a recent S:S version such as 1.22 to<br>
> an earlier Perl environment is needed so that it can<br>
> be installed without having to upgrade much of one's<br>
> whole Perl environment. Then we can get it into the<br>
> distros, and get some users.<br>
<br>
</div>But again, not our problem.<br>
<div class="im"><br>
> *or*<br>
><br>
> (2) Forward-port a known to be good version of<br>
> SQL::Statement such as one of the pre 1.0 versions.<br>
> I can vouch for 0.1020-2 as found in Debian Woody.<br>
<br>
</div>No.<br>
<div class="im"><br>
> *or*<br>
><br>
> (3) Fix 1.15.<br>
<br>
</div>No.<br>
<div class="im"><br>
> OK, so now shoot the messenger. :-)<br>
<br>
</div>Is that an actual option?<br>
<br>
Remember that CPAN is built and maintained by people on a voluntary<br>
basis in our free time (FWIW I quite often would prefer to go skiing<br>
than to maintain Text::CSV_XS). We are not being paid. Neither to code,<br>
nor to fix bugs. If you think you are able to make all of this better,<br>
you should do so by supplying patches. Patches to *recent* versions of<br>
the module. All patches (except maybe for documentation) should be<br>
accompanied by new test cases that provide proof.<br>
<br>
> Paul Beardsell<br>
<font color="#888888"><br>
--<br>
H.Merijn Brand <a href="http://tux.nl" target="_blank">http://tux.nl</a> Perl Monger <a href="http://amsterdam.pm.org/" target="_blank">http://amsterdam.pm.org/</a><br>
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,<br>
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.<br>
<a href="http://mirrors.develooper.com/hpux/" target="_blank">http://mirrors.develooper.com/hpux/</a> <a href="http://www.test-smoke.org/" target="_blank">http://www.test-smoke.org/</a><br>
<a href="http://qa.perl.org" target="_blank">http://qa.perl.org</a> <a href="http://www.goldmark.org/jeff/stupid-disclaimers/" target="_blank">http://www.goldmark.org/jeff/stupid-disclaimers/</a><br>
</font></blockquote></div><br>