[perl #63066] .split(//) treats ends of a string unequally in Rakudo
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #63066] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=63066 > rakudo: say 'hello-world'.split(//).perl; OUTPUT[["hello", "-", "world", ""]] that seems wrongish -- seems like there either should be a "" at the front or no "" at the end. rakudo: say 'hello-world'.split(//).perl; OUTPUT[["hello", "-", "world", ""]] * pmichaud invites masak to submit a rakudobug. :-) * masak submits
Re: [perl #58034] [TODO] save config_args for make reconfig
2009/2/6 James Keenan via RT : > On Thu Feb 05 01:38:19 2009, rurban wrote: >> On Tue Jan 13 17:19:39 2009, allison wrote: >> > Ticket rejected, no on automatic reconfiguration. Consult with jkeenan >> > on storing configuration args. >> >> Attached patch gets the subject right, make reconfig works now by >> properly storing and quoting the Configure.pl args. > >> >> jkeenan, can you please sign this off? > > If I understand the patch correctly, your objective is simply to find a > quick way to repeat Parrot configuration with the same command-line > options that you most recently used. > > If so, then I wonder why you are using 'make clean' instead of 'make > realclean'. We've always said that 'make clean' undoes the effect of > 'make', whereas 'make realclean' undoes the effect of both 'perl > Configure.pl' and 'make'. So I don't know why you aren't using 'make > realclean' here. I've changed it to make realclean as discussed on irc. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58034] [TODO] save config_args for make reconfig
2009/2/6 Reini Urban : > 2009/2/6 James Keenan via RT : >> If so, then I wonder why you are using 'make clean' instead of 'make >> realclean'. We've always said that 'make clean' undoes the effect of >> 'make', whereas 'make realclean' undoes the effect of both 'perl >> Configure.pl' and 'make'. So I don't know why you aren't using 'make >> realclean' here. > > I've changed it to make realclean as discussed on irc. This time with attachment, sorry. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ 58034-config_args.patch Description: Binary data
Re: [perl #55586] [BUG] Parrot no longer uses HLL_map types?
On Fri, Feb 6, 2009 at 1:12 PM, James Keenan via RT < parrotbug-follo...@parrotcode.org> wrote: > So here's the current state of what Coke originally posted: > > $ cat tclsh.pir > .HLL 'Tcl' > .loadlib 'tcl_group' > > .sub main :main > .param pmc argv > foo(argv) > .end > > .sub foo > .param pmc args :slurpy > $S0 = typeof args > say $S0 > .end > > [li11-226:parrot] 504 $ ./parrot tclsh.pir > ResizablePMCArray > > How should we proceed? Disclaimer: I'm not entirely clear on what exactly is happening in a .loadlib. However, I don't see any .HLL_map'ping (either through the .HLL_map, or through the 'hll_map' method on (I think) the interpreter object). So, in order to see what's wrong, I think the .loadlib directive needs inspection. kjs > > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Re: [perl #55586] [BUG] Parrot no longer uses HLL_map types?
On Fri, Feb 6, 2009 at 8:21 AM, kjstol wrote: > On Fri, Feb 6, 2009 at 1:12 PM, James Keenan via RT < > parrotbug-follo...@parrotcode.org> wrote: > >> So here's the current state of what Coke originally posted: >> >> $ cat tclsh.pir >> .HLL 'Tcl' >> .loadlib 'tcl_group' >> >> .sub main :main >> .param pmc argv >> foo(argv) >> .end >> >> .sub foo >> .param pmc args :slurpy >> $S0 = typeof args >> say $S0 >> .end >> >> [li11-226:parrot] 504 $ ./parrot tclsh.pir >> ResizablePMCArray >> >> How should we proceed? > > > Disclaimer: I'm not entirely clear on what exactly is happening in a > .loadlib. > However, I don't see any .HLL_map'ping (either through the .HLL_map, or > through the 'hll_map' method on (I think) the interpreter object). > So, in order to see what's wrong, I think the .loadlib directive needs > inspection. > > kjs > IIRC, the .loadlib was loading PMCs which used the C method of declaring HLL-map; There was an map to RPA fromTclList. The expected output here was that when invoking a sub, it would use the TclList type to construct the slurpy args. (which worked in the past). -- Will "Coke" Coleda
Re: [perl #37578] [TODO] PIR - simple register allocation
On Fri, Feb 6, 2009 at 8:32 AM, Andrew Whitworth via RT wrote: > On Thu Feb 05 18:11:58 2009, pmichaud wrote: >> I'm okay with closing the ticket, assuming that :unique_reg does >> indeed cause the register allocation algorithm to be simple. >> (IIRC, as recently as a few months ago this wasn't the case.) Did anyone actually verify this statement? If not, closing the ticket may be premature. > Thanks for the reply pmichaud! Closing ticket. > > $#openRTtickets--; > > -- > Andrew Whitworth > a.k.a Whiteknight > > > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Will "Coke" Coleda
Re: [perl #55586] [BUG] Parrot no longer uses HLL_map types?
.HLL has been changed into a one-operand directive:write .HLL 'Tcl'.
the second operand indicated the (I think) shared lib containing the
language's PMCs, if any. Use '.loadlib' for that. So:
.HLL 'Tcl'
.loadlib 'tcl_group'
is equivalent to the old, deprecated and removed:
.HLL 'Tcl', 'tcl_group'
cheers,
kjs
On Fri, Feb 6, 2009 at 1:43 AM, James Keenan via RT <
parrotbug-follo...@parrotcode.org> wrote:
> I may be doing something wrong, but now it seems that it doesn't compile
> at all:
>
> [li11-226:parrot] 525 $ cat tclsh.pir
> .HLL 'Tcl', 'tcl_group'
>
> .sub main :main
> .param pmc argv
> foo(argv)
> .end
>
> .sub foo
> .param pmc args :slurpy
> $S0 = typeof args
> say $S0
> .end
>
> # Local Variables:
> # mode: pir
> # fill-column: 100
> # End:
> # vim: expandtab shiftwidth=4 ft=pir:
>
> [li11-226:parrot] 526 $ ./parrot tclsh.pir
> error:imcc:syntax error, unexpected COMMA, expecting '\n' (',')
>in file 'tclsh.pir' line 1
>
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
[perl #63068] [TODO] Implement $*PROG
# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #63068] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=63068 > the distro-specific 'ps' hack is a *temporary* workaround for a missing $*PROG special var. mberends: oh. :) mberends: did you also create a big fat RT TODO ticket for $*PROG? for the umpteenth time, sorry, no. * masak does so
Re: r25182 - docs/Perl6/Spec
Em Sex, 2009-02-06 às 02:07 -0500, Brandon S. Allbery KF8NH escreveu: > >> +=head2 IO::POSIX > >> + > >> +Indicates that this object can perform standard posix IO operations. > > I don't like that wording, but getting it right seems tricky. > Do we want/need to deal with POSIX conformance levels? When I suggested the name IO::POSIX, it was certainly pointing in that direction. Someone with a deeper understanding on that matter could certainly help mapping that out. In a pratical sense, we're probably going to see IO::Linux26 which might "does IO::POSIXsomelevel" as well as "does IO::BSDinpart" and "does IO::SysVsomewhat". Additionally, we may have "IO::Win32" which doesn't seem to fit in any of those roles... > I would think fcntl() is just the Unix version of a more general > concept, which is probably wider than POSIX. Maybe this wider concepts can be expressed in their own roles, as already been suggested here, as we have IO::Readable and IO::Writeable. IO::Flock is something that looks right to me, where IO::Linux26 does IO::Flock (even if IO::POSIX doesn't). (I use flock as an example because I'm not sure how fcntl applies to a non-posix OS, since that's the name of a POSIX function). > Even given this, if we want compatibility we might provide stuff in > IO::POSIX (IO::VMS, IO::Windows, whatever) which translates to these > calls. I think that's up to the more concrete roles IO::Linux26, IO::Win32 IO::Solaris etc daniel
2 questions: Implementations and Roles
Quick question about implementing things like the DBI/DBD split in Perl6. In Perl5, you have code in DBI that essentially says: - $driverpackage = "DBD::$driver"; eval "use $driverpackage; \$obj = $driverpackage->new(\%params);"; - This has always seemed ugly to me. Is there a better way to do it? Also, is there a simple way to know when I should be using a class vs. a role? Thanks, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
r25223 - docs/Perl6/Spec
Author: lwall Date: 2009-02-07 00:27:35 +0100 (Sat, 07 Feb 2009) New Revision: 25223 Modified: docs/Perl6/Spec/S02-bits.pod Log: refactor pseudo-package names clarify use of protoobjects as responder to subcall interface Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-02-06 23:25:26 UTC (rev 25222) +++ docs/Perl6/Spec/S02-bits.pod2009-02-06 23:27:35 UTC (rev 25223) @@ -12,9 +12,9 @@ Maintainer: Larry Wall Date: 10 Aug 2004 - Last Modified: 1 Feb 2009 + Last Modified: 6 Feb 2009 Number: 2 - Version: 151 + Version: 152 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -512,7 +512,7 @@ # and is implemented by the MyScalar class my Int $x is MyScalar; -Note that C<$x> is also initialized to C<::Int>. See below for more on this. +Note that C<$x> is also initialized to the C protoobject. See below for more on this. =item * @@ -525,12 +525,18 @@ $spot.defined; # False say $spot; # "Dog" -Any class name used as a value by itself is an undefined instance of -that class's prototype, or I. See S12 for more on that. -(Any type name in rvalue context is parsed as a list operator -indicating a typecast, but an argumentless one of these degenerates -to a typecast of undef, producing the protoobject.) +Any type name used as a value is an undefined instance of +that type's prototype object, or I. See S12 for more on that. +Any type name in rvalue context is parsed as a single protoobject value and +expects no arguments following it. However, a protoobject responds to the function +call interface, so you may use the name of a protoobject with parentheses as if it +were a function, and any argument supplied to the call is coerced +to the type indicated by the protoobject. If there is no argument +in the parentheses, the protoobject returns itself: +my $type = Num; # protoobject as a value +$num = $type($string) # coerce to Num + To get a real C object, call a constructor method such as C: my Dog $spot .= new; @@ -1760,37 +1766,51 @@ The following pseudo-package names are reserved at the front of a name: -MY # Lexical symbols declared in the current scope -OUR # Package symbols declared in the current package -FILE# Lexical symbols in this file's outermost scope -PERL# Lexical symbols in the standard setting -LANG# Lexical symbols in current DSL (usually PERL) -GLOBAL # Interpreter-wide package symbols -PROCESS # Process-related globals (superglobals) -SUPER # Package symbols declared in inherited classes +MY # Symbols in the current lexical scope (aka $?SCOPE) +OUR # Symbols in the current package (aka $?PACKAGE) +CORE# Outermost lexical scope, definition of standard Perl +GLOBAL # Interpreter-wide package symbols, really CORE::GLOBAL +PROCESS # Process-related globals (superglobals), CORE::PROCESS COMPILING # Lexical symbols in the scope being compiled +CALLER # Contextual symbols in the immediate caller's lexical scope +CONTEXT # Contextual symbols in my or any caller's lexical scope The following relative names are also reserved but may be used anywhere in a name: -OUTER # Lexical symbols declared in the outer scope -CALLER # Contextual symbols in the immediate caller's scope -CONTEXT # Contextual symbols in any context's scope +OUTER # Symbols in the next outer lexical scope +UNIT# Symbols in the outermost lexical scope of compilation unit +SETTING # Lexical symbols in the unit's DSL (usually CORE) +PARENT # Symbols in this package's parent package (or lexical scope) +The following is reserved at the beginning of method names in method calls: + +SUPER # Package symbols declared in inherited classes + Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe C, and then only for coyotes.) -The C scope is equivalent to C. For a standard Perl -program C is the same as C, but various startup options -(such as C<-n> or C<-p>) can put you into a domain specific language, -in which case C remains the scope of the standard language, -while C represents the scope defining the DSL that functions +The file's scope is known as C, but there are one or more +lexical scopes outside of that corresponding to the linguistic setting +(often known as the prelude in other cultures). Hence, the C +scope is equivalent to C. For a standard Perl program +C is the same
Re: r25200 - docs/Perl6/Spec t/spec
On 2009 Feb 5, at 13:51, Larry Wall wrote: Pity that -F specifies the ground. Hey, I know, let's make -G the figure, that makes about as much sense as -x vs +x, or electrons vs positrons... :) Someone's been rereading _Gödel,_Escher,_Bach_? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: 2 questions: Implementations and Roles
Timothy S. Nelson wrote: >Also, is there a simple way to know when I should be using a class > vs. a role? If you plan on creating objects with it, use a class. If you plan on creating classes with it, use a role. -- Jonathan "Dataweaver" Lang
Re: r25182 - docs/Perl6/Spec
On 2009 Feb 6, at 6:24, Daniel Ruoso wrote: Em Sex, 2009-02-06 às 02:07 -0500, Brandon S. Allbery KF8NH escreveu: I would think fcntl() is just the Unix version of a more general concept, which is probably wider than POSIX. Maybe this wider concepts can be expressed in their own roles, as already been suggested here, as we have IO::Readable and IO::Writeable. IO::Flock is something that looks right to me, where IO::Linux26 does IO::Flock (even if IO::POSIX doesn't). (I use flock as an example because I'm not sure how fcntl applies to a non-posix OS, since that's the name of a POSIX function). fcntl = file descriptor control/configuration. While the name itself is POSIX, the range of possible actions described by it is larger than that. (Yes, one could just compose roles with individual actions, thus making fcntl() disappear altogether. But you will not be thanked by someone who has to work out exactly which roles s/he needs to implement for a given "IO-like" object, nor by the unfortunate tasked with porting perl5 code.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
r25226 - docs/Perl6/Spec
Author: lwall
Date: 2009-02-07 08:50:27 +0100 (Sat, 07 Feb 2009)
New Revision: 25226
Modified:
docs/Perl6/Spec/S29-functions.pod
Log:
missing commas
Modified: docs/Perl6/Spec/S29-functions.pod
===
--- docs/Perl6/Spec/S29-functions.pod 2009-02-07 06:25:54 UTC (rev 25225)
+++ docs/Perl6/Spec/S29-functions.pod 2009-02-07 07:50:27 UTC (rev 25226)
@@ -819,14 +819,14 @@
value. For example:
@list = (1, 2, 3, 4);
- (:@even, :@odd) := classify { $_ % 2 ?? 'odd' !! 'even' } @list;
+ (:@even, :@odd) := classify { $_ % 2 ?? 'odd' !! 'even' }, @list;
In this example, @even will contain all even numbers from C<@list>
and C<@odd> will contain all odd numbers from C<@list>.
To simply transform a list into a hash of arrays:
- %cars_by_color = classify { .color } @cars;
+ %cars_by_color = classify { .color }, @cars;
red_car_owners(%cars_by_color.map:{.owner});
=item grep
