Gimp & Perl6

Has anyone looked at a Perl6 module for GIMP? GIMP natively uses a Scheme-like interface, but there are Perl and Python modules.

[perl #128969] [RFC] Proposal to move grammar related part of error messages behind a runtime flag

# 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:

[perl #128968] no .emit method on Any (as opposed to, for example, .take)

# 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 . for ^10; that seems inconsistent to me.

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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,

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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?

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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.

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

> 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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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 =

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

> 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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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.

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

Re: [perl #128595] [LTA] -M with non-existant module breaks 'exit' in REPL

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. > #

Re: [perl #126264] LTA error message for keywords like "eval" or "begin" in lower case

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

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

[perl #128703] [BUG] Reversed list separator deletes the operands

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 #128703] [BUG] Reversed list separator deletes the operands

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 > $

Re: [perl #128965] [BUG] Pair.WHICH mishandles Scalar key

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

[perl #128965] [BUG] Pair.WHICH mishandles Scalar key

# 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

Re: [perl #128948] [BUG] Pair.WHICH distinguishes pairs with same container value

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

Re: [perl #128943] [BUG] Set.WHICH confused by spaces

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 !!

Re: [perl #128903] [BUG] SetHash::push not implemented

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

[perl #128964] Type coercion doesn't work on Block.returns

# 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 ?