Pie-thon - b2.py is running
And as promised it runs fast. More then double the speed of Python - with an unoptimized Parrot build ;) leo
xx and re-running
Recently on perlmonks, at http://perlmonks.org/index.pl?node_id=375255,
someone (DWS, actually) brought up the common error of expecting x (in
particular, listy x, which is xx in perl6) to not create aliases. What
he was doing in particular, I don't have any expectation of making it
work, but what about the also-common problem of C< @randoms = (int rand
100) xx 100 >? In perl5, this picks one random integer between 0 and
99, and copies it 100 times -- not what was intended. The best way to
do this is C< my @randoms = map {int rand 100} 0..100; >, which is
rather yucky -- conceptually, you aren't trying to transform one list
into another. OTOH, C< my @randoms; push @randoms, int rand 100 for
0..100 > is even yuckier.
Perhaps if the LHS of a xx operator is a closure, it should run the
closure each time around... or perhaps there should be an xxx operator.
(Both suggestions from BrowserUk's reply,
http://perlmonks.org/index.pl?node_id=375344). The former raises the
question of what you do if you really want to repeat a coderef, and the
later raises the possibly of being blocked (really), and starts to
become confusing -- the difference between x and xx is sensical -- the
former repeats one thing, the later many... but what's the reasoning for
xxx, other then that it's like xx? How will users be able to remember
which is which?
-=- James Mastros,
theorbtwo
Re: Testing Database Schema
Tony Bowden wrote: We have an in-house procedure that says that the SQL definition for a table should be included in the __DATA__ section of the class that represents it (we're using Class::DBI), and is to be treated as the definitive version of the schema. [cut] We're having too much difficulty thinking of a sane way to do this, however. For now it just needs to cope with MySQL. But MySQL has an interesting 'feature' where the CREATE TABLE schema you feed it, isn't the same as the SHOW CREATE TABLE schema you get back - as it fills in lots of extra defaults, quotes column names etc. Change the procedure to require the bit after __DATA__ to match what mysql gives you back? This is actually better then what you do anyway, as what mysql gives you is significantly more detailed. Contrarywise, parse the SQL at the bottom of the file, treat it as a bunch of assertations, and attempt to verify each of them using non-modifying SQL and/or using DBI's standard introspection mechinsimis. (Hint: One way to get a list of columns in a table is to select * limit 1 from it, and inspect what you get back.) -=- James Mastros
Re: :)
On Sat, Jul 17, 2004 at 06:23:50PM -0400, Austin Hastings wrote: > > On Saturday, 17 July, 2004 01:53 Sat, Jul 17, 2004, Juerd wrote: > > > > Do we have a :) operator yet? > > It's an adverbial modifier on the core expression type. Does > nothing, but it acts as a line terminator when nothing but > whitespace separates it from EOL. Please tell me you're serious. --Dks
Re: Why do users need FileHandles?
On Sun, Jul 18, 2004 at 05:36:58PM -0700, Dave Whipp wrote:
> truncate Vs append would be infered from usage (assign => truncate). One
> might be able to infer read Vs write in a similar way -- open the file based
> on the first access; re-open it (behind the scenes) if we write it after
> reading it.
You might run into issues if the user starts doing seeks before
writing...although maybe not, since that just means that we need to
(behind the scenes) remember the current location of the seek pointer
when re-opening.
Exclusivity issue: when it re-opens, should it lock before opening?
Race condition: what if something deletes the file between the moment
that perl closes the file and the moment that it re-opens it? Is
there a cross-platform way to do an atomic reopen?
FWIW, although I'm not sure it will work in practice, I really like
this idea of eliminating FileHandles as a user-level object.
> my Str $text is file("foo.txt") does no_follow_symlink does no_create;
>
> Do we have an antonym for C?
How about 'no'?
my Str $text is file("foo.txt") no follow_symlink no create;
Other options (not all good):
without
not
dont
doesnt
--Dks
Re: Why do users need FileHandles?
On Sun, Jul 18, 2004 at 08:39:09PM -0500, Rod Adams wrote:
> Case 1:
> So I wanted to do a read/write scan, so I create my TextFile, start
> reading in data, so the file is opened for reading. Then, I come to the
> part where I want to update something, so I do a write command. Suddenly
> the file has to be closed, and then re-opened for read and write. And
> all my buffers, file pointers and the like are reset, (though curable
> with very careful planning), leaving me in a bad spot. Better if I could
> just declare the file open for read and write at open time.
>
> Case 2:
> I meant to use some critical data file in read-only mode, and accidently
> use a write command somewhere I didn't mean to, and silently just
> clobbered /etc/passwd. Better if I could have just opened the file read
> only, and trigger an error on the write command.
>
> What design philosophy would you envision TextFile taking to handle both
> these cases in a coherent fashion?
my $default is TextFile("/tmp/foo");
my $rw is TextFile("/tmp/foo")is rw;
my $ro is TextFile("/etc/passwd") is const;
$default will have the semantics that Dave has been
describing--initially opened read-only, then re-opened as r/w if you
write to it.
$rw is explicitly r/w. Attempts to write to it succeed, and do not
require an implicit re-open.
$ro is explicitly ro. Attempts to write to it fail, and do not
perform an implicit re-open.
Given the above code, here is some usage:
print $ro.readline(); # Prints first line
$ro = "boom!";# THROWS AN ERROR
(assume error was trapped somehow)
# Print file, inefficiently
print $default.readline for 1..$default.lines;
# Append a line
$rw .= "an additional line\n";
# New line is visible through $rw
print $rw.lines[-1]; # (*)
# last line not yet visible through $default because it was
# added by external handle--just like in a tail -f, we
# need to move file pointer manually
$default.seek(File.current_pos);
# Can't re-open for write mode, since another handle
# already has the write-lock. Throw error to that effect.
$default = "oops, this doesn't work";
(*) The .lines[-1] semantic is feasible if we are willing to tolerate
very slow performance (at least the first time; it could cache the
locations of $/ after scanning and dump the cache if $/ changes), the
fact that it wouldn't work on all files (/dev/null, /dev/zero, etc),
and a few other issues.
> I don't think anyone (read: Larry) has declared exactly what the
> capabilities of the default file handle object are yet. It seems me that
> you could very well get what you want.
True on both counts.
--Dks
Script to find Module Dependency Test Results...
I have a prototype Perl script that will determine the dependencies of a given
CPAN distribution, and then check CPAN Testers for any failure reports of that
distro or dependent distros for a given platform.
I would like to work with other people to turn this into something of use to
the community, at the very least a module but ideally something that could be
integrated with one of the CPAN-related web sites. (I'm also starting
graduate school in the fall and looking for people to take this idea and run
with it, as I won't have as much time.)
For an example of what this does, if I ask it to search for dependencies for
the disto 'Pixie', it tells me the following:
Pixie-2.06:
DBIx-AnyDBD-2.01: {}
Data-UUID-0.11: {}
Test-Class-0.03:
Test-Differences-0.47:
Text-Diff-0.35:
Algorithm-Diff-1.15: {}
Test-Exception-0.15:
Sub-Uplevel-0.09: {}
Test-Tester-0.09: {}
Test-Tester-0.09: {}
for Windows machines, it also tells me this:
Algorithm-Diff-1.15: []
DBIx-AnyDBD-2.01:
- action: FAIL
distversion: DBIx-AnyDBD-2.01
id: 79987
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/79987
version: 2.01
Data-UUID-0.11:
- action: FAIL
distversion: Data-UUID-0.11
id: 145033
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/145033
version: 0.11
- action: FAIL
distversion: Data-UUID-0.11
id: 146960
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/146960
version: 0.11
Pixie-2.06: ~
Sub-Uplevel-0.09: []
Test-Class-0.03:
- action: FAIL
distversion: Test-Class-0.03
id: 144608
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/144608
version: 0.03
Test-Differences-0.47: []
Test-Exception-0.15: []
Test-Tester-0.09: []
Text-Diff-0.35: []
In other words, there are no test reports for Windows users of Pixie, but
that's likely because they can't get several distros that Pixie requires to
work on Windows (Test-Class, DBIx-AnyDBD-2.01, and Data-UUID-0.11).
This information would be of use to various quality-assurance types, as well
as the module author. It's probably of use to module users too.
Re: Why do users need FileHandles?
On Tue, 20 Jul 2004 07.25, Austin Hastings wrote:
> --- Rod Adams <[EMAIL PROTECTED]> wrote:
> > If I cannot open a file for writing (permissions, out of space,
> > write locked, etc), I want to know the instant I attempt to open it
> > as such, _not_ when I later attempt to write to it. Having all
> > these features available to open as arguements seems a much better
> > idea to me. It's "Open a file with these specifications", not "Open
> > a file, and then apply these specifications to it".
>
> But why? Do you really open files and then perform an hour of work
> before attempting to use them? I'll argue that's not the normal case;
> rather, the normal case is something like
>
> open or die ...
> other_stuff()
> while (...) {
> print ...
> }
> close
>
> and the intervening delay (other_stuff) is negligible in wall-clock
> terms: when a failure occurs, the user hears about it immediately.
The issue isn't about how long it takes other_stuff() to run. The issue is
whether other_stuff does something irrevocable that shouldn't have been done
if the file couldn't be opened.
Imagine a double-entry bookkeeping system that needs to atomically update two
files at once. You don't want to discover that one file is inaccessible
after you've already written the transaction to the other file. You'd end up
circumventing the DWIMmery by writing empty strings to the files just to make
sure they exist:
$handle1 = open "file1";
$handle2 = open "file2";
print $handle1: ""; # Did it really open?
print $handle2: "transaction 2" or die;
print $handle1: "transaction 1" or die;
I contend that however many examples you could come up with that make
"open-on-write" look neat, it's possible to contrive just as many examples
that make "open-on-write" look awkward. Which, IMHO, is a perfect argument
for putting this functionality into a library where those who want to use it,
will.
It's probably time to leave all of this up to @Larry to concoct something that
everyone's happy with.
--
Debbie Pickett
http://www.csse.monash.edu.au/~debbiep
[EMAIL PROTECTED]
Re: Why do users need FileHandles?
On Mon, Jul 19, 2004 at 03:37:12PM -0500, Rod Adams wrote: > I think part of the "mental jam" (at least with me), is that the > read/write, exclusive, etc, are very critical to the act of opening the > file, not only an after the fact restriction on what I can do later. If > I cannot open a file for writing (permissions, out of space, write > locked, etc), I want to know the instant I attempt to open it as such, > _not_ when I later attempt to write to it. Having all these features > available to open as arguements seems a much better idea to me. It's > "Open a file with these specifications", not "Open a file, and then > apply these specifications to it". > > I do admit there is merit to your abstraction system, but IMO, it > belongs in a library. > > -- Rod Adams First, why are they incompatible? Offer both, let TIMTOWTDI sort it out. Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. --Dks
Re: Testing Database Schema
[EMAIL PROTECTED] (Tony Bowden) writes: [...] > > > lots of SQL to a common format. Both seem much too cumbersome, however. > > > Anyone have any brighter ideas? > > Don't use a temporary database, just a temporary table. > > Surely that's more work? That depends on how you open your databases and how much trouble it is to use another database compared to munging the table name. :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: push with lazy lists
On Fri, 2004-07-16 at 12:10 -0400, Jonadab the Unsightly One wrote: > Austin Hastings <[EMAIL PROTECTED]> writes: > > > Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which > > collapses to the range [Inf, Inf). > > It's not that simple. By that reasoning, 10% of all numbers in > [0,Inf) would be in [Inf/10,Inf), also reducing to the range > [Inf,Inf). As a lurking mathematician on the list, I thought that it might be insightful to offer some comments at this point. Apologies in advance if I'm repeating something that happened at the beginning of the thread. Once you start talking about non-finite sets of numbers, percentages start to become amusingly meaningless. Classic examples: the set of integers and the set of positive integers have the same size; there are as many points on the perimeter of a square as there are in its interior. For many of the same underlying reasons, it's quite impossible to have a flat random probability distribution across the integers (or reals, for that matter). Hardware people are lazy, and have given us only a finite number of bits to work with. So, that gives us an excuse to be lazy as well in the non-Bignum case: if the list is known in advance to be infinite, then we just take C to be a flat distribution over the range of the double, or whatever Perl is using for such things. It's not like people will be able to access any other elements in the array ;-). If the array size is unknown, and the programmer doesn't want to risk accidental heat death, I see no problem with C for those cases; i.e., if the size of the array appears to be larger than abs($lower) and abs($upper), then we fall back to using those limits. People using C with Bignums deserve to be spanked. :) A graceful solution in that case would be to interpret that as C, or better yet, C, since that roughly reflects what humans will do when you ask them for a random real number (mouth off some random digits and multiply by a "random" power of 10). Besides, there's always C if people can't stomach C returning negative numbers. If they're using Bignums, they also ought to be savvy enough to figure out some other distribution if desired.* Peter *If people think C should only return positive things, I'm fine with that. It's just annoying to have to type C< * (int(rand (2))*2-1)>.
Re: Exit status code from Test::More might go away
On Jul 19, 2004, at 8:09 AM, Michael G Schwern wrote: The exit code information adds unnecessary extra information to an already crowded set of diagnostics. Observe the difference. Oh, yeah, it's nice that you lose the extra two lines that I, for one, never paid attention to, anyway. Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: [OT] Re: Single Sign-on Re: Perl Passport?
[EMAIL PROTECTED] (Darren Chamberlain) writes: > > As I figured it out neither... > > > > Reason: auth.perl.org is part of the SSO (Single Sign-on) that was > > created especially for the perl.org domain and its sub-domains. > > > > As far as I know it isn't a service that is publicly available. And I > > also don't think that Ask or Robert will give away the source, as it > > is build specifically for perl.org and it's setup. > > Is that not http://svn.develooper.com/combust/auth/trunk/ ? You need a > perl.org account to access it. (you can also use guest/guest). The version in that directory is the new version I've been working on. Hopefully we'll switch auth.perl.org over to use it not long after OSCON. Some of the fun things with the new system is that it supports sites on other domains properly, doesn't use a "universal id" and I plan to make it support multiple authentication services. The client library (perl only for now) is at: http://search.cpan.org/dist/Sau-Client/ There are some interesting links at the bottom of http://logintest.perl.org/doc/design_notes.html - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: scalar subscripting
Hello,
I wish to be consistent with shall, so `.' is literal dot in double
strings. I prefer "$file.ext" or "${file}.ext".
For method calls ``$()'' could be used: "$($foo.bar)".
Perhaps, what does "${foo.bar}" mean?
Best regards
Hans
Re: Testing Database Schema
[EMAIL PROTECTED] (Tony Bowden) writes: [...] > The two "best" ideas we've had so far are to either run the SQL in the > code against a temporary database, and then compare both SHOW CREATE > TABLE outputs, or to use something like SQL::Translator to convert both > lots of SQL to a common format. Both seem much too cumbersome, however. > > Anyone have any brighter ideas? One variation that might work (and if it does, it'd also work on other databases) would be to use DB::Introspector. http://search.cpan.org/dist/DB-Introspector/ - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Script to find Module Dependency Test Results...
I have a prototype Perl script that will determine the dependencies of a given
CPAN distribution, and then check CPAN Testers for any failure reports of that
distro or dependent distros for a given platform.
I would like to work with other people to turn this into something of use to
the community, at the very least a module but ideally something that could be
integrated with one of the CPAN-related web sites. (I'm also starting
graduate school in the fall and looking for people to take this idea and run
with it, as I won't have as much time.)
For an example of what this does, if I ask it to search for dependencies for
the disto 'Pixie', it tells me the following:
Pixie-2.06:
DBIx-AnyDBD-2.01: {}
Data-UUID-0.11: {}
Test-Class-0.03:
Test-Differences-0.47:
Text-Diff-0.35:
Algorithm-Diff-1.15: {}
Test-Exception-0.15:
Sub-Uplevel-0.09: {}
Test-Tester-0.09: {}
Test-Tester-0.09: {}
for Windows machines, it also tells me this:
Algorithm-Diff-1.15: []
DBIx-AnyDBD-2.01:
- action: FAIL
distversion: DBIx-AnyDBD-2.01
id: 79987
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/79987
version: 2.01
Data-UUID-0.11:
- action: FAIL
distversion: Data-UUID-0.11
id: 145033
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/145033
version: 0.11
- action: FAIL
distversion: Data-UUID-0.11
id: 146960
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/146960
version: 0.11
Pixie-2.06: ~
Sub-Uplevel-0.09: []
Test-Class-0.03:
- action: FAIL
distversion: Test-Class-0.03
id: 144608
platform: MSWin32-x86-multi-thread
report_url: |-
http://nntp.x.perl.org/group/perl.cpan.testers/144608
version: 0.03
Test-Differences-0.47: []
Test-Exception-0.15: []
Test-Tester-0.09: []
Text-Diff-0.35: []
In other words, there are no test reports for Windows users of Pixie, but
that's likely because they can't get several distros that Pixie requires to
work on Windows (Test-Class, DBIx-AnyDBD-2.01, and Data-UUID-0.11).
This information would be of use to various quality-assurance types, as well
as the module author. It's probably of use to module users too.
Re: String interpolation
Larry Wall wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as "%10.5d"}
This is close to the new form() syntax as well, which could be
considered a plus. I for one won't complain about adding the good things
from Ruby back in to Perl.
matt
Note that this not only fixes the Perl 6 "% in sprintf" issue, but
also the Perl 5 "@ in email address" issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables "{.foo}"
where we would have had a lot of "$_.foo", and I think that's an
improvement in readability, at least for people who believe in topics.
Larry
Re: is_deeply and overloaded obejcts
On Wed, 21 Jul 2004 14:51:13 -0400, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > I was going nuts recently, trying to figure out why I couldn't use > is_deeply to compare objects. I've finally determined that it's only an > issue (as far as I see) when comparing objects that overload > dereferencing to their implementation type. > > The attached code should fail all three tests; at no point are the two > structures identical. Instead, the third test -- when the structures > are blessed into an implementation-type overloaded class -- passes. > > This should be simple-ish to fix, I'd think. > > 1. two objects are different if their implementation types differ > 2. two objects are different if their blessed-into-temp-class structures >differ > 3. otherwise two objects are the same > > So, given two Garbage::Overloaded=HASH objects, we'd bless them into > Test::More::TempClass and then compare those. > > Thoughts? Something similar to this came up before. The upshot is that I reaffirmed the implicit choices made in is_deeply's design: It does not attempt to pierce overloading. Originally this came up in the context of trying to compare Class::DBI objects which overload stringification. Given that choice, obj_deep.t is working correctly. The choice was made to preserve the encapsulation that overloading gives. A clear example is date objects. A function which returns a date as a string and a date as an overloaded date object should remain indistinguishable. I felt it was more important to preserve this important aspect of blackbox testing than the glassbox technique of examining an object's internals. There are two ways around this. Supply a private _guts() method to get at the object's internals or use the much more flexible Test::Deep. I'll make a note to clarify the overloading situation in the docs.
Re: String interpolation
Larry Wall <[EMAIL PROTECTED]> writes:
> : my $d="a";
> : print "--$d--{my $d = "b" }--$d--\n";
>
> Yes, that is correct.
I'm afraid things like this will keep many popular editors and IDEs
from implementing perl6 support...
-- Johan
Re: String interpolation
Matt Diephouse skribis 2004-07-20 20:06 (-0400): > This is close to the new form() syntax as well, which could be > considered a plus. I for one won't complain about adding the good things > from Ruby back in to Perl. Ehm, no, that means that if you want to interpolate something into the format string, the rest of that string becomes bizarrely unreadable. Juerd
CPANTS (was Re: Script to find Module Dependency Test Results...)
Hi!
On Mon, Jul 19, 2004 at 12:12:39AM -0400, Robert Rothenberg wrote:
> I have a prototype Perl script that will determine the dependencies of a
> given CPAN distribution, and then check CPAN Testers for any failure
> reports of that distro or dependent distros for a given platform.
Sounds a little bit like CPANTS, the CPAN Testing Service. I'll do a talk on
it at YAPC::Europe, so if you're there we could talk about joining forces.
If you're not there, we can use email :-)
One downside of CPANTS is that it cannot actually run code (for various
reasons), so we might not be able to actually work together. But I don't
know how your script is working, so...
BTW, I've currently found some time to do some work on CPANTS. It's not
ready for release, but interested parties can take a look at
http://svn.zsi.at:1000/repos/Module-CPANTS-Generator/trunk/
But beware: docs are missing and/or false, so it might be better to wait a
little bit...
Just now I'm generating stats, which will probably take some time to complete.
I'll post links to results as soon as they are available.
As I've got some time right now, I'll post a short overview of how CPANTS is
working:
*) fetch all dist from CPAN using CPANPLUS (examples/fetch_cpan.pl)
*) analyse all dists using the generator in Module::CPANTS::Generator::*
by running the C method in the generators.
this step generates a yaml-file for each dist in dir metrics.
(examples/anaylse_dists.pl)
*) calculate kwalitee by looking at the yaml-metrics, adding the kwalitee
infos to the yaml file (examples/calc_basic_kwalitee.pl)
*) generate a SQLite DB from the yaml-metrics (examples/yaml2sqlite.pl)
*) calculate more kwalitee. This time we can use the sqlite-DB do to
cross-referencing. (eg in Generators::Prereq I check if a dist is required
by three or more other dists. If it is, it get's more kwalitee (although
I'm not sure if this is a good metric..))
(examples/calc_complex_kwalitee.pl)
When all is finished there is a yaml file for each dist and a SQLite-DB
containting all the infos in an easy-to-query format.
I've attached the metrics yaml file for Acme::Bleach I generated during
testing...
Feedback/Patches welcome...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
--- #YAML:1.0
dist: Acme-Bleach-1.12
distribution:
dist_without_version: Acme-Bleach
extension: tar.gz
extractable: 1
extracts_nicely: 1
package: Acme-Bleach-1.12.tar.gz
version: 1.12
version_major: 1
version_minor: 12
files:
build_pl: 0
count_bad_permissions: 0
count_dirs: 4
count_files: 19
count_symlinks: 0
list_bad_permissions: ''
list_dirs: demo,lib,lib/Acme,t
list_files: ! >-
Changes,MANIFEST,Makefile.PL,README,demo/demo_DWIM.pl,demo/demo_bleach.pl,demo/demo_bleach_c.pl,demo/demo_bleach_eng.pl,demo/demo_bleach_lisp.pl,demo/demo_bleach_sh.pl,demo/demo_empty.pl,demo/demo_morse.pl,demo/empty,lib/Acme/Bleach.pm,lib/Acme/DWIM.pm,lib/Acme/Morse.pm,t/DWIM.t,t/bleach.t,t/morse.t
list_symlinks: ''
makefile_pl: 1
manifest: 1
meta_yml: 0
ninja: 0
readme: 1
signature: 0
kwalitee:
extracts_nicely: 1
has_buildtool: 1
has_manifest: 1
has_meta_yml: 0
has_readme: 1
has_version: 1
is_prereq: 0
kwalitee: 7
no_pod_errors: 0
no_symlinks: 1
permissions_ok: 1
pod:
errors: 3
release:
date: Tue May 22 02:17:11 2001
epoch: 990490631
size:
packed: 4299
unpacked: 11479
Re: the whole and everything
Larry Wall <[EMAIL PROTECTED]> wrote: > So Evil Larry? suggests that you embed a Python interpreter and hand off > the unsuccessful tests back to Python. :-) Good idea. Here is bx.pir from Evil Leo: $ cat bx.pir .sub main @MAIN .param pmc argv .const string PY = '/usr/local/bin/python -O ' .local pmc pipe .local string cmd .local string file file = argv[1] cmd = PY . file open pipe, cmd, "-|" .local string res lp: read res, pipe, 4096 print res $I0 = length res if $I0 goto lp close pipe .end $ time parrot bx.pir b0.py 3141592653 3141592653 real0m4.677s user0m0.040s sys 0m0.010s Surprise, its equally fast:) > Larry leo
Re: String interpolation
On Tue, 20 Jul 2004, Damian Conway wrote:
> Larry wrote:
>
> > Actually, I've been rethinking this whole mess since last week, and
> > am seriously considering cranking up the Ruby-o-meter here just a tad.
[snip]
> I can't say I'm keen on making {...} special in strings. I felt that the
> $(...) and @(...) were a much cleaner and more general solution. The
> prospect of backslashing every opening brace in every interpolated
> string is not one I relish.
Well, it seems that there's still a big confusion/indecision about the
default behaviour. But then an interesting point, and one that has already
been raised, is that it should be somehow possible to customize string
interpolation bu means of e.g. adverbs (fortunately we don't have "true"
literal strings but rather quote-like operators), attributes and god know
what else!
Now it should be stressed that the problem is twofold here: one aspect is
chosing the "best" default for some hopefully reasonable meaning of "best"
and the other one is providing a "slim" syntax for the alternate
behaviour(s); i.e. IMHO it would be unreasonable to require the users to
type something like
:with_method_interpolation
each time they want it. But maybe certain delimiters for qq may already
provide that... (or would that be a bad idea?)
As a related side note, is it possible to use multi-char delimiters in
Perl6? I mean, a la:
qq<<...>>;
Michele
--
But seriously this (Godwin's law) painting one's rhetorical
opponents as Nazis is an odious and verminous ploy normally used,
as here, to mask the intellectual bankruptcy of one's arguments.
- Robin Chapman in sci.math, "Die Petry, die: was Re: Die Cantor Die"
Re: :)
David Storrs wrote: On Sat, Jul 17, 2004 at 06:23:50PM -0400, Austin Hastings wrote: On Saturday, 17 July, 2004 01:53 Sat, Jul 17, 2004, Juerd wrote: Do we have a :) operator yet? It's an adverbial modifier on the core expression type. Does nothing, but it acts as a line terminator when nothing but whitespace separates it from EOL. Please tell me you're serious. We could mimick XQuery where it is the comment terminator. http://www.w3.org/TR/xquery/#comments -- Robin Berjon
Call To Cygwin Users Everywhere
If you have read any of my previous posts concerning Cygwin - you will agree that it appears to be a strange beast. The problem is that outside of teaching myself Perl a couple of years ago - I don't have any real experience in this arena. I have no idea if things are really this bizarre or if I am just a bumbling idiot. It would be really nice if someone out there could confirm my wife's suspicions (bumbling idiot). Here are some things in no particular order that would be nice to be confirmed: 1. To get ICU to work A: link => 'c++' in config/init/hints/cygwin.pl B: Ensure that the ICU .dlls are executable C: Ensure that the ICU .dlls are in $PATH D: If using ICU < 2.8, needs shared not static in config/gen/icu.pl E: You may need to download msvcr70.dll and follow steps B and C if you are using a pre-built copy F: In general, if you get a "Unable to remap" error about some .dll, then you will need to run the Cygwin rebaseall utility. 2. The following tests fail under JIT for no apparent reason A. t/op/trans_9-12 t/op/trans_17-18 3. Enabling these tests works but are being skipped - I supplied a patch in bug report #29836 A. Extend 12 B. All threads C. All timer (except the two being universally skipped : 2004-05-24) 4. As outlined in bug report #29936, JIT debugging intermittently doesn't work. I have not followed this up since 2004-05-24 and it may no longer be applicable. The odd thing was I could never isolate what ingredient would cause the failure. 5. -mno-accumulate-outgoing-args is NOT required to make JIT work properly. For a few days this was needed but as of 2004-07-22 it appears not to be. 6. If using compiler optimization flag -O2 or -O3 when configuring parrot to build t/op/number_7.pasm will fail I have isolated the test case to the following: abs N0, -1 end where abs N0, 1 end abs N0, 1.0 end abs N0, -1.0 end all work 7. perl Configure.pl --ccflags='-march=pentium4 -O3 -s -funroll-loops -fomit-frame-pointer' --debugging=0 --optimize --icushared='-licuuc -licudt' --icuheaders=/usr/local/include Obviously change your architecture and your ICU flags accordingly - but that makes parrot really fly ;-) Cheers Joshua Gatcomb a.k.a. L~R __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Re: :)
On Thu, 22 Jul 2004, Robin Berjon wrote: > >>>Do we have a :) operator yet? [snip] > We could mimick XQuery where it is the comment terminator. Well, since it's *optimistically* smiling, it could turn off warnings for the statement it refers to. Michele -- > [...] is like requiring to play tennis with a square ball. Which admittedly makes the game more interesting. - Giuseppe "Oblomov" Bilotta in comp.text.tex (edited)
CPANTS preview
Hi!
I ran CPANTS today, you can view results here:
http://cpants.dev.zsi.at/
( or http://test1.dev.zsi.at if DNS isn't updated..)
in /metrics there is a yaml-file for each dist
cpants.db (or cpants.db.gz) is a SQLite DB file
Oh, there might be a bug, because 100 dists didn't get any kwalitee when at
least some of them should...
Max Kwalitee is 10, which is reached by 99 dists.
dist can get kwalitee for:
extracts_nicely (i.e. in a proper subdir, not in current dir)
has_version
no_symlinks
permissions_ok (i.e. all files are read/writable by extracting user)
has_readme
has_manifest
has_meta_yml
has_buildtool (either Makefile.PL or Build.PL)
no_pod_errors
is_prereq (is listed as PREREQ by at least 3 other dists)
sqlite> select kwalitee,count(kwalitee) as cnt from kwalitee group by
kwalitee order by kwalitee;
kwaliteecnt
-- --
0 100
1 1
2 6
3 28
4 80
5 123
6 482
7 1986
8 3433
9 1365
10 99
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
RE: Script to find Module Dependency Test Results...
On 20 July 2004 22:30 Robert Rothenberg wrote: > I have a prototype Perl script that will determine the > dependencies of a given > CPAN distribution, and then check CPAN Testers for any > failure reports of that > distro or dependent distros for a given platform. One thing to remember, is that some tests are also specific to a particular version of Perl. At the moment I am noticing that several modules that I am going through testing, you have already tested, and CPANPLUS thinks that's okay. However, you are testing using 5.8.4, I've got 5.6.1. The two can have entirely different results. Acme, was going to look at this at some point when he had time, so that the versions were more visible on the report summary pages. But at the moment, it's not always guaranteed that the summary is right. There are some reports that we both have completed, and it highlights the differences. Email::Simple [1] is an example. [1] http://testers.cpan.org/show/Email-Simple.html > I would like to work with other people to turn this into > something of use to the community It is a good idea, but it might be better to look at patching CPAN::WWW::Testers [2], rather than creating an extra script/module. [2] http://search.cpan.org/dist/CPAN-WWW-Testers/lib/CPAN/WWW/Testers.pm > This information would be of use to various quality-assurance > types, as well > as the module author. It's probably of use to module users too. As a report maybe unavailable, due to the fact that no-one has got around to testing it, a simple search mechanism (platform/perl version) using your script could generate the current info from the testers.db file. I like the idea, and with the CPANTS work that Thomas is doing this could be very nice. Barbie.
Re: String interpolation
Jonathan Scott Duff wrote: Surely you mean [EMAIL PROTECTED] instead of 0..Inf I think the iterator implicit in array slicing should, and could, be smart enough to return when there's nothing more to iterate. Considering the following code: @foo = (1, 2, 3); @bar = @foo[1..Inf]; @bar should contain (2, 3). the iterator could just throw an X::ENOITEM (or some such) exception after the "3", which (unless catched and rethrowed by a CATCH block, perhaps) will just terminate the iteration. furthermore, something like: @bar[1..Inf] = @foo; should not (DWIMmy) take forever, but just assign (1, 2, 3) to the second, third and fourth element in @bar. on the other hand, this contrasts with the following code: ($x, $y, $z) = (1, 2); which (in Perl5 at least) assigns undef to $z. for orthogonality's sake, the @bar[1..Inf] assignment should then produce an infinite lists of undefs, which doesn't look too practical. so maybe Inf should have a special meaning in array splicing anyway. cheers, Aldo
Re: Testing Database Schema
On Sun, Jul 18, 2004 at 04:49:24PM +0200, James Mastros wrote: > Change the procedure to require the bit after __DATA__ to match what > mysql gives you back? This is actually better then what you do anyway, > as what mysql gives you is significantly more detailed. We considered that, but, amongst other reasons, I'm not convinced enough that MySQL can be relied on to return exactly the same string for every server version of MySQL. > Contrarywise, parse the SQL at the bottom of the file, treat it as a > bunch of assertations, and attempt to verify each of them using > non-modifying SQL and/or using DBI's standard introspection mechinsimis. That sounds like *way* too much work! > (Hint: One way to get a list of columns in a table is to select * limit > 1 from it, and inspect what you get back.) Yeah, I know that, and use it in several places, but it doesn't really give enough detail for what we're doing here. Tony
Re: :)
On Thu, 22 Jul 2004, Michele Dondi wrote: > On Thu, 22 Jul 2004, Robin Berjon wrote: > > > >>>Do we have a :) operator yet? > [snip] > > We could mimick XQuery where it is the comment terminator. > > Well, since it's *optimistically* smiling, it could turn off warnings for > the statement it refers to. Obviously, it's very confident about that code, so it should turn on a maximum level of warnings for that statement (assured that it will pass). The modifier to turn off warnings on a line would be ;), winking at us to let us know it's up to something. -- Adam Lopresto http://cec.wustl.edu/~adam/ Eschew obfuscation!
Is there a tuple? -- WAS: RE: :)
--- "Adam D. Lopresto" <[EMAIL PROTECTED]> wrote:
> The modifier to turn off warnings on a line would be ;), winking at
> us to let us know it's up to something.
I wondered about paren-after-semi, and thought about C. Which
led me to C<@array[a;b;c]>, then to (a;b;c;), which let me to this:
Given that @array[1;2;3] is a multi-dimensional reference, is there a
"tuple" data type/element/constructor?
Can I say, forex,
my $address = tuple(1;3;5);
and then
my $data = @array[$address];
and GWIW?
Also, can I C certain dimensions?
my @ary is dim(3;3;3) is default('.');
my $vct ::= @ary.assuming( .[0;;0] };
$vct[0..2] = 0..2;
@ary.print; # DWIM!
[ . 0 . ]
[ . 1 . ]
[ . 2 . ]
Ignoring the DWIM, how much of that works?
=Austin
Re: CPANTS preview
On Thu, Jul 22, 2004 at 04:28:08PM +0200, Thomas Klausner wrote: > Hi! > > I ran CPANTS today, you can view results here: Oooh. Nice > http://cpants.dev.zsi.at/ > ( or http://test1.dev.zsi.at if DNS isn't updated..) > > in /metrics there is a yaml-file for each dist > cpants.db (or cpants.db.gz) is a SQLite DB file > > Oh, there might be a bug, because 100 dists didn't get any kwalitee when at > least some of them should... > > Max Kwalitee is 10, which is reached by 99 dists. Will it go up to eleven soon? :-) > is_prereq (is listed as PREREQ by at least 3 other dists) Is it possible to get the lists of prereqs for each module, so as to build a citation index? (without the need to do all the messy downloading or parsing - being lazy I'd like to leave that to you) Or should I download the generator and run it myself? Nicholas Clark
Re: Why do users need FileHandles?
"David Storrs" <[EMAIL PROTECTED]> wrote (apparently may days ago): > Race condition: what if something deletes the file between the moment > that perl closes the file and the moment that it re-opens it? Is > there a cross-platform way to do an atomic reopen? I'm not sure if you need to close it before you reopen it. You can usually open the file a second time before closing it. (the only issue would be if you were using mandatory locks, in which case you're probably a power-user using the FileHandle module, anyway). I don't know about the cross-platform aspect, but a similar scenario is that the file changes on disk while we've using it. In most modern editors, the user is asked: "file changed on disk: reload file? (Y/N)" when this happens. I'd like to think that we could arrange for an exception to be thrown (resumable, of course) if this happens when we've mapped a file into an object. Dave.
Re: CPANTS preview
Hi!
On Thu, Jul 22, 2004 at 05:25:38PM +0100, Nicholas Clark wrote:
> > Max Kwalitee is 10, which is reached by 99 dists.
>
> Will it go up to eleven soon? :-)
as I'm planning to go on vacation next week, probably not...
> > is_prereq (is listed as PREREQ by at least 3 other dists)
>
> Is it possible to get the lists of prereqs for each module, so as to build
> a citation index? (without the need to do all the messy downloading or
> parsing - being lazy I'd like to leave that to you)
>
> Or should I download the generator and run it myself?
download the sqlite db file and do
sqlite> select dist,requires,version from prereq
prereq is gathered by looking at Meta.YML, Build.PL and Makefile.PL. There's
currently no checking, if infos provided there are correct. And
Build.PL/Makefile.PL parsing might be buggy. So use the infos with care
(which holds true for all CPANTS stuff at the moment)
BTW, dist is a distname (eg Acme-Bleach-1.12) and requires is a module name
(eg Acme::Bleach).
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: Why do users need FileHandles?
"David Storrs" <[EMAIL PROTECTED]> wrote ># Print file, inefficiently > print $default.readline for 1..$default.lines; print it efficiently: print $default; > # Append a line > $rw .= "an additional line\n"; $rw ~= "\n" unless $rw.chars[-1] eq "\n"; $rw ~= "an additional line\n"; > # New line is visible through $rw > print $rw.lines[-1]; # (*) > > # last line not yet visible through $default because it was > # added by external handle--just like in a tail -f, we > # need to move file pointer manually > $default.seek(File.current_pos); I don't think the manual sync is really needed: name the method something a bit more neutral: $default.refresh; > (*) The .lines[-1] semantic is feasible if we are willing to tolerate > very slow performance (at least the first time; it could cache the > locations of $/ after scanning and dump the cache if $/ changes), the > fact that it wouldn't work on all files (/dev/null, /dev/zero, etc), > and a few other issues. The performance here could depend on the encoding. If the file is ASCII, then we don't need to worry about multi-byte characters, so the under-the-hood implementation could follow a heuristic such as "seek to 1000 bytes from end of file: scan forward for "\n". If none found, then go back further. Otherwise continue to scan to find last "\n" in the file". Dave.
Re: Why do users need FileHandles?
On Mon, 2004-07-19 at 14:04, David Storrs wrote: > Second, I would suggest that it NOT go in a library...this is > reasonably serious under-the-hood magic and should be integrated into > the core for efficiency. You must have amazingly fast hard drives. -- c
Re: Why do users need FileHandles?
--- chromatic <[EMAIL PROTECTED]> wrote: > On Mon, 2004-07-19 at 14:04, David Storrs wrote: > > > Second, I would suggest that it NOT go in a library...this is > > reasonably serious under-the-hood magic and should be integrated > into > > the core for efficiency. > > You must have amazingly fast hard drives. I mount /tmp on swap. My "hard drive" is bitchin fast. =Austin
Re: Why do users need FileHandles?
- Original Message - From: David Storrs <[EMAIL PROTECTED]> Date: Monday, July 19, 2004 5:04 pm Subject: Re: Why do users need FileHandles? > Second, I would suggest that it NOT go in a library...this is > reasonably serious under-the-hood magic and should be integrated into > the core for efficiency. How would integrating this in the core make it more efficient? Core or not, I'd see something like this being implemented with a custom pmc. I tend to think of inclusion in the core being more of a philosophical decision... - Joe
Re: Call To Cygwin Users Everywhere
Joshua Gatcomb <[EMAIL PROTECTED]> wrote: > 5. -mno-accumulate-outgoing-args is NOT required to > make JIT work properly. It will be required, as soon as USE_CGP is turned on again. config/auto/gcc.pl should set it, but obviously doesn't for cygwin. leo
Re: Why do users need FileHandles?
JOSEPH RYAN writes: > - Original Message - > From: David Storrs <[EMAIL PROTECTED]> > Date: Monday, July 19, 2004 5:04 pm > Subject: Re: Why do users need FileHandles? > > > Second, I would suggest that it NOT go in a library...this is > > reasonably serious under-the-hood magic and should be integrated into > > the core for efficiency. > > How would integrating this in the core make it more efficient? Core > or not, I'd see something like this being implemented with a custom > pmc. I tend to think of inclusion in the core being more of a > philosophical decision... Yes, it is. Whether or not a PMC is in the core, it should be equally fast. That is, unless Parrot is allowed intimate knowledge of the PMC's internals. And there are very few (any?) PMCs that possess this property even now. Even more philosophical is "what is core?" I get the impression that Larry is trying to blur the distinction between core and non-core as much as possible. So making it "go in the core" may just mean that it's on the list of recommended modules to install. Luke
Re: Why do users need FileHandles?
- Original Message - From: Luke Palmer <[EMAIL PROTECTED]> Date: Thursday, July 22, 2004 2:48 pm Subject: Re: Why do users need FileHandles? >> JOSEPH RYAN writes: > > > > How would integrating this in the core make it more efficient? Core > > or not, I'd see something like this being implemented with a custom > > pmc. I tend to think of inclusion in the core being more of a > > philosophical decision... > > Yes, it is. Whether or not a PMC is in the core, it should be equally > fast. That is, unless Parrot is allowed intimate knowledge of the > PMC'sinternals. And there are very few (any?) PMCs that possess this > property even now. But why would Parrot need to see the PMC's internals? I was thinking more along the lines of a class just looked just like PerlString, except with different, uh, stuff in the pmc class methods. > Even more philosophical is "what is core?" I get the impression that > Larry is trying to blur the distinction between core and non-core as > much as possible. So making it "go in the core" may just mean > that it's > on the list of recommended modules to install. You're probably right. Every time I think about the idea of "there will be no core modules", a conservative part of me becomes scared out of its mind, and that conservative side wants to riot. But, once I think about it a little more, that riot quickly gets beaten down with thought batons like: "Sure, there won't be any core modules, but most of what Perl5's core will be seamlessly built into the language anyways, and not having other core modules will free everyone from having to continue to use crusty old interfaces like Exporter and File::Find". But, going back to the original topic, something like this kind of I/O abstraction should still be some sort of *module* (core or not), not a core *behaivor*.
Re: xx and re-running
- Original Message -
From: James Mastros <[EMAIL PROTECTED]>
Date: Sunday, July 18, 2004 5:03 am
Subject: xx and re-running
> Recently on perlmonks, at
> http://perlmonks.org/index.pl?node_id=375255,
> someone (DWS, actually) brought up the common error of expecting x
> (in
> particular, listy x, which is xx in perl6) to not create aliases.
> What
> he was doing in particular, I don't have any expectation of making
> it
> work, but what about the also-common problem of C< @randoms = (int
> rand
> 100) xx 100 >? In perl5, this picks one random integer between 0
> and
> 99, and copies it 100 times -- not what was intended. The best
> way to
> do this is C< my @randoms = map {int rand 100} 0..100; >, which is
> rather yucky -- conceptually, you aren't trying to transform one
> list
> into another. OTOH, C< my @randoms; push @randoms, int rand 100
> for
> 0..100 > is even yuckier.
>
> Perhaps if the LHS of a xx operator is a closure, it should run
> the
> closure each time around... or perhaps there should be an xxx
> operator.
> (Both suggestions from BrowserUk's reply,
> http://perlmonks.org/index.pl?node_id=375344). The former raises
> the
> question of what you do if you really want to repeat a coderef,
> and the
> later raises the possibly of being blocked (really), and starts to
> become confusing -- the difference between x and xx is sensical --
> the
> former repeats one thing, the later many... but what's the
> reasoning for
> xxx, other then that it's like xx? How will users be able to
> remember
> which is which?=
When I think about your description of xxx, I
summarized it in my head as "Call a coderef a certain
number of times, and then collect the results."
That's pretty much what map is, except that xxx is
infix and map is prefix.
@results = { ... } xxx 100;
@results = map { ... } 1.. 100;
Doesn't seem that special to me.
- Joe
Re: xx and re-running
JOSEPH RYAN writes:
> When I think about your description of xxx, I
> summarized it in my head as "Call a coderef a certain
> number of times, and then collect the results."
> That's pretty much what map is, except that xxx is
> infix and map is prefix.
>
>
> @results = { ... } xxx 100;
> @results = map { ... } 1.. 100;
>
> Doesn't seem that special to me.
And adding to that the definition of a unary hyper operator:
[EMAIL PROTECTED] == map { Â$_ } @list
It seems that the rand problem could be solved this way:
my @nums = rand (100 xx 100);
Luke
Re: String interpolation
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote: > We allowed/required @foo to interpolate in Perl 5, and it catches a > certain number of people off guard regularly, including yours truly. > So I can argue [EMAIL PROTECTED] both ways. Currently @foo[] is a syntax error. maybe "@foo[]" in Perl6 could be what "@foo" is in Perl5? And I mean a literal '[]', not "@foo[expression-that-returns-an-empty-list]" Dave -- You never really learn to swear until you learn to drive.
Re: String interpolation
Larry Wall wrote:
No Yes
-- ---
@foo@foo[1]
%bar%bar{"a"} or %bar«a»
$foo.bar$foo.bar()
&foo&foo(1)
I may have missed it, but what are the contexts in these cases? I'm
thinking the first two are easily scalar. Are the second list just as
if they were inside curly braces, or are the scalar to match the others
(or just to be flexibly different)?
In this worldview, $foo is an exception only because it doesn't naturally
have a form that ends with some kind of bracket.
Will "$x[$y]" interpolate? Oh and if $x is a reference to an array, is
"$x" a stringified reference or dereferenced (and in which context)? I
got it in my head that since things in curlies would be in list context
that the others must be scalar/string context. I haven't been able to
find a reason for justifing that leap, but I kind of like it. Well for
the moment.
Dan
Re: String interpolation
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote:
> No Yes
> -- ---
> @foo@foo[1]
> %bar%bar{"a"} or %bar«a»
> $foo.bar$foo.bar()
> &foo &foo(1)
>
> In this worldview, $foo is an exception only because it doesn't naturally
> have a form that ends with some kind of bracket.
In an ideal universe, here's what I would like to see:
Scalars and things ending in brackets are interpolated. Things
starting with '@' are interpolated if there is an array of that name,
otherwise they are treated as literals.
$foo = 'apple';
%bar = ('a', 1, 'b', 2);
@foo = <>;
sub foo { my $param = shift // 7; return $param +2; }
# attached to object $baz which stringifies to '^object baz^'
method bar { return 'quux'; }
print "$foo"; # apple
print "\$foo"; # $foo
print "%bar"; # %bar
print "$baz.bar"; # ^object baz^.bar
print "$baz.bar()"; # quux
print "$baz\.bar()";# ^object baz^. with WARNING: no function bar()...
print "&foo"; # &foo
print "foo()"; # 9
print "&foo()"; # 9
print "&foo(1)";#
print "@foo[1]";# a
print "%bar{'a'}"; # 1
print "%bar«a»";# 1
print "@foo"; # a b c [1]
undef @foo;
print "@foo"; # @foo [2]
[1] Variable @foo exists, so it is interpolated. Separator character
might or might not be space, null string, whatever.
[2] Variable @foo does not exist, so is used as literal value,
possibly with warning. I don't know if there would be a difference
between these:
undef @foo
delete ::{'@foo'} # Perl5 syntax...still correct?
If there is, then probably the latter is required.
--
[EMAIL PROTECTED]
Re: Why do users need FileHandles?
Luke Palmer wrote: JOSEPH RYAN writes: - Original Message - From: David Storrs <[EMAIL PROTECTED]> Date: Monday, July 19, 2004 5:04 pm Subject: Re: Why do users need FileHandles? Second, I would suggest that it NOT go in a library...this is reasonably serious under-the-hood magic and should be integrated into the core for efficiency. How would integrating this in the core make it more efficient? Core or not, I'd see something like this being implemented with a custom pmc. I tend to think of inclusion in the core being more of a philosophical decision... Yes, it is. Whether or not a PMC is in the core, it should be equally fast. That is, unless Parrot is allowed intimate knowledge of the PMC's internals. And there are very few (any?) PMCs that possess this property even now. Even more philosophical is "what is core?" I get the impression that Larry is trying to blur the distinction between core and non-core as much as possible. So making it "go in the core" may just mean that it's on the list of recommended modules to install. Luke How about we say "in core" means it packaged with the perl6 source and covered in the coresponding camel & lama books. :) Dan
Re: Why do users need FileHandles?
- Original Message - From: Dan Hursh <[EMAIL PROTECTED]> Date: Thursday, July 22, 2004 3:07 pm Subject: Re: Why do users need FileHandles? > Luke Palmer wrote: > > > JOSEPH RYAN writes: > > > >>- Original Message - > >>From: David Storrs <[EMAIL PROTECTED]> > >>Date: Monday, July 19, 2004 5:04 pm > >>Subject: Re: Why do users need FileHandles? > >> > >> > >>>Second, I would suggest that it NOT go in a library...this is > >>>reasonably serious under-the-hood magic and should be > integrated into > >>>the core for efficiency. > >> > >>How would integrating this in the core make it more efficient? Core > >>or not, I'd see something like this being implemented with a custom > >>pmc. I tend to think of inclusion in the core being more of a > >>philosophical decision... > > > > > > Yes, it is. Whether or not a PMC is in the core, it should be > equally> fast. That is, unless Parrot is allowed intimate > knowledge of the PMC's > > internals. And there are very few (any?) PMCs that possess this > > property even now. > > > > Even more philosophical is "what is core?" I get the impression > that> Larry is trying to blur the distinction between core and non- > core as > > much as possible. So making it "go in the core" may just mean > that it's > > on the list of recommended modules to install. > > > > Luke > > How about we say "in core" means it packaged with the perl6 source > and > covered in the coresponding camel & lama books. :) Well, that's what all of the ruckus is about. There is a strong leaning towards including *no* builtin modules with the core. So, that leaves only the builtin functions and classes as "the core", and so what is "in core" becomes a pretty big deal. - Joe
Re: Testing Database Schema
On Mon, Jul 19, 2004 at 05:00:05AM -0700, Ask Bjoern Hansen wrote: > [EMAIL PROTECTED] (Tony Bowden) writes: > > [...] > > The two "best" ideas we've had so far are to either run the SQL in the > > code against a temporary database, and then compare both SHOW CREATE > > TABLE outputs, or to use something like SQL::Translator to convert both > > lots of SQL to a common format. Both seem much too cumbersome, however. > > > > Anyone have any brighter ideas? > > One variation that might work (and if it does, it'd also work on other > databases) would be to use DB::Introspector. > > http://search.cpan.org/dist/DB-Introspector/ There's also http://search.cpan.org/dist/SQL-Translator/ and http://search.cpan.org/dist/DBIx-DBSchema/ Tim.
Re: CPANTS preview
On Thu, Jul 22, 2004 at 04:28:08PM +0200, Thomas Klausner wrote: > Hi! > > I ran CPANTS today, you can view results here: > > http://cpants.dev.zsi.at/ > ( or http://test1.dev.zsi.at if DNS isn't updated..) > > in /metrics there is a yaml-file for each dist > cpants.db (or cpants.db.gz) is a SQLite DB file > > Oh, there might be a bug, because 100 dists didn't get any kwalitee when at > least some of them should... > > Max Kwalitee is 10, which is reached by 99 dists. The DBI gets 9. The one failure is permissions_ok: > permissions_ok (i.e. all files are read/writable by extracting user) Why is that a kwalitee issue? I don't think it warrants impacting the kwalitee. Tim. p.s. It'll cause problems for anyone using a source code control system that keeps files read-only - like RCS and CVS do. That's the reason the DBI has many read-only files. (I use svn now, but used to use RCS.)
Re: CPANTS preview
On Thu, Jul 22, 2004 at 05:25:38PM +0100, Nicholas Clark wrote: > On Thu, Jul 22, 2004 at 04:28:08PM +0200, Thomas Klausner wrote: > > Hi! > > > > I ran CPANTS today, you can view results here: > > Oooh. Nice Agreed. I think it is a great start. Thanks very much for your work. > > Max Kwalitee is 10, which is reached by 99 dists. > > Will it go up to eleven soon? :-) At the moment the focus seems very much on packaging. That's fine, but it does mean that "correctly" packaged junk looks pretty good. In time, some more metrics would be good. Some suggestions: - How do the CPAN testers reports look? - What does cpanratings think? - Some analysis of the RT action. - Number of releases, perhaps in relation to the size of the code. More releases expected for larger code. - Static analysis. - Test coverage. Some of those will be a lot harder than others, and the metrics will obviously need to be weighted, but I just wanted to throw out a few thoughts from the safety of the peanut gallery. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Why do users need FileHandles?
Luke Palmer <[EMAIL PROTECTED]> wrote on July 22, 2004: Even more philosophical is "what is core?" I believe the standard definition is "Anything I want to use goes in the core; anything everyone else wants goes wherever there's room left over." ... So making it "go in the core" may just mean that it's on the list of recommended modules to install. Does that mean having to "use Some::Module" to use it? If so, that partially defeats the point of having a magical DWIMy shorthand in the first place. (And if not -- then I guess it's irrelevant to most end users whether it's "really" a module or not.) I think stringified filehandles should be "core" -- i.e. always available without having to install or include anything -- because they're exactly the sort of easy thing that Perl is supposed to make trivial. And of course, since there are plenty of cases where pretending a file is just a string won't work, Perl should also make the harder cases easy by including plain old 'open' in The Core as well. [Not] using one doesn't in any way get in the way of using the other, and they'd both be commonly used, so I think they both need to be readily available. In fact, my general attitude towards random feature $foo is: useful to lots of people who want to use it + not harmful to people who don't = put it all in the core. -David "at least until starting perl begins to take longer than your coffee break" Green
Re: Why do users need FileHandles?
David Green writes:
> >So making it "go in the core" may just mean that it's
> >on the list of recommended modules to install.
>
> Does that mean having to "use Some::Module" to use it?
Not necessarily. Glop, on which I'm doing a presentation at OSCON (have
to plug it sometime ;-), makes use of an idiom where you don't have to
'use' everything you want. That's because the small module quanta used
in the design would make the first 50 lines of your program 'use'
statements.
I should expect a similar thing in Perl 6 if traits are going to be
packaged up in their own modules.
> If so, that partially defeats the point of having a magical DWIMy
> shorthand in the first place. (And if not -- then I guess it's
> irrelevant to most end users whether it's "really" a module or not.)
Here's one defining feature of core:
if $feature.has_shorthand {
$feature.in_core = !$feature.requires_use;
}
Sorry. Got tired of English.
> I think stringified filehandles should be "core" -- i.e. always
> available without having to install ...
There's a lot of stuff like that. Way too much to include in a
distribution. That's why we're going to distribute close to nothing
with Perl 6 in order to force vendors to install a decent module suite.
It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1]
> In fact, my general attitude towards random feature $foo is: useful
> to lots of people who want to use it + not harmful to people who
> don't = put it all in the core.
And there's our second system syndrome. Fortunately, Perl is embracing
its second system syndrome.
I think with a sensible auto-inclusion system (really, they're quite
nice--if it can be done at compile time), we'll be able to keep things
out of core and still make them feel like they're in core. There's
something to be said for modules like that.
Luke
[1] Everything You Ever Wanted To Install But Were Afraid To Ask
