[perl #62528] Match.keys method returns nothing.
# New Ticket Created by "Eric Hodges"
# Please include the string: [perl #62528]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62528 >
use v6;
rule test {test};
"test" ~~ //;
say '$/.keys => ', $/.keys.perl;
say '%($/).keys => ', %($/).keys.perl;
# outputs
# $/.keys => []
# %($/).keys => ["test"]
Same could be said for .values and .kv
It would be very DWIM for it to act like a hash in these cases by default.
[perl #62530] Assinging a $/ to a scalar and then accessing its extened .keys method produces a "Null PMC" error
# New Ticket Created by "Eric Hodges"
# Please include the string: [perl #62530]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=62530 >
class Match is also { method keys () {return %(self).keys }; };
rule a {H};
say "Hello" ~~ //;
say $/.keys.perl;
my $x = $/; $x.keys.perl.say;
Produces:
H
["a"]
Null PMC access in find_method()
[perl #61534] [PATCH] Add support for =END and =begin END
# New Ticket Created by "Eric Hodges" # Please include the string: [perl #61534] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=61534 > I also added tests in revision R24492 file t/spec/S02-whitespace_and_comments/*_end.t
[perl #61420] [PATCH] Add support for .succ and .pred for Int, Num and Str
# New Ticket Created by "Eric Hodges" # Please include the string: [perl #61420] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=61420 > Index: src/classes/Int.pir === --- src/classes/Int.pir (revision 33937) +++ src/classes/Int.pir (working copy) @@ -37,6 +37,24 @@ .end +=item succ and pred + +Increment and Decrement Methods + +=cut + +.sub 'succ' :method +$P0 = clone self +inc $P0 +.return ($P0) +.end + +.sub 'pred' :method +$P0 = clone self +dec $P0 +.return ($P0) +.end + =item ACCEPTS() =cut Index: src/classes/Str.pir === --- src/classes/Str.pir (revision 33937) +++ src/classes/Str.pir (working copy) @@ -113,7 +113,25 @@ .return ($P0) .end +=item succ and pred +Increment and Decrement Methods + +=cut + +.sub 'succ' :method +$P0 = clone self +inc $P0 +.return ($P0) +.end + +.sub 'pred' :method +$P0 = clone self +dec $P0 +.return ($P0) +.end + + =item WHICH() Returns the identify value. Index: src/classes/Num.pir === --- src/classes/Num.pir (revision 33937) +++ src/classes/Num.pir (working copy) @@ -67,6 +67,25 @@ .end +=item succ and pred + +Increment and Decrement Methods + +=cut + +.sub 'succ' :method +$P0 = clone self +inc $P0 +.return ($P0) +.end + +.sub 'pred' :method +$P0 = clone self +dec $P0 +.return ($P0) +.end + + =item WHICH() Returns the identify value.
Re: negated operators and disjunctions (was: Recommended Perl 6 best practices?)
# from Carl Mäsak
# on Sunday 14 September 2008 07:18:
>die "Unrecognized directive: TMPL_$directive"
> if $directive ne 'VAR' | 'LOOP' | 'IF';
>
>One is tempted to assume that this means the same as
>"$directive ne 'VAR' || $directive ne 'LOOP' || $directive ne 'IF'",
>but it doesn't.
Actually, it does mean exactly that.
But you're not really tempted to read it as:
if this isn't "var" or else this isn't "loop" or else this isn't "if"
(in denial?). Instead, one is tempted to read it as:
if this is not: 'var', 'loop', or 'if'
, by which you really mean:
if this is not 'var' and this is not 'loop' and this is not 'if'
or:
if not this is any of: 'var', 'loop', or 'if'
which is:
unless this is any of: 'var', 'loop', or 'if'
or:
if this is not all of: 'var', 'loop', and 'if'
But perhaps the thing to remember is to not mix negated operators with
disjunctions? The 'dis' being a form of negative and all.
I found this in E06:
if %person{title} ne $known_title { ... }
Well... I guess E06 is unmaintained, but currently has the best
explanation of junctions I can find, so I offer the attached patch in
the hope that the logic error does not propagate.
--Eric
--
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---
http://scratchcomputing.com
---
Index: exe/E06.pod
===
--- exe/E06.pod (revision 14582)
+++ exe/E06.pod (working copy)
@@ -857,6 +857,15 @@
print "Unknown title: %person{title}.";
}
+[Update: that was a logic error: the negated operator carries through
+the disjunction and is always false.
+
+unless %person eq $known_title {
+say "Unknown title: %person.";
+}
+
+Hash key quoting has also changed.]
+
or even C references:
my &ideal := \&tall & \&dark & \&handsome;
Re: Iterator semantics
Hi Larry,
# from Larry Wall
# on Thursday 11 September 2008 12:13:
>So when you put something into a list context, some of the values
>will be considered "easy", and some will be considered "hard".
>The basic question is whether we treat those the same or differently
>from a referential point of view. ...
>The easy ones are the values that have already been calculated,
>presumably...
>
>Suppose we have
>
> my @a = 1..10; # assume easy
> my @b = =$socket; # assume hard
>
> for @a,@b {...}
>
>If the for list sees @b as hard and just copies @b's iterator into its
>own list for lazy evaluation, then it's going to end up iterating the
>socket without loading @b. Contrariwise if @b is eagerly evaluated it
>might clobber the other iterator in the for list. So those iterators
>must be kept unified. It's not enough to copy out the iterators
>from the array; access to the hard elements of the array must still
>be modulated by the array container. A snapshot of the array
> container will not do in this case.
If a lazy list is an array with an iterator welded onto the end, then:
1 .. 10 is just: 1, 2, 3, weld_here iter(4, thru => 10)
1 .. * is just: 1, 2, 3, weld_here iter(4)
And because an iterator doesn't go backwards, the array has to remember
the previous values to allow me to maintain the "just an array"
abstraction, so after I asked for @a[3], the internal state is like:
1 .. * becomes: 1, 2, 3, 4, weld_here iter(5)
>As a first shot at that definition, I'll submit:
>
> 1 .. $n # easy
> 1 .. * # hard
>
>On the other hand, I can argue that if the first expression is easy,
>then the first $n elements of 1..* should also be considered easy, and
>it's not hard till you try to get to the *. :)
>
>It could also be that I'm confusing things here, of course, and that
>1..* is something easy and immutable that nevertheless cannot be
>calculated eagerly.
But you can take a copy of the "@a = 1 .. *" however you like as long
as "just an array" holds such that @a[41] is always the same regardless
of whether you (internally) have to kick the welded-on iter 27 times to
get that element or have already passed it. So in this case you could
(internally) end up with two copies each holding their own iter() in
different states while still giving the same result at the "just an
array" level. But this is just an optimization on the general case you
stated of "must be modulated by the array container" and it is an
optimization which is only possible for predictable iters.
So, perhaps the case is:
1 .. $n # bounded and predictable
1 .. * # unbounded and predictable
=$handle # bounded and unpredictable
=$socket # unbounded and unpredictable
By "unpredictable", I'm meaning simply that the value of a given element
cannot be calculated independently by replicating a (pure) function
f($i). Perhaps a filehandle isn't a thorough example of that though?
What about:
my @a = 1..*;
my @b = =$socket;
for @a,@b {...; @a = something(); ...}
or:
my @a = 1..*;
my @b = =$socket;
my @c = (@a, @b);
for @c {...; @a = something(); ...}
In the first case, changing @a changes the for() iterator but in the
second, the for() will still be nibbling on 1..*, right? So the
welded-on-iter is basically by-reference until I do something under
the "just an array" paradigm which breaks the weld?
@a = 1..*;
@a[-1] = 9; # @a = (9) now ?
That's just my thoughts from what I understand and sorry if introducing
welding into the analogy causes bits of molten metal to go flying
around ;-)
--Eric
--
"You can't win. You can't break even. You can't quit."
--Ginsberg's Restatement of the Three Laws of Thermodynamics
---
http://scratchcomputing.com
---
Re: [perl #57320] touch /tmp/t && make test => fails t/perl/Parrot_IO.t ?
# from Will Coleda # on Monday 28 July 2008 07:31: >I presume Eric noticed this as he was working on his patch to enable a >parallel make test; Now that his patch is applied, fixing these tests >should have a higher priority; If two tests that are trying to >create/use the same directory run at the same time, one of them is >likely to fail. Well, that is all true. But it really has little to do with parallel testing, it is simply a faulty assumption. Today I'm working on something else and still haven't shutdown my machine since then, so I still have a file /tmp/t, so the tests still fail. I *could* delete that file, but what if that just happens to be my favorite empty file of all time? But if I look at it deeper, the Parrot::IO code only exists for ./tools/docs/write_docs.pl? Oh, and a bunch of the codingstd tests? --Eric
Re: unified languages-test
# from Will Coleda # on Monday 18 August 2008 12:11: >> as far as i'm aware, with planet.parrotcode, the administrator picks >> the feeds that are aggregated. >> ~jerry > >Yes, I assumed you wanted server side aggregation. > >What you're suggesting here sounds just like "subscribe to as many >feeds as you want in your reader", which I can already do. What else >am I missing? Perhaps http://$url/testfeed?tcl&rakudo=spectest_regression&parrot=branches/gsoc_nci/testj Or something like that, where the "any news?" question from the client is answered as the union of "any news?" in relation to all of the requested targets. Which would reduce the number of requests to the server. But of course a newsreader with nested folders could cobble it all together on the client side. --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --- http://scratchcomputing.com ---
Re: enterprise parrot
# from jerry gay # on Tuesday 05 August 2008 14:13: >>On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell wrote: >> Which reminds me: chromatic, what was your reasoning for major >> releases being every three months, instead of four or six? >> >> I agree we don't want to go much beyond six months for our major >> releases, but with at least two major distros that aim for decent >> freshness (Ubuntu and Fedora) using six month release cycles, I'm >> curious what we gain with a shorter cycle than that. >please start a new thread as this has moved off-topic. Indeed. There's quite a bit of ground left to be covered before anyone needs to worry about how much the support contracts are going to cost. I imagine that release cycles and deprecation of parrot features isn't going to mean nearly as much churn to RHEL or Ubuntu LTS, or Debian "stable" users as it would with e.g. Perl 5 -- because they will typically be interfacing with the HLL, which provides a bit of buffer. --Eric -- A counterintuitive sansevieria trifasciata was once literalized guiltily. --Product of Artificial Intelligence --- http://scratchcomputing.com ---
Re: [perl #57358] Enable parallel testing
# from Moritz Lenz # on Monday 28 July 2008 13:02: >With enough RAM everything is fair game ;-) >I ran it with $n == 20, and identified this list of files: Yes. My reading of Parrot::Configure suggests that there's no tempdir involved, which would need to be done per-process. The alternative is to try to grok whatever Andy Armstrong was doing (has done?) with the TAP::Parser::Scheduler and schedule 't/steps' as a serial chunk. Other alternatives could be made to exist via a simple matter of coding. --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --- http://scratchcomputing.com ---
Re: [perl #57358] Enable parallel testing
# from Moritz Lenz # on Monday 28 July 2008 09:52: >> That's not -just- with the patch, though, is it? I presume you've >> set TEST_JOBS to be something other than '1' ... > >I've set it to 2, and obeserve the errors below. With serial testing I >get a PASS (r29828). Yes. TEST_JOBS=1 doesn't change anything. It looks like most of the tests in t/steps might potentially conflict. To smoke out the resource conflicts in the test suite, one would have to run $n jobs -- but that will forkbomb your system. Another check is to run each against each other with `prove -j 2 $test_n $test_i` Tests need to be written defensively for arbitrary parallelization to be possible. If that's too much coding, the non-optimal "serial within a directory" scheme (or other forms of work division) would have to be used. --Eric -- "Politics is not a bad profession. If you succeed there are many rewards, if you disgrace yourself you can always write a book." --Ronald Reagan --- http://scratchcomputing.com ---
Re: [perl #57320] touch /tmp/t && make test => fails t/perl/Parrot_IO.t ?
# from James Keenan via RT # on Sunday 27 July 2008 18:45: >> It appears that this test assumes (multiple times perhaps?) that it >> may make named files in /tmp/. > >Are you saying that making named files in /tmp (or any other temporary >directory) is bad or something to be avoided? If so, what > alternatives should we pursue? Yes. At least, things like '/tmp/file' and '/tmp/dir' are asking for trouble. By "named files", I mean "simplistically named". Firstly, as a matter of good practice: a simple name (especially short things like 't') could conflict with a file or directory name which is likely something I'm using (i.e. if I had a directory /tmp/t/, then the test would have passed, but silently deleted some files I was working with and made me sad - or at least extremely puzzled!) Secondly, for parallelization: you could conflict with another of your own test scripts and then everyone gets confused and puzzled. Suggested alternative: create one directory such as "/tmp/parrot.7947" (using process id or a more sophisticated algorithm if available), then create whatever you want inside that -- "/tmp/parrot.7947/t" is fine. Thanks, Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed --- http://scratchcomputing.com ---
Re: This week on parrot?
# from Andy Lester # on Monday 05 May 2008: >But do those lurkers actually exist? I exist (or at least, I operate under the assumption that I exist.) >that the people who would be interested in a summary are already on >the list. Indeed I am on the list. But, I usually don't read anything with brackets in the subject line, which is most of the list traffic. A lot of what is happening is the sort of stream that doesn't give your foot back if you dip your toe in the water, so I tend to use what little time I currently have for parrot watching from the streambank. >I guess what I'd really like to see would be something aimed higher >than the p5p summaries are. It'd be something that could be >interesting to a wider range of readers, not just the people who care > about the nitty gritty of PGE/PIR/whatever. "This fabulous > technology brings is this much closer to Rakudo being reality." "This gets us closer" is somewhat assumed in that working away from the goal would be rather silly. But, yes it is good to be explicit about what is progressing and how quickly -- though maybe that's another channel. I think something with a similar level of detail to the p5p summaries would be useful for those who want to contribute, but are looking for a good entry-point. A mid-level summary of "who is doing what" would make it more approachable. --Eric -- Hot dogs: just another condiment. --Heart-attack Man --- http://scratchcomputing.com ---
Re: This week on parrot?
# from Andy Lester # on Monday 05 May 2008: >> This presupposes that the summaries are a good thing: anyone have >> any feedback on this point? > >Just wondering who the audience would be. Lurkers (potential contributors.) Posting it on use.perl.org (and/or various other feed sources) would reach more of us. --Eric -- "Time flies like an arrow, but fruit flies like a banana." --Groucho Marx --- http://scratchcomputing.com ---
Re: [tutorial] pct tutorial language: Squaak implementation
> "Mark" == Mark J Reed <[EMAIL PROTECTED]> writes:
Mark> ... confusion with Squeak, which is how I read this subject
Mark> at first. ("Smalltalk on Parrot?! Whoa!). But maybe
Mark> that's just me. :)
I read it that way too (and had the same reaction :-)
--
[T]he main reason Viaweb ended up being server-based was
that we didn't want to have to write Windows apps.
-- Paul Graham
Re: Google Summer of Code 2008 Call for Proposals
# from Will Coleda # on Thursday 20 March 2008 12:22: >We also have a presence on #parrot and #soc-help on irc.perl.org, as >well as #perl6 on freenode. > >See http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects >for some project ideas if you're a student Hi all, The traffic regarding parrot seems a bit light. In past years of involvement, the bulk of accepted proposals were parrot or Perl 6 related. I think we would like to see at least 10 applications here this year. So, a few questions for parrot people: Are there enough exciting and accessible potential projects within and around parrot? Are we making them clear enough on the wiki? Should we have some more info about how the student should get started coming up with a parrot-related "invent your own project" proposal? More links to parrot info? Are there some students starting to appear in #parrot and I'm just not noticing it? Did your local perl mongers list get my "call for proposals" mail? http://use.perl.org/~Eric+Wilhelm/journal/35953 Do *you* know any students who would be good candidates? Am I just being impatient? I'm curious whether there is a lack of interest or a failure to adequately promote the opportunity. (Or possibly procrastination, but students who appear before the 31st seem likely to make for a more successful, drama-free summer.) I think the most successful students are going to come from one-on-one connections, so I would ask everyone to please try to contact at least one student by Monday. Thanks, Eric
summer of parrot - ideas and mentors wanted
# from chromatic # on Saturday 01 March 2008 17:19: >Will Coleda and Dave Rolsky are currently performing similar features > for Parrot; either of them might be a good first choice. > >If neither can do it, I will. Excellent, thanks. Parrot seems to be nicely supplied with soc managers now! Jerry Gay had already volunteered to do this on irc, so I will let you all sort it out. Please feel free to join us in #soc on irc.perl.org. Should parrot have its own pages for ideas and mentors? Perhaps add a link to your own ideas page, but go ahead and start adding yourselves mentors here? http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_mentors http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects If you hate wikis as much as I do, please visit this handy form and I will batch the wiki edits on your behalf. http://scratchcomputing.com/loveperlhatewiki.html Thanks, Eric -- But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it. --Joel Spolsky --- http://scratchcomputing.com ---
Re: summer of code mentor applications starting (and ending) next week
# from Nicholas Clark # on Friday 29 February 2008 06:58: >There is no such thing as a p5p admin*. No, it would need to be somebody on behalf of TPF, as google needs somewhere to send the mentorship check. Alternatively, a company or individual attached to a sufficiently large perl-based project could submit their application separately (at least Catalyst, mod_perl, and RT come to mind.) But for hacking The only requirement is that you be an entity with which google (a US organization) can legally do business (and of course: that you represent a vibrant open source project.) I'm told that the TPF website is out-of-date. Richard? We need to start building a list of mentors, but they need someone at TPF to contact. >>> http://code.google.com/soc/2008/ >>> "The organization should choose a single administrator to submit >>> its application via the GSoC web app between March 3-12, 2008." --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --- http://scratchcomputing.com ---
Re: [perl #38262] [CAGE] get external Perl5 modules out of the parrot repo
# from James Keenan via RT # on Wednesday 27 February 2008 09:40: >The output of Test::Builder changed at 0.64_01, which falls in between >the 0.60 we had in the distro and the 0.72 which most (but not all) of >our developers are likely to be using now. >... >Two possible solutions: Either eliminate those 6 tests entirely, or >rewrite the tests to make the regexes which need to be matched > tolerant of the differences between Test::Builder 0.60 and 0.72 in > this regard. Are you depending on having Test::Harness 3? If so, the TAP::Harness and/or TAP::Parser API should make parsing TAP less fragile than hand-rolled regexps. --Eric
Re: the future of testing
# from Rafael Garcia-Suarez # on Wednesday 09 January 2008 05:36: >Allison Randal wrote in perl.perl6.internals : >> In the Python test suite, there's a single global location to >> declare a list of test files that are expected to be skipped on a >> particular platform. This has a much cleaner feel than our own >> motley collection of skip and todo markers in various test files. To me, python code generally tends to *feel* cleaner, but on deeper inspection, usually is limited by failed assumptions. I suspect that you've fallen prey to this same seduction in your perusal of their test suite. There may still be something in it -- I'm just adding salt :-D A global skip/todo config would be nice in that it also provides more metadata about the tests, so e.g. running a targetted cross-section of tests becomes easier. >That assumes that tests are skipped per file, which is not always the >case (sometimes you want to skip only one test, sometimes even to work >around an OS bug that appears only in one specific version). But >reorganizing platform-dependent tests might be a good idea. Agreed. Skipping a subtest is very common. Organization would benefit from them being separated, but duplicated setup code would ensue. If tests were broken into methods within the file, you could have the global config and keep the granularity. The "what is a platform?" issue could also make the categorization messy (when you start involving compiler combinations or what-not.) Perhaps something more declarative can be done by providing standard is_foo() functions to reduce the complexity (and/or increase the readability) of the SKIP/TODO conditionals. So, (syntax aside) given foo.t with methods bar, baz, bort, and bob: t/foo.t is_osx(version: 10.0): skip_all: reason: ... is_osx: skip: bar baz bort is_solaris: todo: baz reason: baz needs love is_win32(with => compiler: msvc): todo: bort --Eric -- software: a hypothetical exercise which happens to compile. --- http://scratchcomputing.com ---
Re: [perl #45601] [unified_testing] Plans and notes for the unified testing branch
# from Bernhard Schmalhofer via RT # on Tuesday 27 November 2007 16:22: >after the release of Test::Harness 3.03 I'm wondering about the status >of the 'unified_testing' branch. Test::Harness::Straps doesn't exist in the new Test::Harness, so trunk would need to catchup with that issue regardless (e.g. calling Test::Harness::runtests() will no longer pickup on your custom straps package.) >I wonder whether any major obstacles have surfaced and whether it > makes sense to merge the changes in 'unified_testing' with 'trunk' > again. As far as the harness is concerned, yes. Using the TAP::Harness API is preferable. If the parrot-land changes aren't 100% (e.g. unifying the way in which tests expect to be called), the old harness will still need to deal with the fact that the Test::Harness internals have changed and Straps is no longer available through that API. --Eric
Re: [perl #45601] [unified_testing] Plans and notes for the unified testing branch
# from James Keenan via RT # on Friday 21 September 2007 13:44: >On Thu Sep 20 13:03:31 2007, [EMAIL PROTECTED] wrote: >>http://perlsix.org/svn/parrot/view/branches/unified_testing/BRANCH_TODO >>... >> 5) Add processing of the output of Configure --test. > >When I began working on writing tests for the Perl 5 components of >Parrot last November, we made the decision to not incorporate all the >tests I was writing under the 'make test' target. This is perfectly fine. >... some take a long time to run >...some of the tests were only meaningful if run post-configuration, >pre-build... Those are fine reasons to exclude tests from a given target. >So I'm unclear as to what the 'unification' you're talking about would >mean for these test suites. Can you clarify? I think "unification" is primarily needed in the sense of unifying how the results are reported. Do not be alarmed -- the fact that TAP::Parser has "a parser" (and an aggregator) as separate objects from the harness means there is more than one way to do it.[1] Also, "unification" in the sense that the shebang line for the tests tell the harness ~how to execute the test, not where to find the parrot and etc. It is intended that the test shebangs will function against an installed parrot and/or hll. And, also "unification" might involve specifying/organizing the tests (e.g. which are "developer", which are "exhaustive", etc) as e.g. a YAML file rather than capturing `$some_t_harness --files`.[2] If this can be completely expressed in data and/or directory layout, the amount of support code required to select a set of tests to run is reduced or eliminated. The details are in the details, err... footnotes. [1] For example, a smoke server might be logging the TAP results from `./Configure.pl --test`, then doing some post-processing and reporting on those results in conjunction with the rest of the TAP tree. The time at which those tests are run need not be dictated by the single harness, but it would be nice to unify the config/declaration of which tests are which and why -- possibly allowing a smoker to run them outside of the context of ./Configure so long as the state of the universe required by these tests is known. [2] This is not strictly necessary, but from my adventures in reading a few $some_t_harness files, the list of files does not usually require computation, and yet can be difficult to deduce from a quick read vs a data file. Perhaps some environment variables or etc. become involved and the list of tests actually does require computation. At the least, the unified harness will not require each t/harness to execute Test::Harness::runtests(@tests)[3] and so the code is reduced simply to the task of returning a manifest of files to be run. Perhaps t/manifest, (which (yes) might still need to be executed) but does not actually run the tests.[4] But maybe a nice directory layout would do? [3] "unification" actually conflicts with "each t/harness calling runtests()" in that the options (such as archiving the TAP) would need to be communicated in a rather roundabout way. [4] Whatever best serves the goal of being able to reliably report on the results of all of the tests run, how long they (each and all) took, and (hopefully cleanly) selects which to run (or not run) when. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --- http://scratchcomputing.com ---
Re: Test::Harness 2.99_02 vs. Parrot
# from Andy Armstrong # on Monday 10 September 2007 11:13 am: >On 10 Sep 2007, at 19:12, Andy Armstrong wrote: >> What are the steps a parrot-n00b would take to be able to reproduce >> your results? svn co https://svn.perl.org/parrot/trunk parrot perl Configure.pl make make test If your Test::Harness is 2.99_+, you'll see lots of places where the -I switch angers the '#!./parrot'. I tend to think this is an abuse of Test::Harness and therefore parrot should bundle Test-Harness-2.64 in their distro (at least, until they get away from it.) >Sounds like Eric's got it under control :) More or less (but there's only one of me.) From prove's point of view, the parrot test suite is a wreck in terms of how it defines which tests are to be run. Some are blacklisted, activated by options, etc. This logic is also (potentially) distributed to every $(find -name harness) file in the tree. So, this is only a *start* because it currently has no way to know which test files to run. http://scratchcomputing.com/tmp/runtests --Eric -- As an old bass player friend of mine used to say: throw money, don't clap. --Tony Parisi --- http://scratchcomputing.com ---
Re: [perl #45153] better TAP::Harness support
# from Parrot via RT # on Tuesday 04 September 2007 01:30 am: >With TAP::Parser, the attached patch and Parrot/TAP/Harness.pm in the >current directory[1], the tests can be run as: > > runtests --harness Parrot::TAP::Harness $(perl t/harness --files) The runtests code has been refactored into App::Prove, which allows parrot to make their own ./runtests such as the attached. This gets rid of the need for --harness argument, and also allows for additional argument flag customizations. ./runtests $(perl t/harness --files) Get TAP::Harness from the svn. Note: this distro also contains a lib/Test/Harness.pm and bin/prove -- neither of those are needed for this, and they *might* even cause trouble with the existing parrot test framework. http://svn.hexten.net/tapx/trunk Additionally, there is now parallel testing support with TAP::Harness::Parallel. http://scratchcomputing.com/svn/TAP-Harness-Parallel/trunk This works like: ./runtests --jobs 9 $(perl t/harness --files) And appears to yield a 30-40% decrease in wait time (assuming that tests do not have resource conflicts (shared tempfiles, etc.)) A cursory examination implies that some parrot tests do indeed have such conflicts, but you have to crank -j up to 25 to find them (which is borderline forkbombing.) t/pmc/io.t t/pmc/os.t t/dynoplibs/myops.t t/src/extend.t --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com --- runtests Description: Perl program
Re: TAP::Harness
# from Gabor Szabo # on Saturday 01 September 2007 01:35 am: >Regarding Parrot, I think there was some discussion of moving it to > use TAP::Harness and to use Smolder to collect the TAP based results. Indeed. We determined that the main task is refactoring all of the t/harness files. It looks like each one of them is building-up a list of tests in code (either with array declarations, globs, etc -- and affected by various environment vars and/or switches.) Other than sorting-out all of that, it's a simple matter of subclassing TAP::Harness and overriding a few methods such as _get_parser_args(). At least, I think that will do it. --Eric -- "Left to themselves, things tend to go from bad to worse." --Murphy's Corollary --- http://scratchcomputing.com ---
Re: [perl #44213] docs/faq.pod - fix L pod abuse
# from Will Coleda via RT # on Friday 03 August 2007 01:40 pm: >Seems like a pretty straightforward patch, but isn't the L<> syntax >used currently proper? The L<> doesn't support "named" http:// links. from perlpod: ' L Links to an absolute URL. For example, L<http://www.perl.org/>. But note that there is no corresponding L syntax, for various reasons. ' >Is there a particular pod reader we're trying >to make happy? I'm assuming the website uses combust, so mostly whatever combust uses. The "68K emulator" and "April Fool's Joke" links here are broken because of it: http://www.parrotcode.org/faq/ Also, pod2html (Pod::HTML) and Pod::Simple::HTML. Thanks, Eric -- "It is impossible to make anything foolproof because fools are so ingenious." --Murphy's Second Corollary --- http://scratchcomputing.com ---
Re: t/codingstd/perlcritic.t needs to be optional
# from Andy Lester # on Wednesday 27 June 2007 10:09 pm: >Modified since when? Create a .critictest file when it succeeds and use that timestamp? # from chromatic # on Wednesday 27 June 2007 11:10 pm: >> What if we have the Perl::Critic checks as Subversion commit hooks? >> Could email p6i with the results, too. That's what we do at work, >> and it's annoying, but it's there and it's pretty in-your-face. > >If it doesn't hose svk push, where the first of several commits fails > due to standards violations, I wouldn't mind trying it as an > experiment. I would guess a post-commit hook run in the background would be the way to do it. Besides the timeout issue, complex code preventing a checkin may be a bad thing because one would need to track-down a server admin if the gatekeeper script had a bug. If the tests run quickly enough locally, that will encourage clean checkins, with the post-commit informing the list of any dirty ones. --Eric -- "You can't win. You can't break even. You can't quit." --Ginsberg's Restatement of the Three Laws of Thermodynamics --- http://scratchcomputing.com ---
Re: What should I work on at the hackathon tomorrow and Friday?
That's a generous offer. How about activating the TODO test described in http://rt.perl.org/rt3/Ticket/Display.html?id=42996, and making it pass? -- A DRE voting system is one of the simplest computer applications you could imagine. It just adds by one. -- Brit Williams, emeritus professor of computer science
Re: [perl #39426] [BUG] Can't build with cygwin.
> "Paul" == Paul Cochrane <[EMAIL PROTECTED]> writes: Paul> Cygwin is building for me without the PATH setting as of Paul> r19022. Not for me, alas: $ svn up -r19022 $ perl Makefile.PL $ make all ... Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc make: *** [runtime/parrot/include/config.fpmc] Error 53 -- I'm a libertarian with a fascist heart. -- Jim Blandy
Re: [perl #43081] [p6] Get p6 tests from pugs.
# from Paul Cochrane # on Thursday 31 May 2007 01:42 pm: > It is possible to get anonymous svn access to the pugs >source, but svn won't allow you to check out source from a different >repository into another repository's path Maybe I'm missing something, but what I've done in similar situations basically amounts to: svn propset svn:ignore "foo" . svn co http://example.com/repository foo Later: svn up foo rsync foo/ standard/location/ That is, the files are all copied (or symlinked) from a single foreign checkout directory into their standard homes within the native repository tree. IME, the "up vs co" logic is best stuck in a bootstrapping script ala: http://svn.dotreader.com/svn/dotreader/trunk/util/dev_fetch_books Do avoid svn:externals though. --Eric -- hobgoblin n 1: (folklore) a small grotesque supernatural creature that makes trouble for human beings --- http://scratchcomputing.com ---
Re: Current State of Building Parrot on Cygwin
> "Ron" == Ron Blaschke <[EMAIL PROTECTED]> writes: Ron> If you see this error ... Ron> the file has Windows line endings Dare I suggest that parrot not be so fussy about line endings? -- If you're trying to choose between two theories and one gives you an excuse for being lazy, the other one is probably right. -- Paul Graham
Re: [perl #37997] r10604 build failure on Cygwin
> "Ron" == Ron Blaschke <[EMAIL PROTECTED]> writes: Ron> Sorry, I guess there was some mental PATH overloading going Ron> on. Try adding the absolute path to F to PATH. Ron> export PATH=/path/to/parrot/blib/lib:$PATH Ron> And then "make." OK, that gets me past that failure, but then I run into another; see attached. + svn info + egrep '^(URL|Revision)' URL: svn+ssh://home/home/erich/svn-repos/trunk/doodles/anagrams/c-sharp Revision: 3457 + perl -V Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=cygwin, osvers=1.5.18(0.13242), archname=cygwin-thread-multi-64int uname='cygwin_nt-5.1 inspiron 1.5.18(0.13242) 2005-07-02 20:30 i686 unknown unknown cygwin ' config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Uusemymalloc -Doptimize=-O3 -Dman3ext=3pm -Dusesitecustomize' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O3', cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld2', ldflags =' -s -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -lcrypt -lgdbm_compat perllibs=-lcrypt -lgdbm_compat libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s' cccdlflags=' ', lddlflags=' -s -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_64_BIT_INT USE_LARGE_FILES USE_SITECUSTOMIZE PERL_IMPLICIT_CONTEXT Locally applied patches: SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under cygwin Compiled at Dec 30 2005 02:44:25 %ENV: CYGWIN="" @INC: /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5.8 . + cat myconfig cat: myconfig: No such file or directory + which gcc /bin/gcc + gcc -v Reading specs from /bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) + echo Windows XP SP 2 x86 Windows XP SP 2 x86 + strings /bin/cygwin1.dll + grep -i cygwin-1 + head -1 /ext/build/netrel/src/cygwin-1.5.24-2/winsup/cygwin/cygheap.cc #perl Configure.pl && PATH=/usr/local/src/parrot/blib/lib:$PATH make all smoke Parrot Version 0.4.10 Configure 2.0 Copyright (C) 2001-2007, The Perl Foundation. Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case it'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Determining nongenerated header files.done. Determining what C compiler and linker to use..
Re: [perl #42170] [PATCH] Report line numbers on trailing_space.t
> "jerry" == jerry gay <[EMAIL PROTECTED]> writes: jerry> i've never run emacs, so i don't know the lispy analog. jerry> i'm sure somebody will chime in with it. This does what you think it does: (setq-default show-trailing-whitespace t) Emacs 22 users can highlight tabs like this: (global-hi-lock-mode 1) (highlight-regexp "\t") -- ... apart from the sanitation, the medicine,education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us? -- Reg, JPF
Re: IRC discussion of smoking and branching
> "chromatic" == chromatic <[EMAIL PROTECTED]> writes: chromatic> The line-ending coding standards tests can be a problem chromatic> in some cases, where Windows developers add new files chromatic> with their native format and forget to set the chromatic> svn:eol-style=native property on the files, so those chromatic> standards fail on Unix and Unix-like platforms. If it helps any: it's possible to fiddle with one's ~/.subversion/config file so that it automatically puts that property (or any property, really) on newly-added files whose names match a pattern. This isn't a foolproof solution, because it requires that every committer make this change on every box on which they hack, and I don't know if there's an equivalent mechanism for those who use git or svk. But it could be a start. Here's the relevant bits from my config file: [miscellany] ### Set enable-auto-props to 'yes' to enable automatic properties ### for 'svn add' and 'svn import', it defaults to 'no'. ### Automatic properties are defined in the section 'auto-props'. enable-auto-props = yes [auto-props] *.pl = svn:eol-style=native;svn:executable;svn:keywords=Id *.pm = svn:eol-style=native;svn:keywords=Id -- Покажи мне твой .emacs, и я скажу, кто ты. -- Russian Proverb
Re: [perl #37997] r10604 build failure on Cygwin
> "Joshua" == Joshua Gatcomb <[EMAIL PROTECTED]> writes: Joshua> Really? No one on #parrot has been able to get parrot to Joshua> work on Cygwin for months. The reason has changed since Joshua> this specific ticket but if you have a working cygwin Joshua> build can you please share more details such as: I doubt this is terribly useful, but I cannot get the cygwin build working, and here's the output that I see. This is with r17772, which someone claimed worked for them. URL: https://svn.perl.org/parrot/trunk Revision: 17772 perl Configure.pl && make all smoke Parrot Version 0.4.10 Configure 2.0 Copyright (C) 2001-2007, The Perl Foundation. Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case it'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Determining nongenerated header files.done. Determining what C compiler and linker to use.done. Determining whether make is installed..yes. Determining whether lex is installed...skipped. Determining whether yacc is installed..skipped. Determining if your C compiler is actually gcc.yes. Determining if your C compiler is actually Visual C++...no. Enabling optimization...no. Determining flags for building shared libraries...done. Determine if parrot should be linked against a shared library..yes. Determining what charset files should be compiled in..done. Determining what encoding files should be compiled in.done. Determining what types Parrot should use..done. Determining what opcode files should be compiled in...done. Determining what pmc files should be compiled in..done. Determining your minimum pointer alignment. 1 byte. Probing for C headers.done. Determining some sizesdone. Computing native byteorder for Parrot's wordsize.little-endian. Test the type of va_ptr (this test is likely to segfault)..x86. Figuring out how to pack() Parrot's types.done. Figuring out what formats should be used for sprintf..done. Determining if your C library has a working S_ISREGyes. Determining architecture, OS and JIT capability...done. Generating CPU specific stuff.done. Verifying that the compiler supports function pointer castsyes. Determining whether your compiler supports computed goto...yes. Determining if your compiler supports inline...yes. Determining what allocator to use.done. Determining if your C library supports memalignyes. Determining some signal stuff.done. Determining whether there is socklen_t.yes. Determining if your C library has setenv / unsetenv...both. Determining if your platform supports AIO...no. Determining if your platform supports GMP...no. Determining if your platform supports readline..no. Determining if your platform supports gdbm.yes. Testing snprintf..done. Determining whether perldoc is installed...yes. Determining whether python is installed.yes, 2.5.0. Determining whether GNU bc is installed.no. Determining whether GNU m4 is installed.no. Running CPU specific stuffdone. Determining whether ICU is installedno. Determining Parrot's revision.done. Generating C headers..done. Generating core pmc list..done. Genera
Re: [perl #37997] r10604 build failure on Cygwin
I use Cygwin and am willing to occasionally test the build on it. Alas I have no clue how to actually -develop- for Cygwin, so I doubt I'd be much help fixing any problems that I find. But I'd be happy to "svn up; perl Configure.pl && make all test" and summarize or post the results. -- I'd like to see Rush Limbaugh tell Omar he can't get married. --Alex Kotlowitz. You hadda be there
Re: [perl #42106] t/pmc/iterator.t t/src/io.t failed on Linux
I think that's my code; I'm looking into it. -- I'd like to see Rush Limbaugh tell Omar he can't get married. --Alex Kotlowitz. You hadda be there
Re: [perl #41617] "make test-pir" fails on x86 linux, r14402
> "Audrey" == Audrey Tang <[EMAIL PROTECTED]> writes: Audrey> Thanks, please "svn up" the pugs tree and try again. Same problem with r15386. -- Raffarin said he wants to see secure Internet voting in France by 2009, and he said if he had a homosexual son, he would love him ... -- from the Chicago Tribune
in PIR, a BigInt is turning into a string against my will -- what am I doing wrong?
(This is with parrot built from the subversion trunk, revision 16999)
Here's a bit of PIR that demonstrates my problem:
.sub 'main' :main
load_bytecode 'dumper.pir'
.local ResizablePMCArray fields
split fields, ",", "hey,you"
_dumper (fields)
.local pmc big
new big, .BigInt
_dumper (big)
set big, "1234567890987654321"
_dumper (big)
unshift fields, big
_dumper (fields)
.end
;;
./parrot mutate.pir
"VAR1" => ResizableStringArray (size:2) [
"hey",
"you"
]
"VAR1" => PMC 'BigInt' { ... }
"VAR1" => PMC 'BigInt' { ... }
"VAR1" => ResizableStringArray (size:3) [
"1234567890987654321",
"hey",
"you"
]
;;
what's puzzling is that "big" starts out as a BigInt, but seems to get
transformed into a string when I put it into the array. I wanted that
last dumped value to contain a BigInt followed by two strings, but
instead it's three strings. I would have thought that making my
"fields" variable be a ResizablePMCArray would have sufficed to ensure
that, but as far as I can tell, "fields" gets transformed from a
ResizablePMCArray to a ResizableStringArray after I assign the return
value of "split" from it. What must I do to get what I want?
Thanks
--
ハ ハ
ミ＾･＾ﾐ
｀~~~´
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Paul, I just checked the RT queue. I didn't realize they came in at the same time. Use the one that's 1.4k and is CC'd perl6internals. Eric -Original Message- From: Paul Cochrane via RT [mailto:[EMAIL PROTECTED] Sent: Sunday, December 17, 2006 7:51 AM To: Eric B. Lubow Subject: [perl #41099] [PATCH] root.in Makefile and CREDITS Eric, > Added make reallyinstall target > Added help text for make reallyinstall target > Fixed make install target It seems that you've provided two different patches to do this (the first looks like an svn diff, and the second a plain normal diff), which one do you want applied? Paul
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Paul, Use the one that is the newest. It has the reallyinstall target in the make help and in the actual make process. Eric -Original Message- From: Paul Cochrane via RT [mailto:[EMAIL PROTECTED] Sent: Sunday, December 17, 2006 7:51 AM To: Eric B. Lubow Subject: [perl #41099] [PATCH] root.in Makefile and CREDITS Eric, > Added make reallyinstall target > Added help text for make reallyinstall target > Fixed make install target It seems that you've provided two different patches to do this (the first looks like an svn diff, and the second a plain normal diff), which one do you want applied? Paul
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target Eric Lubow E: [EMAIL PROTECTED] W: http://eric.lubow.org/ root.patch Description: root.patch
[perl #41099] [PATCH] root.in Makefile and CREDITS
Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target root.new | 16 1 file changed, 12 insertions(+), 4 deletions(-) Eric Lubow E: [EMAIL PROTECTED] W: http://eric.lubow.org/ root.patch Description: root.patch
[perl #41099] [PATCH] root.in Makefile and CREDITS
# New Ticket Created by "Eric B. Lubow" # Please include the string: [perl #41099] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41099 > Ensured the makefile doesn't allow a make install and added myself to the CREDITS file. Eric Lubow E: [EMAIL PROTECTED] W: http://eric.lubow.org/ CREDITS.patch Description: Binary data root.patch Description: Binary data
Re: underscores in the core lib
I think .valid is an excellent argument for underscores all by itself.
Unless you already know what it means you don't have any clue that
its not actualy the word valid instead of val_id. I don't know of any
other problems like this, but at very least that should be changed.
Don't we still try and follow the rule of least surprise!! ? I was
realy surprised to find out that valid was value_id, especialy since
the last reference I saw to it was along side defined, undefined, etc,
so I assumed it was related to that.
/me scratches his noggin.
I don't have any other arguments for _, but it would be interesting to
hear the reasoning agianst it. The builtin versus userdefined is
getting realy blury in p6 anyway so it seems weird to use this as a
way to define it, after all it's not like all user functions WILL have
_ in there name.
On 8/6/06, Ashley Winters <[EMAIL PROTECTED]> wrote:
On 8/6/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Audrey mentioned that Perl 6 is trying to avoid underscores in the
> core library.
>
> It came up when I asked why "valid" isn't called "value_id" because
> if ( $user_input.valid ) { } reads fairly confusingly.
>
> So, a few questions:
>
> 1. what is the "official" naming style for the Pelr 6 standard
> library (not just functions, but methods for core objects, the MOP,
> the compiler toolchain, the truely absolutely core modules, etc).
>
> 2. What is bad about underscores? From what I know most people tend
> to think that $object.do_that_action is the clearest way of naming
> methods, and the technical reasons to avoid these (long symbol
> names, lots of typing) are no longer really valid nowadays (with
> editor autocompletion, etc).
Nothing is wrong with underscores. In fact, under_scores and
camelCase/StudlyCaps should be encouraged I. When you
see function_name() or functionName() or _functionname(), it should be
obvious to any Perl programmer that it's *not* a standard Perl
function -- it's a user/module function. When you see SCARYCAPS, you
should expect out-of-band implicit (action-at-a-distance) behaviour
from whatever code it in it.
Think of underscores and caps as a form of twigil. $scalar, @array,
%hash, &sub, &_internal, &userFunction, &user_function,
&RefugeeWindowsProgrammer, &Let_There_Be_Poetry, &MAGIC,
&UNAUTHORIZED_USER_MAGIC.
And, just like $scalars can hold arrays, &somesub could be a standard
function or a user function (or a standard function which a user
reimplemented -- you never know).
- Ashley Winters
--
--
__
Eric Hodges
Re: ~~ with *
On 6/16/06, Larry Wall <[EMAIL PROTECTED]> wrote:
given $bool {
when False {...}
when True {...}
}
Just my two cents, but whenever i see "when True {...}" I expect $_
to be true, so that i can do when True and when False. And I if see
when followed by a comparison i expect the when to be true when the
comparison is true. To me its kind of like, if you only have one
operand then use the given subject, if you have two operands then they
don't need a subject. So the given $_ topic would fill in only in the
cases where you needed a topic. Of course that might not realy make
since for given/when and its smart matching magic. But then maybe we
just don't want to be able to say "when $a == $b" and thats just
invalid since it would be clearer written as an if.
--
--
__
Eric Hodges
Re: 'temp $x;' with no assignment
On 3/27/06, Larry Wall <[EMAIL PROTECTED]> wrote: > On Mon, Mar 27, 2006 at 02:54:05PM -0600, Jonathan Scott Duff wrote: > : On Mon, Mar 27, 2006 at 10:46:02PM +0200, Yuval Kogman wrote: > : > On Mon, Mar 27, 2006 at 14:35:52 -0600, Jonathan Scott Duff wrote: > : > > I think that if C is the new C, then immediately after the > : > > C line, $x should hold whatever flavor of undef is appropriate. > : > > > : > > Is there some reason we're huffmannizing > : > > : > > : > Because 90% of the code that people use local for in perl 5 is for > : > counting levels and automatically unwrapping them. The other 10% are > : > for more complex values. > : > : Make me believe your 90/10 numbers. > > Doesn't matter what the numbers are, it's the right thing to do. > The default undef hack stems from the days when local() was trying > to fill the role of my() as well. Nowadays temp() should just > mean: "Please arrange to restore yourself to your current value" > and nothing more. (Well, plus the notion that, when applied to a > mutator, the save/restore instruction is passed on to the mutatee to > save itself before the mutation, not after.) > > The p5-to-p6 translator will turn > > local $x; > > into > > temp undefine $x; > > Larry > In order not do do some strange magic could you jsut do: temp($x)++; That seems clear and non magical to me. Just my 2 cents! ;) -- -- __ Eric Hodges
Re: proposal: rename 'subtype' declarator to 'set'
> > I think 'subset' might be a nicer colour for this bikeshed. For an > extra three characters you lose the confusion with "to set", and it > highlights the fact that you're (usually) declaring a *constrained* > subset of the original type. > > > Stuart > Ehh. By that definition arn't all sets subsets? Anyway I didn't see any confusion with "to set" at all. subset confused me quite a bit though. Besides it might not be a sub set at all. set types ; You could call that a subset of words, but i think this has extra clarity over: subset types ; First thing i think when seeing that is...subset of what? where is the larger set defined? Of course I have no knowledge of set theory at all, just a humble programming giving his input.
Re: given too little
On 11/10/05, Gaal Yahas <[EMAIL PROTECTED]> wrote:
> I'm a little bothered that this is consistent but (to me, at least)
> unintuitive. Testing methods on the topic is something people may want
> to do often: is there a way to hide away the control logic? I'm tempted
> to propose that when a ".method" is seen in the when expression, the
> whole thing should become a terminal if. Inconsistent but possibly what
> people want.
That all looks good but you don't realy want it to be just if there is
a .method in there. It would have to be more magical than that
becuase i might want to do something else.
given $num {
when > 5 { }
when < 5 { }
when == 5 {}
}
I'm not sure that can be done in a whay that makes sense but I would settle for
given $num {
when $_ > 5 { }
when $_ < 5 { }
when $_ == 5 {}
}
I'm pretty sure i've heard this discussed but checking S04/Switch
Statments doesn't make any mention of it. If it has been settled
could we get some doc updates?
--
--
__
Eric Hodges
Re: new sigil
needs class and where it doesn't\
sub test (^T $x) {
my ^T $y = $x + 5;
}
Is pretty easy and straight forward. With class i can't figure and
obvious DWIM.
sub test (class T $x) {
my class T $y = $x + 5;
}
That doesn't look right because you have 'my class' so you would think
the type is 'class' except the type isn't class, its T. If you
bareword T then it might overlap (collide) with a real class named T.
In the following case it is not clear wether Dog is defined in the
signature, or a realy seperate class.
sub test (class Dog $x) {
my Dog $y = $x + 5;
}
The same example with ^ becomes much clearer to me.
sub test (^Dog $x) {
my ^Dog $y = $x + 5;
}
The ^ clearly states the meaning while bareword Dog and 'class Dog'
would both cause conflicts in my head.
Just my reasoning about it all.
BTW didn't you contradict your own real world usage of type1^type2 ?
Even if we use ^ as a sigil why would it get confused on that? I
don't think type1 ^type2 could have any realy meaning so it should be
easy for the parser to know the difference.
--
--
__
Eric Hodges
Re: new sigil
What about something like:
c\
Then you get
sub sametype (c\T $x, c\T $y) {...}
Not exactly pretty though. c\T
Actualy i think ^ might be my favorite so far.
sub sametype (^T $x, ^T $y) {...}
--
Eric
Re: Translitteration and combining strings and array references
On 10/18/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > > Uh, no. Certainly not for a method. For a bare sub that has been > predeclared it may be possible. But we don't want to remagicalize > pairs after we just argued the heck out of it to make pairs *always* > be named parameters. My thought was that it wouldn't be much different than *%hash as a signature except you wouldn't loose order and the keys wouldn't me mashed. Is what I'm suggesting more magical in someway? I freely admit it might be a bad idea, I just wasn't sure why and thought i might bring it up since this seems different than the magical ness of pairs before. -- -- __ Eric Hodges
Re: Translitteration and combining strings and array references
I have a suggestion/proposal/whatever.
I am just starting to get a grasp of uses for pairs and where they are
handy. Working on string.trans some showed that it would be useful to have
the function accept a list of pairs. That was working until the fix for
magical pairs went through and now the pairs in the call are treated as
named arguments. After some discussion with iblech and looking at the
Synopsis it looks like *%hash will slurp up named args into a hash and
[EMAIL PROTECTED] slurp up extra parameters. *%hash could work for trans except
it
stringifies the left (or magic quotes or whatever the term is) and looses
order. Both of those are significant to trans and possibly other uses for
lists of pairs. So I was wondering if we could have a signature that meant
to slurp up named args and put them in a list as pairs. For now I suggest
[EMAIL PROTECTED], because it has the flattening connotation already and we are
sort
of flattening a list of named args into a list of pairs.
The biggest issue I see with this is that i don't know how the key value of
named args is handled and if it is handled too soon to then be useful in a
pair.
Currently we (can|will be able to) do
"string".trans( (['h','e'] => "0") );
"string".trans( <== ['h','e'] => "0");
Those are fine and i can live with that, but it seems that if we made the
signature of trans
method trans(Str $self: [EMAIL PROTECTED]) {};
Then we could just do plain old:
"string".trans(['h','e'] => "0");
Which to me seems a lot easier to read. I would propose that it only effects
named params so that there is no concern about pairs in values and how to
handle them.
Re: Translitteration and combining strings and array references
On 16 Oct 2005 03:46:25 -, David Formosa (aka ? the Platypus) < [EMAIL PROTECTED]> wrote: > > On Fri, 14 Oct 2005 08:38:55 +0200, Peter Makholm <[EMAIL PROTECTED]> > wrote: > > Yesterday I spend some hours getting pugs to understand > > translitterations with multiple ranges in each pair. E.g. > > > > "foobar".trans( "a-z" => "n-za-n" ); > > > > By accident I tested something like: > > > > "foobar".trans( ['a' .. 'z'] => "n-za-m" ); > > > > and it didn't work. > > It's a bug. When Pugs gets anyhashes that bug will go away. Can you > add it in to the errors. > > > -- > Please excuse my spelling as I suffer from agraphia. See > http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. > Free the Memes. > Actually its been fixed already. Of course i think the whole thing was then broken again, i was planning on checking it out sometime tonight after someone else figures out the current $?SELF being undeclared bug. ;) BTW it doesn't need any hash i just needed pairs which it had for about an hour before things changed again. lol. so is development on pugs I guess, here today, gone tomorrow, back again another day. -- -- __ Eric Hodges
Re: zip: stop when and where?
Hey, I'd just like to say that I find B a bit misleading because you couldn't tell that the first list ended, it could just have undef's at the end. I like a because it doesn't add any data that wasn't there, of course that could be a reason to dislike it too. On the other hand c makes a good option when you want to work with infinite lists. Is this something that could be modified on per use basis and we just choose one now as the default "they didn't request a specific one so use this one). After all that i think I agree on C specificaly because you can provide a good code use of it and it doesn't add any data that wasn't there before. I don't think it should ever lean towards (b) but them I bet someone else will have an equaly good use of that. ;) So in the end I think some way of chooseing would be good, with one option picked as standard. -- Eric Hodges
Re: Stringification, numification, and booleanification of pairs
Hey,
Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.
my $pair1 = (a => 2);
my $pari2 = (b => 3);
say $pair1 + $par2; # Error: illegal stringification of pair.?
I know nothing, but couldn't users create there own pair class that does
what they want? Or extend the builting one to override operators they way
they want?
Just my 2 cents.
On 9/21/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> Ingo Blechschmidt skribis 2005-09-21 14:47 (+):
> > my $pair = (a => 42);
> > say ~$pair; # "a\t42"? "a\t42\n"? "a 42"?
> > say +$pair; # 0 (pairs aren't numbers)?
> > # 42?
> > # 0 ("a" is not a number)?
> > # 0 (~$pair can't be used as a number)?
> > say ?$pair; # true (because 42 is true)?
> > # true (because pairs are always true)?
> > FWIW, I'd opt for ~$pair to be "a\t42", +$pair to be +(~$pair) [1],
> > and ?$pair to be always true.
>
> Pairs are objects, thus references.
>
> I like your suggestions for ~$pair (though any separator except other \s
> characters would do) and ?$pair.
>
> I don't think +(~$pair) makes any sense, though. It's basically the same
> as +(~$pair.key). It's probably wise to avoid that $pair can be confused
> for its key or value. A good alternative is hard to find, though. I tend
> to prefer 1 at this moment (coincidentally, that's +?$pair).
>
>
> Juerd
> --
> http://convolution.nl/maak_juerd_blij.html
> http://convolution.nl/make_juerd_happy.html
> http://convolution.nl/gajigu_juerd_n.html
>
--
__
Eric Hodges
Re: Demagicalizing pairs
Just my two cents then back to lurking. The idea of having named parameters
with different names than the variables ++. Otherwise your public API is
dependent on private variables which is a Bad Thing and the only thing that
realy bugged me about current named parameters in P6.
BTW why is it that just because they are defined as named they can't be used
positionaly as well?
Guess you could always use your same positional to named magic for the
positionals. Then the programmer is expliciting defining the order in case
the cases they want to use ordered versus named.
multi sub seek ( $x, $y ) { seek( $:x, $:y) }:
multi sub seek ( :x($horizontal), :y($vertical)) { ... };
On 8/19/05, Larry Wall <[EMAIL PROTECTED]> wrote:
>
> On Fri, Aug 19, 2005 at 08:39:24AM -0700, Larry Wall wrote:
> : Actually, that's an argument that : is in a different class than the
> regex
> : quantifiers, and required named should be
> :
> : sub bar (+$:key)
> :
> : as I speculated earlier. Maybe we just force that to bind to $key
> instead
> : of $:key.
>
> Which makes me wonder whether, in ordinary code (not sigs)
>
> $:key
>
> is short for
>
> :key($key)
>
> The idea being that it makes it really easy to pass delegate particular
> pairs to subfunctions as long as you keep the names consistent. It'd
> also make it drop-dead easy to write positional-to-named constructors:
>
> method new ($proto: $a, $b, $c) {
> ...
> return $proto.bless($:a, $:b, $:c);
> }
>
> instead of
>
> method new ($proto: $a,$b,$c) {
> ...
> return $proto.bless(:a($a), :b($b), :c($c));
> }
>
> I suppose if we pushed it we could even allow $:foo in adverbial position.
>
> 1 .. 100 $:by
>
> But I wonder if people will think that
>
> foo 1, 2, 3, @:foo
>
> should interpolate @foo as a list of pairs rather than binding to the
> 'foo' argument. Likewise for %:bar. But those are still [EMAIL PROTECTED] and
> *%bar, I suspect, and people can learn that the : twigil always means
> rewrite. Hmm. That seems to indicate that the actual signature for
> named parameters is
>
> sub foo (:foo($foo))
>
> and that
>
> sub foo ($:foo)
>
> is just shorthand for that. That would give us the ability to give the
> variable a different name than the parameter. I like.
>
> sub seek (:x($horizontal),:y($vertical))
>
> On the other hand, it's now unclear whether you can call that as
> seek(1,2).
> Needs to be allowed somehow.
>
> Larry
>
--
__
Eric Hodges
Perl defined Object, Array, Hash classes
Hey, Found out this morning that wizard.p6 suddenly stopped wondering and I was stumped as to why. The autrijus came along and pointed out that i was defineing an Object class of my own. This was obliterating the built in class causing all other classes to fail to work at all. It would seem from my point of view then that adding class definitions like that through the language should not be done in the root namespace. By putting them there we obliterate any user defined classes (or vice versa in this case). I think it would be much better to instead put those internal definitions in there own namespace or seperate them out in some similar manner. That way in the future the language can add its own classes without fear of conflicts with user defined classes. After all there is no reason to paint ourselves into that corner so early, no one wants to have to fight for new internal classes because every added class could possibly compromise existing code. Well that is my 2 cents and my first post here so please forgive anything that apears rude or stupid and guide me on how to improve future posts. Thanks, __ Eric Hodges
Re: we need more ops.
On Mon, 29 Jul 2002, Nicholas Clark wrote:
> [Maybe we should have a competition to suggest the most crazy three character
> operator - ie state your sequence of three characters (not necessarily ASCII,
> but it helps), state their name, and state their purpose (including whether
> listop, binop, uniop, precedence, associativity or whatever else helps make
> your entry more humorous. So presumably there could be a :-) operator, but
> offhand I can't think of something plausible it could do. And does the
> tie-fighter need an X-wing operator to complement it? (not sure what that
> one would look like, let alone what it would do)]
:-) the Positivity operator ("happy face")
On the left-hand side of an expression, it tests whether the
expression contains a positive value. On the right-hand side, it
transforms the results of the expression into a positive value.
How it does this is implementation dependent.
This operator has right-hand side precendence.
Other operators in this vein are :-(, the "Negativity" operator, and :-|,
the "Zero" operator.
Examples:
print :-) "-1"; # prints "0"
print "-1" :-); # prints some positive value, probably "1"
print -1 :-( :-) :-|; # prints some zero value, probably "0"
What we really need are see no evil, hear no evil, speak no evil
operators.
And on a complete aside, here is something I dug up in 'fortune'. Some of
these are actually useful!
Proposed Additions to the PDP-11 Instruction Set:
BBW Branch Both Ways
BEW Branch Either Way
BBBFBranch on Bit Bucket Full
BH Branch and Hang
BMR Branch Multiple Registers
BOB Branch On Bug
BPO Branch on Power Off
BST Backspace and Stretch Tape
CDS Condense and Destroy System
CLBRClobber Register
CLBRI Clobber Register Immediately
CM Circulate Memory
CMFRM Come From -- essential for truly structured programming
CPPRCrumple Printer Paper and Rip
CRN Convert to Roman Numerals
DC Divide and Conquer
DMPKDestroy Memory Protect Key
DO Divide and Overflow
EMPCEmulate Pocket Calculator
EPI Execute Programmer Immediately
EROSErase Read Only Storage
EXCEExecute Customer Engineer
HCF Halt and Catch Fire
IBP Insert Bug and Proceed
INSQSW Insert into queue somewhere (for FINO queues [First in never out])
PBC Print and Break Chain
PDSKPunch Disk
PI Punch Invalid
POPIPunch Operator Immediately
PVLCPunch Variable Length Card
RASCRead And Shred Card
RPM Read Programmers Mind
RSSCreduce speed, step carefully (for improved accuracy)
RTABRewind tape and break
RWDSK rewind disk
RWOCRead Writing On Card
SCRBL scribble to disk - faster than a write
SLC Search for Lost Chord
SPSWScramble Program Status Word
SRSDSeek Record and Scar Disk
STROM Store in Read Only Memory
TDB Transfer and Drop Bit
WBT Water Binary Tree
Re: coders: add doco
On Fri, 12 Jul 2002, John Porter wrote: [...] > And I don't wanna hear the same old b.s. "patches welcome". > It is incumbent on the person who writes the code to include > his own commentary. Of course, if someone else who *already* > understands the code wants to remedy here and there, fine. Well.. I don't understand the code very well, but I'm willing to help out with any kind of documentation tasks. To be honest, I need some pointers on where exactly to start with this, too, but I'm a quick study :) Eric
Opcode docs, part 2
If no one has any objections, I am planning on adding the undocumented opcodes to pdd06_pasm.pod. For the most part, I am just going to copy the pod documentation from the various *.ops files to pdd06. For those opcodes without documentation or which are confusing, I'll try to contact the authors. Eric -- Baldrick, you wouldn't know a subtle plan if it painted itself purple and danced naked on top of a harpsichord, singing "Subtle plans are here again!" -- Edmund Blackadder
Opcode documentation
First, a quick introduction: I'm Eric. At YAPC, I asked Dan what I can do to help out Parrot and this is what he pointed me at. I've compiled a list of all of the opcodes (as listed in the *.ops files) that are not documented in docs/pdds/pdd06_pasm.pod. In addition, because of some possible weirdness I noticed, I've also compiled a list of the opcodes which are in pdd06 but are not implemented in any of the *.ops. Without further ado: # parrot/core.ops (53/133 documented) abs and bandbnotbor bounds bxorcallcallcc callco callnative capturecc chopn cleari clearn clearp clears close cmodcollectoff collecton debug depth end enternative eq err find_type ge gt index intdepthintrestore intsave le loadext loadlib lt mod ne neg noopnot or ord pack popipopnpopppopsprint profile pushi pushn pushp pushs readlinerestore restoreall rotate_up save saveall savec set_addrset_keyed set_keyed_integer shl shr sleep stringinfo substr sweepoffsweepon timetrace unless warningsoff warningson xor yield # parrot/debug.ops (0/4 documented) debug_break debug_init debug_load debug_print # parrot/io.ops (3/8 documented) close fdopen print printerrputs # parrot/math.ops (0/3 documented) factgcd lcm # parrot/obscure.ops (0/4 documented) covers exsec hav vers # parrot/rx.ops (0/32 documented) rx_advance rx_allocinforx_backwardsrx_clearinfo rx_cloneinforx_compile rx_dot rx_endgroup rx_fail rx_forwards rx_freeinfo rx_incrindex rx_info_getgrouprx_info_getindexrx_info_getstartindex rx_info_successful rx_is_d rx_is_s rx_is_w rx_literal rx_makebmp rx_oneofrx_oneof_bmprx_popindex rx_pushindexrx_pushmark rx_setprops rx_startgroup rx_succeed rx_zwa_atbeginning rx_zwa_atend rx_zwa_boundary Here is a listing of the unimplemented opcodes which are defined in pdd06. The reason I include them is that there are some opcodes in core.ops which are closely named to the ones listed below. For example 'pushn' (from core.ops) is similar to 'push_n' (from pdd06_pasm). atan2 call_method callout can chop_keyclear_eh clone_key fetch_globalfetch_lex find_attribute find_global_slotfind_global_table find_lex find_method find_string_lib get_op_countget_string_name inc_key isa ke_type ke_valuekey_sizeload_bytecode load_opcode_lib load_string_lib locklog make_object new_fh new_key newpad pausecollectpop_i pop_n pop_p pop_s push_i push_i_cpush_n push_n_cpush_p push_p_cpush_s push_s_cpushunlock readw restore_i restore_n restore_p restore_s resumecollect rethrow save_i save_n save_p save_s set_attribute set_eh set_key set_warpsize_keystatus tell throw toss_keytostringunlock unwarp wait warpwritew Finally, for my data collection techniques, I used a script which scans the *.ops files for: $op =~ /^(inline|)\s*op\s+([\w\d_]+)\s*\(/; which should signify the beginning of the C code for the opcode. Hopefully. I then compare that to a list of the opcodes pulled from pdd06_pasm (done by scanning the =item lines) to see what is where. If I've made any mistakes or am just deeply confused, please let me know and I'll make adjustments. Eric
Re: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?
Larry Wall writes:
> I think if we have to go through contortions to get at the outer topic
> by name, it's better to just name the variable on the outer loop in the
> first place. Adding -> $varname to the outer loop is safe, because it
> doesn't change the semantics of topicality--now that we changed the
> rule so that $_ is always aliased to the topic regardless of whether
> it's aliased to an explicit variable name.
>
> Larry
This seems to argue against OUTER::
--
Eric J. Roode[EMAIL PROTECTED]
Senior Software Engineer, Myxa Corporation
@_=unpack "C*",qq;\cw22(D\coF?!%\$&D\x1e=B\cyB'\cu"\cy=B\; $>=0; ;$=-=$=;
push (@^A,$_[$=++]+$_),$^A[$=-1]=~s+\d[^&0.=^&1].+$&-ord e+e
foreach map{unpack 'C'x8,$_}(\getpwuid $>)[0,2,5];
print pack('C*',@^A),"\n";
Re: Math functions? (Particularly transcendental ones)
Dan Sugalski wrote: >Okay, I'm whipping together the "fancy math" section of the interpreter >assembly language. I've got: [...] > >Can anyone think of things I've forgotten? It's been a while since I've >done numeric work. I'm not a math weenie, but I would thing gamma(x) would be of use. Also perhaps a div2(n,m): given two ints, returns two ints, n/m and n%m. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
RE: Expunge implicit @_ passing
Brent Dax wrote: >On the other hand, it could stop some of the really stupid uses for >inheritance I've seen. The dumbest one was in high school Advanced >Placement's C++ classes--the queue and stack classes inherited from the >array class! Oh? How could "final classes" prevent such a travesty? Are you seriously suggesting that the Array class should be designed such that it cannot be inherited? -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: explicitly declare closures???
John Porter wrote: > >Dave Mitchell wrote: >> ie by default lexicals are only in scope in their own sub, not within >> nested subs - and you have to explicitly 'import' them to use them. > >No. People who write closures know what they're doing. > >When's the last time someone "accidentally" wrote a closure? People using mod_perl do it all the time: http://www.perlreference.com/mod_perl/guide/obvious.html I don't agree with the original proposal, since 'use diagnostics' will tell you about closures -- but people DO create closures by mistake, and it can be a very difficult bug to trace if you aren't used to closures. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: aliasing a value in a while each loop
David L. Nicol wrote: > >Are there really situations where > > $$reference = An Expression; > >is clearer than > > $reference = \(An Expression); > >? Eric is confused. I don't know about in Perl 6-to-be, but in Perl 5 those two mean totally different things: $foo = \$bar; # sets $foo to be a ref to $bar $$foo = "hi mom"; # sets $bar to "hi mom" $foo = \"hi mom"; # sets $foo to be a ref to "hi mom" -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
RE: array/hash manipulation
On Friday, July 20, Ilya Sterin wrote:
>No, I don't think you are understanding it correctly. It's not about
>looping sequentially, but rather simultaneouly, for comparison purposes.
>
>@foo = (1,2,3);
>@bar = (1,2,3);
>for my ($foo, $bar) (@foo, @bar) #As the index for @foo increases, so
> #does @bar index
>{
>print "OK\n" if $foo == $bar;
>}
>
>Will print...
>OK
>OK
>OK
>
>Ilya
Yes, right. I'm saying that's very easy to code in perl 5.
@foo = (1, 2, 3);
@bar = (1, 2, 3);
@baz = (1, 2, 3);
$ai = aiter (@foo, @bar, @baz);
while ( ($foo,$bar,$baz) = &$ai )
{
print "OK\n" if $foo == $bar && $bar == $baz;
}
>From my library:(feel free to copy&paste into yours)
#---> $array_iterator = aiter(@a, @b, @c, ...);
# aiter : Creates an array iterator to return the elements of a set of
# arrays in turn. That is, the first time it is called, it returns
# the first element of each array. The next time, it returns the
# second elements. And so on, until all elements are exhausted.
#
# This is useful for looping over more than one array at once:
# $ai = aiter(@a, @b);
# while ( ($a,$b) = $ai->() ) { }
sub aiter (\@;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@)
{
my @arr_list = @_; # The list of (references to the) arrays
my $index = 0; # Which one the caller will get next
my $max_num = 0; # Number of elements in longest array
# Get the length of the longest input array
foreach (@arr_list)
{
$max_num = @$_ if @$_ > $max_num;
}
# Return the iterator as a closure wrt the above variables.
return sub
{
my $i = $index++;
return () if $i >= $max_num; # No more elements to return
return map $_->[$i], @arr_list; # Return ith elements
}
}
--
Eric J. Roode[EMAIL PROTECTED]
Senior Software Engineer, Myxa Corporation
Re: array/hash manipulation [was :what's with 'with'?]
on Fri Jul 20, Mark REED wrote:
>I'm sorry, but I fail to see how this is a big improvement over the
>current version:
>
>while (my ($key, $val) = each %my_hash)
>{ ... }
And a workalike to
while ( ($a,$b,$c) = (@a, @b, @c) )
or
for my ($el1, $el2) (@foo, @bar)
is very easy to code in perl 5. At the risk of sounding reactionary,
this doesn't seem like a Big Win for perl.
------
Eric J. Roode[EMAIL PROTECTED]
Senior Software Engineer, Myxa Corporation
Re: what I meant about hungarian notation
[on David Nicol's thought that maybe references should be treated differently than other scalar data] > >But $, @, and % indicate data organization, not type... > Perhaps it's a mistake that Perl treats numbers and strings the same. Perhaps "$" should be broken out into two prefixes: S for strings, and | for numbers. Use $ when it's unknown what type a variable will hold, or for a variable that can hold either type. Sfoo = 'a string'; |bar = 'a number'; $baz = Sfoo || |bar; And references are right out. ;-) -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - concerns
In a fit of insanity, at 10:14 EDT Tue May 8, I wrote: > >9 times out of 100, qw saves a large number of keystrokes. (The >other 1% of the time, ... I hope it's obvious that I meant "99 times out of 100" -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Apoc2 - concerns
At 16:17 May 7, Simon Cozens wrote: >On Mon, May 07, 2001 at 01:14:12PM -0700, Nathan Wiger wrote: >> I think Uri's qh() suggestion is the cleanest: > >Interesting train of thought, since one of the ideas was that qw() is >ugly and has to go. (Larry's been saying this for nearly two years now, >it's just that people sometimes don't listen. :) Let's keep it and add >something similarly ugly to keep it company! > >-- >And the fact is, I've always loathed qw(), despite the fact that I >invented it myself. :-) > -- Larry Wall in <[EMAIL PROTECTED]> Well, one person's ugly is another person's joy forever. Regardless of the aesthetics of q//, qq//, qw//, et al, (and here docs too), they get the job done in a remarkably flexible, efficient way that is simply not possible with just about any other language out there. 9 times out of 100, qw saves a large number of keystrokes. (The other 1% of the time, you have to work around qw's inability to quote things with spaces). qq, q, and here-docs may be "ugly", but that's a judgment call. What they are not is "broken". Personally, I don't understand how using two alphabetic characters and a pair of delimiters, in order to save typing a whole mess of quotes and backslashes, can be construed as "ugly". :-) And, while I'm on my soapbox here, I don't get how <...> is a vast improvement over qw<...>. :-) -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Flexible parsing (was Tying & Overloading)
Larry Wall wrote: [wrt multiple syntaxes for Perl 6] > >In any event, I'm not worried about it, as long as people predeclare >exactly which variant they're using. And I'm also not worried that >we'll have any lack of style police trying to enforce Standard Perl 6. > >Larry As a member of a consulting group, I am very often called in to enhance or maintain (or just plain fix) existing code for clients. My concern is that it will not be enough simply to know Perl; that I will have to be able to decipher many user-defined variants of Perl. Bad Perl code is easy enough to write and difficult to read, let alone change. And bad Perl code is terribly common. I'm worried that poorly-designed Perl syntaxes will start popping up, further obfuscating poor code, and that will be one more burden for those of us who need to fix it. Sure it's job security, but A badly-written C program is not nearly as hard to maintain as a badly-written PostScript program, partly because PostScript is so redefinable. Maybe reading code written in a bad Perl syntax will be no worse than reading a badly-designed and badly-written class module. I hope that's the case. No, you shouldn't hold back the development of the language simply because people will abuse your efforts and write bad code. Just please keep in mind potential abuses as you're doing your design. A language with arbitrarily flexible syntax can be infinitely difficult to decipher. Thanks. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Flexible parsing (was Tying & Overloading)
John Porter wrote: > >Dan Sugalski wrote: >> The one downside is that you'd have essentially your own private language. >> Whether this is a bad thing or not is a separate issue, of course. > >IIUC, this ability is precisely what Larry was saying Perl6 would have. I may have my history wrong here, but didn't Ada try that? Super- flexible, redefinable syntax? And wasn't the result that nobody could read anybody else's code, so Standards Committees were set up to define Legal Styles that basically reduced the syntaxes that you could use to just the One Standard Style? -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: s/./~/g
Larry Wall wrote: > >Branden writes: >: The big question is: why fix what is not broken? Why introduce Javaisms and >: VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 >: code (and Perl 5 programmers) for a zero net gain? > >It's not zero net gain, and I'm going to ignore the next person who says it. Hokay, fine, I can respect that, but I'm with Branden here... I just don't see the gain. Is it merely to make Perl's derefs look like Java's? If so, so what? If there's more, please elucidate. [...] > >What is it about . that seems to inspire allergic reactions in people? >Surely it's not the . itself, but the requirement that you fit everything >into that one syntactic mold. Perl's not going to do that. No, more like ". is already used for something". The only reason I have seen written out so far for the shift from -> to . and . to is: it looks more like other languages. That seems like a whole lot of fixing of non-broken syntax. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Strings vs Numbers (Re: Tying & Overloading)
Nathan Wiger wrote: > >Here's something I was thinking about at lunch: > > $concated_number = "$number" + "$other_number"; > $numerical_add = $number + $other_number; > One major, MAJOR pet peeve I have wrt Javascript is that it uses + to mean concatenation as well as addition, and that it (like perl) allows scalars to contain strings or numbers. One is continually forced to jump through hoops to do simple arithmetic. User has entered a number -- ah, but it comes in as a string. Want to add 666 to it? You have to do this nonsense: $sum = $addend - 0 + 666; You constantly have to subtract zero in order to force a numeric context. Asinine. Whatever the final Perl 6 solution to string concatenation/addition is, don't let it become the ambiguous mess that Javascript is. My two cents. Thanks for listening. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: "Art Of Unix Programming" on Perl
brian d foy <[EMAIL PROTECTED]>: > On Fri, 9 Feb 2001, Simon Cozens wrote: > > > Perhaps we're not giving the right impression. Hey, brian, aren't > > you supposed to be preventing this from happening? > > no, it isn't. I find this response somewhat mysterious. -- http://www.tuxedo.org/~esr/">Eric S. Raymond Such are a well regulated militia, composed of the freeholders, citizen and husbandman, who take up arms to preserve their property, as individuals, and their rights as freemen. -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" referred to in the Second Amendment to the Constitution.
Re: "Art Of Unix Programming" on Perl
Dan Sugalski <[EMAIL PROTECTED]>: > Yes, but you see, we're not generating code. All the rest of the stuff is > irrelevant, and Real Hackers don't need to design--it's all self-evident. > Besides, you only need to design if you're building one of those Cathedral > thingies, and we all know how bad those are. (If you need to reach higher, > the correct method is, of course, to add another layer of tents on top of > the previous one) The obvious and cutting rejoinder for me to make would be: "Hey. If I believed this, I'd still be writing Perl." But that's a cheap shot, and Larry Wall and I are homies, and I don't really believe it anyway (well, not *much*...). So instead I'll ask you gentlemen to enlighten me. Larry actually invited me to join the Perl6 design list (if only as the doomed futile token voice for LISPy minimalism) and I tried to, but there was some kind of ugly technical snafu with Skud's listserv and I couldn't get signed on. What *is* going on over there, anyway? It is unfortunately true that the effort looks stalled from the outside. I'd be happy to revise that opinion if there are whitepapers or design notes or a Wiki or something I could look at. Anyway, worry not, I don't expect the book to complete for a year. You have plenty of time to change my mind. And I still wouldn't mind contributing to the design. (Cripes. I only dissed Perl mildly. I gave Java a much rougher time and basically consigned Tcl to an early grave -- but no flamage from *those* guys...) -- http://www.tuxedo.org/~esr/">Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries)
Re: RFC 12 (v2) variable usage warnings
Allow me to throw another log on the fire:
my $x;
if (something)
{
$x = 1;
}
my $y = $x;
This would give a compile-time warning under your RFC, warning the
user of a possibly uninitialized $x. Okay. Next:
my $x;
if (something)
{
$x = 1;
}
else
{
$x = 2;
}
my $y = $x;
Would this give the same warning? Would it notice that $x is set
in both branches of the condition?
Worse:
my $x;
if (something)
{
$x = 1;
}
if (!something)
{
$x = 2;
}
my $y = $x;
I presume this would generate a warning under your RFC, right?
Since I would guess the compiler shouldn't be required to notice
that one condition is the inverse of the other?
I'm not sure I like the above construct not behaving identically
to the second case (if...else...) above...
Moving on:
my $x;
if (thing1)
{
$x = 1;
}
elsif (thing2)
{
$x = 2;
}
elsif (thing3)
{
$x = 3;
}
else
{
$x = 4;
}
my $y = $x;
Warnings, or no?
How about:
my ($x, $i);
for ($i=0; $i<10; $i++)
{
$x .= $i;
}
my $y = $x;
Now, I can look at that and see that $x will be '0123456789', but
the compiler can't be expected (imho) to know whether the loop
condition will ever execute, so under your RFC it will generate a
"possibly uninitialized" warning, right?
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 12 (v3) variable usage warnings
Steve Fink, via the Perl6 Librarian, wrote:
>=head2 EXAMPLE
>
>1 my ($x, $y, $z, $r);
>2 $z = 1;
>3 f(\$r);
>4 my $logfile = "/tmp/log";
>5 $x = 1 if cond();
>6 print $x+$y;
>7 undef $z;
>8 print $z;
>
[...]
>No warning is issued for C<$r> because any variable whose reference is
>taken may be used and/or assign to through the reference.
Perl is not C. Perl passes parameters to subroutines by reference.
Example:
sub initialize_to_seven
{
$_ = 7 foreach @_;
}
my ($a, $b, $c);
initialize_to_seven ($a, $b, $c);
print "$a, $b, $c\n";
------
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 263 (v1) Add null() keyword and fundamental data type
Glenn Linderman wrote: >Eric Roode wrote: > >> 1. You don't say in your RFC, but I'm guessing, that a null value >> evaluates to false in a boolean context. Correct? > >I would expect it to be considered false. Logical expressions involving >NULL are defined to be "undefined", actually, which is not considered true. Hmmm. So: $a = null; $b = ($a == 42); print defined($b)? "defined" : "not defined"; would print "not defined", maybe? [snip] >$NULL = "NULL"; > >could be the default; and $NULL could be set to anything desired to be the >stringization for NULL. Setting $NULL to NULL would be special, and >equivalent to the $NULL = "NULL". Setting $NULL to undef could result in >warnings during stringization of NULL. And setting $NULL=null could result in infinite loops :-) -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 12 (v2) variable usage warnings
Steve Fink wrote: >I am merely suggesting that the compiler detect, when it can, that >you're trying to use the value of a variable without ever having >assigned a value to that variable. And in THAT message, you had better >know the name of the variable, since it's the basis of the analysis. And >yes, it only handles simple named variables. Um, "when it can"? Isn't this considered a Hard Problem by the computer scientists? >Example: > >1 my ($x, $y, $z); >2 $z = 1; >3 my $logfile = "/tmp/log"; >4 $x = 1 if cond(); >5 print $x+$y; >6 undef $z; >7 print $z; > >--> use of uninitialized variable $y in line 5 (compile time) >--> possible use of uninitialized variable $x in line 5 (compile time) >--> variable $logfile defined in line 3 but never used (compile time) >--> use of undefined value in line 7 (run time) How about: foo(); $x = 1 unless defined($x); print $x; Generate a warning, or not? Or: foo(); print $x; Generate a warning, or not? Which one? Remember, foo() may initialize $x. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 263 (v1) Add null() keyword and fundamental data type
1. You don't say in your RFC, but I'm guessing, that a null value evaluates to false in a boolean context. Correct? 2. In your abstract, you say that undef is used to mean that a variable's value is undefined, which I presume means uninitialized. You say that null would provide a useful way to indicate that a variable's value is known to be unknown or not applicable. Then, at various places in the RFC, you use a hypothetical use initialize 'null'; construct to initialize all new variables to null. Doesn't that defeat the purpose, and make null equivalent to undef? 3. Your RFC does not specify how a null value stringizes. What is the output from: $a = null; print "a is '$a'"; I can see two possibilities: "a is ''" and "a is 'null'". I personally would greatly prefer the first. Would the use of a null value in a string generate a warning, as an undef value does now? -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 258 (v1) Distinguish packed binary data from printable strings
Nathan Wiger wrote: > >One thing that Nat will soon be releasing is an RFC on strict typing. >I'll also have one (hopefully) on an embedded tie-like solution that >will allow you to create your own variable types. With these you would >conceivably be able to say: > > use strict 'types'; > my packed $b = 5; # oops! Um, I *think* the following suggestion falls in this category. The other day a coworker tracked down a bug that boiled down to: if ($string != '') Obviously, the operator should have been "ne". I was going to suggest that comparison operators, where one operand is a constant, should produce a warning message when the operator is inappropriate. I am sure that sometimes you'll want to do if ($foo gt 5) but for the most part, that's the Wrong Thing. (That would be better written as "if ($foo gt '5')" anyhow). In light of Nate's comment above, maybe it would be approporiate to have this warning under "use strict 'types'" only; or perhaps it would normally be a warning, but under "use strict 'types'", it would be a compile-time error. If so, please add this suggestion to the RFC. If not, should I make a separate RFC? -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Michael Schwern wrote:
>See, I never understood this. If you're indenting the terminator, it
>implies you're also indenting the here-doc text. I mean, this doesn't
>make any sense:
>
>{ { { {
>print <I don't know what their
>gripe is. A critic is
>simply someone paid to
>render opinions glibly.
>TAG
>} } } }
>
>Right? You're not going to just indent the terminator because you
>can. Its going to go along with indenting the text.
>
>So indenting the terminator and indenting the text are linked. If you
>do one, you want to do the other.
Don't tell me what I want to do :-)
$chunk1 = <
text that's in the table cell
CHUNK1
$chunk2 = <
text that's in another table cell
CHUNK2
$chunk3 = <
CHUNK3
The here-doc terminators all line up with the perl code.
The generated program is nicely indented relative to the left margin.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Nathan Wiger wrote: > >I also suggest that no whitespace stripping/appending/etc/etc be done at >all. If I write: [...deletia...] >But this shouldn't be implicit in the language. That's a good argument for having a separate operator for these "enhanced here docs", say <<<, rather than chucking the whole idea out the window. ------ Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Richard Proctor made some excellent comments, and asked: >When measuring whitespace how does the system treat tabs? (be realistic >and dont FLAME) I suggest that there be NO tab/space conversion. Not 8 columns, not 4 columns, nothing. If the here doc terminator has four tabs preceding it, then four tabs should be stripped from each of the lines in the string. If the terminator has one tab and four spaces, then one tab and four spaces should be stripped from each of the lines. Mixing spaces and tabs is basically evil, but if you're consistent about it, it's your own rope for you to trip over or hang yourself. I set my tab stops to four columns; at least one of my coworkers sets his tab stops to eight columns. We edit the same code with no problems. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: Drop here docs altogether? (was Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs))
Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
languages without here docs. Example:
print <= '"'))
{
// rest of code to be generated later.
CODE_SNIPPET
There's a chunk of code for which '', "", qq//, qq<>, qq{}, are all
inadequate. This kind of code happens A LOT in web programming.
I do not want to have to examine all of my generated strings to see
what quoting character I can use this time around, and I do not want
to risk breaking my program whenever I change the text in a code
snippet ("oops! I added a bracket. gotta change the quoting character!").
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
RE: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
Garrett Goebel wrote:
>Could someone shoot down or prop up the following:
>
>* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Ariel Scolnicov wrote: >1. It requires the perl parser know about indentation. Of course we > all know that tabs are 8 characters wide (I myself make a point of > bludgeoning anyone who says otherwise), but do we really want to > open this can of worms? Not so fast with those 8-column tabs. (But, I do NOT want to start a religious war here). At my company, we're required to have one tab stop, no spaces, between indentation levels. Boss likes 8 columns, which to my mind is way too much -- it doesn't take too many levels for your code to march off the right side of the screen. I prefer four columns. No problem -- I make my tab settings four columns. Which, for purposes of here docs and this proposal, works just as well. The REAL sinners are those who mix spaces and tabs. THAT's evil. :-) -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Glenn Linderman wrote: >Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing >stuff after the terminator? Even the ";" afterward seems useless... the ";" >should be at the end of the statement, not the end of the here doc. The only >improvement to here docs I see in this RFC is to allow whitespace before/after >the here doc terminator. The rest is handled adequately and consistently today, >and Tom's dequote is adequate to eliminate leading white space... especially >among people who cannot agree that a tab in a file means "mod 8" (which it >does). The semicolon, as you point out, belongs on the statement at the head of the here doc. The proposal to allow a semicolon at the end is mere window-dressing. Aesthetics only. Personally, I have used editors and pretty-printers that could handle here-docs except that they thought that the "statement" without a semicolon meant that all subsequent lines should be indented. I have had to resort to: $foo = <
Re: Conversion of undef() to string user overridable for easy debugging
>Imagine that you could easily override the conversion of undef() into a >string, so that when stringified it returns something like "#UNDEF#" >instead of just an empty string. That would make debugging far more >easy: take a look at the output, and search for this sentinel string. This would HAVE to be a very optional feature. I rely on undef converting to a null string in many, many programs. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: Don't require braces
Raptor wrote:
>
>problem can be solved again in this way i.e. shell like syntax :
>
>while $i > 10 && $i++ && print $i;
>
>mean this
>
>while ($i > 10 ) {$i++; print $i};
But:
$i=-5; while ($i<=5) && $i++ && print $i;
doesn't mean the same as:
$i=-5; while ($i<=5) {$i++; print $i}
even if we ignore the fact that "while (...) &&" is a weird construct
(what is the truth value of a while statement?).
When $i is zero, the print won't happen in the first statement.
I too would like C's one-line if/for/while syntax as a matter of
convenience, but I grudgingly admit that Perl's way more than
makes up in unambiguity what it loses in convenience.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Chaim Frenkel wrote:
>
>TC> And even in those rare places where they do, to use them as such
>TC> is gratuitously counter-efficient.
>
>Why? How is
>
> @main_list = ;
> @more_stuf = ;
>
> @just_to_do_a_job{@main_list} = ();
> @just_to_do_a_job{@more_stuff} = ();
>
> @main_list = keys %just_to_do_a_job;
>
>more or less efficient than
>
> @main_list union= @more_stuff;
>
>Both have to go through the same amount of work ("work is conserved")
>but one is more efficient in terms of the user's brainpower.
Why not simply do
@main_list = (@main_list, @more_stuf); ?
What? You say you don't want duplicates in the resulting list?
Why didn't you say so?
So how is the hypothetical union operator going to check for dupes?
Loop over each element of the first array, checking whether it is
contained somewhere in the second array (by looping over it)?
Dude, O(m*n) ain't good.
Or perhaps you think that Perl should do for you what you're not
willing to do for yourself: it should create two temporary hashes
to do the collision detection. A lookup table is a great way to
find collisions, right? And a hash is a great way to implement a
lookup table, right? Yes! So Perl should internally create hashes
to do your union operator. And intersection operator. And whatever.
But don't you think creating and destroying all those temporary
hashes is going to be a waste of your computer's time? I mean, I
know hardware is cheap and all, but
Why not create a permanent lookup table of all the elements of each
of your sets. Wouldn't that be a good optimization? Sure! So instead
of:
@first_list = qw/one two three/;
@second_list = qw/two four six/;
create hashes:
%first_set = map {$_=>()} qw/one two three/;
%second_set = map {$_=>()} qw/two four six/;
Don't like that ugly syntax? Can't remember it? Here's a free sub for
you:
sub create_set { map {$_=>()} @_ }
"But," I hear you wail, "I like using arrays for sets! It makes sense
to me!". Tell me, Chaim, how DO you test for membership in your array
world? grep?
if (grep {$_ eq 'three'} @first_list)
Talk about ugly. And slow: O(n/2). What's wrong with:
if (exists $first_set{three})
Simple, elegant, fast. O(1), more or less.
You think hash functions are ugly? Then wrap them in functions so
you don't have to look at them.
How *do* you propose to implement union and intersection with arrays,
internally in Perl? Any idea? Double-looping over the arrays is
horribly slow. Forcing Perl to create and destroy lookup tables each
time is wasteful. Did you have a better idea?
If you want Perl to have core support for widgets like union and
intersection, that's one thing. Make a case for it. But you have
repeatedly tried to make a case for arrays as set representations
and you have not made a good case yet. Your least-bad argument has
been that arrays "make more sense to you" than hashes. Does execution
time mean nothing to you?
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Ariel Scolnicov wrote: >Eric Roode <[EMAIL PROTECTED]> writes: > >[...] > >> The underlying problem is that arrays don't make SENSE as an >> implementation for sets. What is the value of: > >But all of the following DO make sense as implementations for sets, >depending on your application: > >* Sorted lists (1, 1, 2, 2, 3, 3, 4, 5) is as invalid a set as (1, 2, 3, 1, 2, 3, 4, 5). >* Lists with guaranteed unique elements Yes -- we call these "hash keys" ;-) Anything else is reinventing the wheel. >* Lists (as implementations for multisets, with you favourite > definitions of the operations) Not sure I follow you here. >* Hashes Yes. >* Bit vectors Yes, I forgot about these. Thanks for bringing this up. _Mastering Algorithms_ goes into much detail about how to represent and manipulate sets as bit vectors. >* Integers Only inasmuch as the integers are used to store bit vectors, which see above. >* Trees >* Balanced trees No built-in language support for these structures, unless you're proposing adding such...? [...] >When I started reading this thread, I was *sure* it would be >immediately clear that sets are bit vectors, drawn on some >pre-specified world! Bit vectors do have their problems, vis a vis mapping the set universe onto the bit positions, adding and deleting elements from the set universe, etc. But they can be a useful way of representing sets, so thanks for bringing them up. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Gael Pegliasco wrote: > >> So what if the man wants >> >> @foo = @bar union @baz; >> @foo = @bar intersetcion @baz; >> >> This is a lot more of a direct map than the twiddling with hashes. >> >> How are you drawing the line. Where does giving the user more power >> than a turing machine stop. >> >> > > >Yes Baby ! > >This sound good for me ! > >I'm completly ok with this new syntax, it is much better than a function >! The underlying problem is that arrays don't make SENSE as an implementation for sets. What is the value of: (1, 2, 3, 1, 2, 3) union (2, 3, 4, 5) ? is it (1, 2, 3, 4, 5)? is it (1, 2, 3, 1, 2, 3, 4, 5)? (1, 2, 3, 1, 2, 3) is NOT a valid set. The problem GOES AWAY if you make a small mental shift and deal with HASHES instead of ARRAYS. (1, 2, 3, 1, 2, 3) CANNOT be the keys of a hash -- the language ALREADY enforces this! Why reinvent the wheel when there's already half a wheel there? IF new keywords "union" and "intersection" (and perhaps others) are to be added to the language, they should be functions that operate on the KEYS of HASHES, not on arrays! And, imho, these are special-purpose functions that are going to be extremely useful to a fairly small set of users (math folks), and are going to be somewhat useful to another small set of people, and fairly useless to the majority of Perl programmers. That screams "module" to me, not "new core features". -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: $a in @b
Randal Schwartz wrote:
>We really need a clean way to distinguish those four cases:
>
>"yes" and keep going
>"no" and keep going
>"yes" and abort after this one
>"no" and abort after this one
>
>What would you have "last" do? And how would you distinguish "the
>other one"?
Sounds like people are trying to fit two booleans into one expression.
Probably what is needed is for grep to have two control expressions:
one to determine whether each element is selected to be put into the
output list (grep's current boolean expression), and one to determine
whether grep should continue execution.
Perhaps a new "pass" keyword should be added, which passes the
current list element through the filter.
@L = (1, 2, 3, 10, 3, 2, 1);
@l = grep {pass if $_>1; last if $_>9} @L;#--> (2, 3, 10)
@l = grep {last if $_>9; pass if $_>1} @L;#--> (2, 3)
@l = grep {pass if $_>1; next if $_>9} @L;#--> (2, 3, 10, 3, 2)
@l = grep {next if $_>9; pass if $_>1} @L;#--> (2, 3, 3, 2)
A grep block with no explicit 'pass' would pass if the last expression
in the block evaluates to true, just as grep does now:
@l = grep {$_>9} @L; # same as:
@l = grep {pass if $_>9}; #--> (10)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 195 (v1) Retire chop().
Richard Proctor wrote: >>[Eric Roode wrote] >> Perhaps $/ and $\ should become per-filehandle variables, and >> there should be some way to set autochomp-on-read per filehandle, >> and auto-newline-on-output per filehandle. > >I can see a small benefit for autochomp-on-read but none whatsoever >for auto-newline-on-output (even if you could decide when to send it). I use it all the time -- indirectly, for one-liners, via the -l option. perl -nle '-e && print "$_ exists"'
Re: RFC 195 (v1) Retire chop().
Does anyone EVER use chomp() except shortly after reading a line of input from a stream? No? Perhaps $/ and $\ should become per-filehandle variables, and there should be some way to set autochomp-on-read per filehandle, and auto-newline-on-output per filehandle. Then, if anyone ever needs to remove $/ from the end of a string at any other time, they can s,$/$,, -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145 (alternate approach))
Richard Proctor wrote:
>
>I think what is needed is something along the line of :
>
> $re = qz{ '(' \$re ')'
>| \$re \$re
>| [^()]+
> };
>
>Where qz is some hypothetical new quoting syntax
Well, we currently have qr{}, and ??{} does something like your \$re.
Warning: radical ideas ahead.
What would be useful, would be to leave REs the hell alone; they're
great as-is, and are only getting hairier and hairier. What would be
useful, would be to create a new non-regular pattern-matching/parsing
"language" within Perl, that combines the best of Perl REs, lex,
SNOBOL, Icon, state machines, and what have you.
$string =~ qz< $start_numF:No_Num# Start with a number
-(\d|) => $end_num F:One_Num # Look for an end num
{$start_num > $end_num?}S:Got_Range # comparison
No_Num: (\$\w+) => $start_var S:Its_A_Var
exit (status=error yada yada)
One_Num: etc etc
PARSE_THE_HELL_OUT_OF_THIS
This new sub-language would, like SNOBOL, allow you to piece together
patterns into powerful expressions, would be more readable than Perl's
line-noise expressions (which are only getting worse with (?this) and
(?that)!), would allow recursive processing, maybe even looping.
Now _that_ would rule :-)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
