combined with a zip operator, e.g. [\Z+], the first intermediate value
> is wrong:
>
> say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300);
> # got: ((6) (11 22 33) (111 222 333))
> # expected: ((1 2 3) (11 22 33) (111 222 333))
>
> Reduction with hyper operators like [\<<
combined with a zip operator, e.g. [\Z+], the first intermediate value is wrong:
say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300);
# got: ((6) (11 22 33) (111 222 333))
# expected: ((1 2 3) (11 22 33) (111 222 333))
Reduction with hyper operators like [\<<+>>] se
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:29 PM
To: perl6-users
Subject: Re: zip mystery
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users
Subject
On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo <mailto:toddandma...@zoho.com>> wrote:
But this does not:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/*", :out);
warning: name not matc
On Mon, Jul 17, 2017 at 8:18 PM, ToddAndMargo wrote:
> But this does not:
>
> my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
> "$DiagDir/*", :out);
>
> warning: name not matched: /opt/xxx/yyy/zzz/diags
T,
What happens when you do this?
my $proc = run('zip', '-j', $ZipLog, $CimLog, $LogFile, $DiagDir ~ '/*', :out);
Mark
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users
Subject: z
-Original Message-
From: ToddAndMargo [mailto:toddandma...@zoho.com]
Sent: Monday, July 17, 2017 8:19 PM
To: perl6-users
Subject: zip mystery
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$Dia
Hi All,
This runs:
my $proc = run('zip', '-j', "$ZipLog", "$CimLog", "$LogFile",
"$DiagDir/BlankFile.txt", :out);
And this also works (bash)
zip -j eraseme.zip /opt/xxx/yyy/zzz/diags/*
But this does not:
my $proc = run('
:
M S04-control.pod
Log Message:
---
[S04] Add missing parenthesis in zip() example
Commit: 21525aab69789f0d7a00640d75ae332d4fad9e73
https://github.com/perl6/specs/commit/21525aab69789f0d7a00640d75ae332d4fad9e73
Author: niner
Date: 2016-01-17 (Sun, 17 Jan 2016
For the records: TimToady++ today explained the underlying problem (final *
NYI):
< bartolin> I've got a question about zip: S03 says "By default the zip
function reads to the end of the shortest list, but a short list may always be
extended arbitrarily by putting *
There was already a ticket for this problem (#122230).
Also the test in question was a duplicate of a test in S03-metaops/zip.t --
which is handled in ticket #122230.
I removed the redundant test from S03-operators/misc.t and I'm closing this
ticket.
the
last element of a list extends this list for infix: operator:
# L
#?rakudo todo "nom regression"
#?niecza todo
{
is (1, 2, * Z ).join('|'),
'1|a|2|b|2|c|2|d',
'A * as the last value extends lists for infix: (zip)';
}
This does currently not work:
> 1, 2, * Z
1 a 2 b * c
On Fri Jul 04 19:54:26 2014, coke wrote:
> Several tests in t/spec/S03-metaops/zip.t were marked as "nom
> regression" and either fail or explode. See file for tests marked with
> this ticket number.
>
Also see S03-metaops/hyper.t
--
Will "Coke" Coleda
# New Ticket Created by Will Coleda
# Please include the string: [perl #122230]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=122230 >
Several tests in t/spec/S03-metaops/zip.t were marked as "nom
regression" and either fail
-concurrency.pod
Log Message:
---
spec zip-latest
:
M S17-concurrency.pod
Log Message:
---
Supply.(zip|merge) can be called as class method
:
M S17-concurrency.pod
Log Message:
---
Add examples for Supply.(merge|zip)
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #119337]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=119337 >
r: zip
rakudo d9f8d6: OUTPUT«(timeout)»
* masak submits rakudob
On Thu Jun 17 00:38:17 2010, ciphertext wrote:
> ciphertext: rakudo: (1,2,3 Z 4,5,6).perl.say
> p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)»
> ciphertext: rakudo: (1,2,3 Z[,] 4,5,6).perl.say
> p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)»
> pmichaud: > (1,2,3 Z[,] 4,5,6).perl.say
> pmich
-operators.pod
Log Message:
---
[S03] Fix ttiars in Zip operators
# New Ticket Created by J S
# Please include the string: [perl #75818]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75818 >
ciphertext: rakudo: (1,2,3 Z 4,5,6).perl.say
p6eval: rakudo c9ee2e: OUTPUT«(1, 4, 2, 5, 3, 6)»
c
# New Ticket Created by "Mark J. Reed"
# Please include the string: [perl #73816]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73816 >
> my @a = (1,2) Z (3,4); say @a.perl
[1, 3, 2, 4]
Per S03, that should be [[1,3],[2,4
Rakudo HEAD as of fed46878c492186a006c7a5a8500befda962714c:
X (1,2) -> [['a',1],['a',2],['b',1],['b',2]]
Z (1,2) -> ['a', 1, 'b', 2]
Per S03, the second one should yield [['a',1],['b',2]]. I'd expect
the two ops to flatten the same amount, regardless.
Also, the above is a manual Perlificatio
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #64474]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64474 >
Hi there,
> say ( Z [1,*]).perl
["a", 1, "b", *] # wrong, should be: ["a", 1, "b", *, "
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #60898]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60898 >
10:04 < moritz_> rakudo: say ( Z 1..10).perl
10:05 < p6eval> rakudo 33300: OUTPUT[e
On Fri, Oct 21, 2005 at 04:04:25PM -0600, Luke Palmer wrote:
: However, if I get my wish of having zip return tuples, then it can be
: left-associative. But since it interleaves instead, making it left-
: or right-associative gives strange, incorrect results.
I expect zip ought to bundle up into
At 5:32 PM -0400 10/21/05, Mark Reed wrote:
Is there a CPAN module which provides the functionality of ¥/zip() for
Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard
to write, of course, just wondering if it's been done . . .
The List::MoreUtils CPAN module do
Does TYE's Algorithm::Loops's mapcar() provide the basic functionality
of what you're looking for?
Rob
On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote:
> Is there a CPAN module which provides the functionality of ¥/zip() for
> Perl5? I don't see anything ob
On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote:
> Hm. This brings up another point, which may have been addressed . . .
>
> The Python function and Ruby array method zip() both accept any number of
> arrays to interleave:
>
> >>> zip([1,2,3],[4,5,6],[7,8,9])
Hm. This brings up another point, which may have been addressed . . .
The Python function and Ruby array method zip() both accept any number of
arrays to interleave:
>>> zip([1,2,3],[4,5,6],[7,8,9])
[(1, 4, 7), (2, 5, 8), (3, 6, 9)]
irb(main):001:0> [1,2,3].zip([4,5,6],[7,8,9])
Is there a CPAN module which provides the functionality of ¥/zip() for
Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard
to write, of course, just wondering if it's been done . . .
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
>
> is something you will probably not see very often, it's still legal
> Perl, even though it looks asymmetric. This too makes finding the
> solution in arguments a non-solution.
Don't be silly. Th
Dave Whipp skribis 2005-10-06 9:57 (-0700):
> Given that my idea about using optional binding for look-ahead didn't
> fly, maybe it would work here, instead:
> @a Y @b -> $a, $b { ... } # stop at end of shortest
> @a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
> @a Y @b ->
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
> If we make zip return a list of tuples rather than an interleaved
> list, we could eliminate the final 1/3 of those errors above using the
> typechecker. That would make the for look like this:
>
> for @a
Luke Palmer wrote:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anywa
do when the lists are unbalanced." Now, that may just
be a behavior of #perl6ers, but I'm extrapolating. It means that
there isn't an assumption, and if they weren't #perl6ers, they'd RTFM
about it.
When I learned Haskell and saw zip, I asked the very same question
Luke wrote:
>>Once C stops zipping, if any other element has a known finite
>>number of unexhausted elements remaining, the fails.
>
> Wow, that's certainly not giving the user any credit.
Actually, I want to be careful because I give the users too much credit. For
imagination.
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> So I now propose that C works like this:
>
> C interleaves elements from each of its arguments until
> any argument is (a) exhausted of elements I (b) doesn't have
> a C property.
>
> Once C stops zipping, if any
David Storrs asked:
If you want a multiway zip with
differing fillins, can't you do this?
@foo = 1..10 ¥:fill(0) 'a'..c' ¥:fill('x') ¥ 1..50;
I don't think that works. For example, why does the :fill(0) of the first ¥
apply to the 1..10 argument
On Oct 5, 2005, at 7:49 PM, Damian Conway wrote:
Providing a :fillin() adverb on C is a suboptimal solution,
because it implies that you would always want to fill in *any* gap
with the same value. While that's likely in a two-way zip, it seems
much less likely in a multiway zip
ikely in a two-way zip, it seems much less likely in a multiway zip.
So I now propose that C works like this:
C interleaves elements from each of its arguments until
any argument is (a) exhausted of elements I (b) doesn't have
a C property.
Once C stops zippin
t expect the
default zip behavior to stop zipping after the least amount of elements.
On 10/5/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> Damian Conway skribis 2005-10-05 10:05 (+1000):
> > I suspect that the dwimmiest default would be for C to stop zipping
> at
> > the leng
Damian Conway skribis 2005-10-05 10:05 (+1000):
> I suspect that the dwimmiest default would be for C to stop zipping at
> the length of the shortest finite argument. And to fail unless all finite
> arguments are of the same length.
This is a nice compromise.
But what if you cannot know whethe
From: Luke Palmer <[EMAIL PROTECTED]>
Date: October 5, 2005 1:48:54 AM EDT
To: David Storrs <[EMAIL PROTECTED]>
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = (&
On Tue, 4 Oct 2005, Eric wrote:
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
Well, OTOH undef is now a more complex object than it used to be, so there
may be cheap workarounds. Of course one
Subject: Re: zip: stop when and where?
Reply-To: Luke Palmer <[EMAIL PROTECTED]>
On 10/4/05, David Storrs <[EMAIL PROTECTED]> wrote:
How about:
@foo = ('a', 'b', 'c');
for @foo ¥ 1..6 :fillin(undef)# a 1 b 2 c 3 undef 4 undef 5
undef 6
for @foo
ay.elems..Inf
So I think I'm pretty much with Damian on this one. I don't like the
idea of it discriminating between finite and infinite lists, though.
What about things like =<>, for which it is never possible to know if
it is infinite?
I don't think people make assumpt
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... ->
Juerd wrote:
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... -> $foo, $i { ... }
Pugs currently does b.
I agree that C should have named
I see your point. Option b does suggest that you can read ahead in a
"blocked" list and get undef's. If I had to choose just one, I think
I'd opt for d, but having two zip's one acting like c and one like d
might be useful. Then, of course, my first thought was wrong. This one
may well be, too.
--
On Tue, Oct 04, 2005 at 09:00:15PM +0200, Juerd wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y
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 optio
That (b) certainly seems like the sensible option to me. My second
choice would be d.
A nice thing about c is that it leaves open the possibility of lazy
evaluation (zip as much of the lists as you can, leaving open the
possibility of picking up the process later). But I still prefer b.
Maybe
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -
What should zip do given 1..3 and 1..6?
(a) 1 1 2 2 3 3 4 5 6
(b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
(c) 1 1 2 2 3 3
(d) fail
I'd want c, mostly because of code like
for @foo Y 0... -> $foo, $i { ... }
Pugs currently does b.
Juerd
--
http://convolution.nl/maak_juerd_blij.h
On Mon, Aug 01, 2005 at 01:13:52PM +0200, "TSa (Thomas Sandlaß)" wrote:
: BTW, you didn't mean originally:
:
: say zip (@odd), (@even); # prints 13572468 or 12345678?
That doesn't work, since () in list context does not enforce scalar context.
It's exactly equiva
HaloO,
Luke Palmer wrote:
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
In general, (@foo, @bar) returns a new list with the element joined,
i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTE
LP> my $x = (1,2,3,4,5);
LP> Looks like an error more than anything else.
'Perl 6 and Parrot Essentials' think different ;-)
--
___
Andrew, [EMAIL PROTECTED]
___
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> In general, (@foo, @bar) returns a new list with the element joined,
> i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
> you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
> [EMAIL PROTECTE
Hi,
TSa (Thomas Sandlaß orthogon.com> writes:
> Ingo Blechschmidt wrote:
> > say zip (@odd, @even); # &zip gets only one argument, the flattened
> > # list ( @odd, @even), containing the
>
> Why flattened? Shouldn't that be *
HaloO,
Andrew Shitov wrote:
TTS> BTW, you didn't mean originally:
TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?
That is exactly like with similar printing result of sub() call:
print sqrt (16), 5; # shout print 45.
That all hinges on the type of the symb
HaloO,
Ingo Blechschmidt wrote:
Whitespace is significant:
say zip @odd, @even;# &zip gets two arguments, result is
# 12345678.
say zip(@odd, @even); # &zip gets two arguments, result is
# 12345678.
say zip (@od
TTS> BTW, you didn't mean originally:
TTS>say zip (@odd), (@even); # prints 13572468 or 12345678?
That is exactly like with similar printing result of sub() call:
print sqrt (16), 5; # sho
HaloO,
Andrew Shitov wrote:
Is it possible to avoid significance of whitespaces?
Yes, with:
say zip .(@odd, @even);
Looks like a method and *is* a method in my eyes.
First &zip is looked-up and then bound as block owner.
Arguments are of course two array refs to @odd and @
Is it possible to avoid significance of whitespaces?
I think, such an aspect of Perl 6 would be awful.
IB> Whitespace is significant:
IB> say zip(@odd, @even);
IB> say zip (@odd, @even);
--
___
Andre
Hi,
Andrew Shitov wrote:
> I tried zip under pugs.
>
> my @odd = (1, 3, 5, 7);
> my @even = (2, 4, 6, 8);
> my @bothA = zip @odd, @even;
> print @bothA;
>
> This code prints 12345678 as expected.
>
> After parenthesis were used to group zip a
Hi,
I tried zip under pugs.
my @odd = (1, 3, 5, 7);
my @even = (2, 4, 6, 8);
my @bothA = zip @odd, @even;
print @bothA;
This code prints 12345678 as expected.
After parenthesis were used to group zip arguments, results changes
to 13572468. Is it right
Goplat wrote:
I have quite a few fonts, the only one I can find where | is a broken bar is
"Terminal", a font for DOS programs that uses the cp437 charset, which is
incompatable with latin1 (« and » are AE and AF instead of AB and BB) and it
dosen't even have a ¦. So, it dosen't seem like a proble
Chaim Frenkel wrote:
> Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
>
Yes. RFC 148 can also partition (RFC 91). I've updated RFC 91 to also allow
a 3rd argument that gives a step size--I haven't checked whether reshape()
can do this. The updated RFCs 90
Aren't RFC 90 (zip/unzip) and RFC 148 (reshape) really the same?
Isn't reshaping the basic operation of interest?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
70 matches
Mail list logo
