Has anyone looked at a Perl6 module for GIMP?
GIMP natively uses a Scheme-like interface, but there are Perl and
Python modules.
# New Ticket Created by Daniel Green
# Please include the string: [perl #128969]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128969 >
Paraphrasing from IRC where my first comment starts here:
http://irclog.perlgeek.de/perl
# New Ticket Created by Timo Paulssen
# Please include the string: [perl #128968]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128968 >
You can .take for ^10, but you have to write .&emit for ^10; that seems
inconsistent to
I'm trying to think how to put this better.
In effect, Scalar isn't so much a mutable container object, as it is a bit
of magic that changes the fundamental identity of the thing "containing"
it, from immutable to mutable. It's sufficiently magic that, barring .VAR,
the only way to make one is to
Brandon Allbery via RT wrote:
>I did not mean "You created something equivalent to a mutable-key Pair".
>You *precisely* created a Pair that has a mutable component, in something
>that is not intended to be mutable.
That view doesn't work for the situation in [perl #128948].
It's quite intentiona
On Tue, Aug 16, 2016 at 5:11 PM, Zefram wrote:
> Brandon Allbery via RT wrote:
> >I think .VAR can remain visible as long as the Scalar can't escape from
> it.
>
> What would it yield if not the Scalar? That's the essence of .VAR
> expressions. To prevent the Scalar escaping, you can't have tha
See discussion at http://irclog.perlgeek.de/perl6-dev/2016-08-16#i_13034703
> On 16 Aug 2016, at 23:11, Zefram wrote:
>
> Brandon Allbery via RT wrote:
>> I think .VAR can remain visible as long as the Scalar can't escape from it.
>
> What would it yield if not the Scalar? That's the essence o
Reverted my Pair.new fix with b00d92d
Suggest we mark this as stalled and/or @LARRY
> On 16 Aug 2016, at 23:11, Zefram wrote:
>
> Brandon Allbery via RT wrote:
>> I think .VAR can remain visible as long as the Scalar can't escape from it.
>
> What would it yield if not the Scalar? That's the
Brandon Allbery via RT wrote:
>I think .VAR can remain visible as long as the Scalar can't escape from it.
What would it yield if not the Scalar? That's the essence of .VAR
expressions. To prevent the Scalar escaping, you can't have that
available as an expression type.
>(Although I do wonder w
On Tue, Aug 16, 2016 at 5:00 PM, Zefram wrote:
> If .VAR and the Scalar class are hidden
> behind a MONKEY-SEE-NO-CONTAINER pragma then I'll accept that they're
> not part of the supported language.
>
I think .VAR can remain visible as long as the Scalar can't escape from it.
(Although I do wond
Brandon Allbery via RT wrote:
>But you have to go into NQP to do that; you already took off all the
>safeties, and whatever happens is your own fault.
Yes, and to be clear I'm satisfied with that kind of distinction between
language and implementation. If .VAR and the Scalar class are hidden
behi
On Tue, Aug 16, 2016 at 4:45 PM, Elizabeth Mattijsen wrote:
> But then you still haven’t defeated it, as you can do nqp::create(Scalar).
But you have to go into NQP to do that; you already took off all the
safeties, and whatever happens is your own fault. (Which is why TimToady
aliased nqp to M
> On 16 Aug 2016, at 22:40, Brandon Allbery wrote:
>
> On Tue, Aug 16, 2016 at 4:37 PM, Zefram wrote:
> Elizabeth Mattijsen via RT wrote:
> >dd9b760 makes it impossible to create a Pair with a mutable key.
>
> Doesn't work. It defeats my original test case, but you're not actually
> type-cons
On Tue, Aug 16, 2016 at 4:37 PM, Zefram wrote:
> Elizabeth Mattijsen via RT wrote:
> >dd9b760 makes it impossible to create a Pair with a mutable key.
>
> Doesn't work. It defeats my original test case, but you're not actually
> type-constraining the key, you're only removing a container wrapper
Elizabeth Mattijsen via RT wrote:
>dd9b760 makes it impossible to create a Pair with a mutable key.
Doesn't work. It defeats my original test case, but you're not actually
type-constraining the key, you're only removing a container wrapper.
So by adding a second container:
> my $a = 3; my $A = $
> On 16 Aug 2016, at 22:10, Brandon Allbery wrote:
>
> On Tue, Aug 16, 2016 at 4:00 PM, Zefram wrote:
> That's what I think it is. I'm mystified as to what you think I think
> it is.
>
> Because of all the behaviors central to it being the implementation of a
> mutable value, that you have re
On Tue, Aug 16, 2016 at 4:00 PM, Zefram wrote:
> That's what I think it is. I'm mystified as to what you think I think
> it is.
>
Because of all the behaviors central to it being the implementation of a
mutable value, that you have reported as bugs. They're not bugs, they are
proof that Scalar
Brandon Allbery via RT wrote:
> *Scalar is not what you think it is*. It is
>*precisely* the implementation of mutable containers,
That's what I think it is. I'm mystified as to what you think I think
it is.
-zefram
Brandon Allbery via RT wrote:
> the likely outcome of your insistence on
>treating it as first class is that .VAR will end up being removed or
>restricted to keep the Scalar from escaping
I'm treating as first class those things that are presented as first
class. T
On Tue, Aug 16, 2016 at 3:30 PM, Zefram wrote:
> FWIW, I think Scalar is a good reification, and the language would
> be better with it being visible, provided that everything relevant
> can handle it.
>
It can't handle it. The implementation is precisely that needed for
mutables; your multiple
Fixed with ba20d34 , tests needed.
> On 10 Jul 2016, at 22:58, Zoffix Znet (via RT)
> wrote:
>
> # New Ticket Created by Zoffix Znet
> # Please include the string: [perl #128595]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.ht
Fixed with 1728139 , tests needed, MasterDuke17++ for actual code.
> On 05 Oct 2015, at 08:18, quester (via RT)
> wrote:
>
> # New Ticket Created by quester
> # Please include the string: [perl #126264]
> # in the subject line of all future correspondence about this issue.
> # https://rt.pe
On Tue, Aug 16, 2016 at 12:39 PM, Zefram
wrote:
> If I construct a Pair whose key is a Scalar object,
Scalar objects are a leaked internal detail that aren't intended for direct
use (.VAR is an avowed hack, and the likely outcome of your insistence on
treating it as first class is that .VAR wil
On Fri Jul 22 17:15:04 2016, cookbook_...@yahoo.co.jp wrote:
> See the following results.
>
> $ perl6 -e 'say (1 R, 2 R, 3 R, 4)'
> (2 1)
> $ perl6 -e 'say (1, 2, 3, 4)'
> (1 2 3 4)
>
> I think that the resulting list of the 1st example should be (4 3 2 1) .
>
>
> My Perl 6 version is
> $ perl
On Fri Jul 22 17:15:04 2016, cookbook_...@yahoo.co.jp wrote:
> See the following results.
>
> $ perl6 -e 'say (1 R, 2 R, 3 R, 4)'
> (2 1)
> $ perl6 -e 'say (1, 2, 3, 4)'
> (1 2 3 4)
>
> I think that the resulting list of the 1st example should be (4 3 2 1) .
>
>
> My Perl 6 version is
> $ perl
Additional: the Pair.key method also returns the content of a Scalar key,
rather than the key itself:
> my $a = 3; my $b = Pair.new($a.VAR, "z"); $a = 5; say $b.key.WHICH
Int|5
-zefram
# New Ticket Created by Zefram
# Please include the string: [perl #128965]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128965 >
If I construct a Pair whose key is a Scalar object, then the identity of
that key object is not
I wrote:
> I'd expect the .WHICH string to be something like
>"Pair|Str|a|Scalar|47608575457088".
Upon further investigation, I think this requires
multi method WHICH(Pair:D:) {
"Pair|" ~ $!key.WHICH ~ "|" ~ $!value.VAR.WHICH
}
That is, .VAR needs to
Sketch of how to solve this kind of problem for all syntactically tricky
.WHICH cases:
class ObjAt {
method make(*@items) {
self.new(@items.map({
"(" ~
(.^isa(ObjAt) ?? .Str !!
.Str.subst(/<[\(\
Looking at implementing this for SetHashes / BagHashes / MixHashes, I’m not
sure we should do this. Because, even though you could consider
SetHashes/BagHashes/MixHashes as Hashy things, the semantics of a .push and an
.append would be very much different from Hash.push/append. That’s because
# New Ticket Created by Elizabeth Mattijsen
# Please include the string: [perl #128964]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128964 >
m: sub a( --> Str() ) { 42 }; dd a # should this work ?
rakudo-mo
31 matches
Mail list logo