Re: I need `dir` help

[jerry gay]

i'm afraid you didn't read the docs very closely...

Returns the contents of a directory as a lazy list of IO::Path objects


stringifying an IO::Path object gives you a large string.

the examples in the docs take up more room than the description of the
routine. here's the first:

Examples:
> # To iterate over the contents of the current directory:
> for dir() -> $file {
> say $file;
> }


i suspect iterating over the contents of the object returned by the dir
routine, as documented in the link you provided, will produce the expected
results.

~particle

On Thu, May 10, 2018 at 4:34 PM, ToddAndMargo  wrote:

> Hi All,
>
> https://docs.perl6.org/routine/dir
>
> perl6 -e 'my $x=dir; say "$x";'
>
> Does indeed read the directory, but give me one YUGE string.
> I need each entry to have some kind of a separator.
>
>
> Many thanks,
> -T
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
>

Re: need <-[x]> help

[jerry gay]

you want a negative lookahead assertion, which are described (with an
example) at https://docs.perl6.org/language/regexes#Lookahead_Assertions

On Thu, May 3, 2018 at 3:10 AM, Todd Chester  wrote:

> Hi All,
>
> What I am trying to do is to replace a quote `"`
> with `inches`, but NOT when the quote is followed
> by a comma `,`.
>
> In other words, ignore `",`
>
> I am not having too good a time with it.  What am I
> doing wrong?
>
> $ perl6 -e 'my $x=qw["44","7" ab","","999"]; say "$x";$x~~s:g/\"(.)<-[,]>/
> inches($0)/; say "$x";'
>
> "44","7" ab","","999"
> inches(4)inches(,)7inches( )binches(,)inches(,)999"
>
> desired output:
> "44","7 inches ab","","999"
>
> Many thanks,
> -T
>
> next step, ignoring the quote at the end of the line.
>

Re: s:g/T/U/ doesn't work ?

[jerry gay]

On Wed, Oct 24, 2012 at 5:35 AM, Marc Chantreux kha...@phear.org wrote:
 Cannot assign to a non-container
   in sub infix:= at src/gen/CORE.setting:11692
   in block at /tmp/ZZZ:4

you're attempting to modify a string constant, which cannot be
modified. try something like (untested):

my $snippet = 'GATGGAACTTGACTACGTAAATT';
for $snippet {
  ...

~jerry

Announce: Rakudo Perl 6 development release #21 (Seattle)

[jerry gay]

On behalf of the Rakudo development team, I'm pleased to announce
the September 2009 development release of Rakudo Perl #21 Seattle.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1].
The tarball for the September 2009 release is available from
http://github.com/rakudo/rakudo/downloads .

Due to the continued rapid pace of Rakudo development and the frequent
addition of new Perl 6 features and bugfixes, we recommend building Rakudo
from the latest source, available from the main repository at github.
More details are available at http://rakudo.org/how-to-get-rakudo.

Rakudo Perl follows a monthly release cycle, with each release code named
after a Perl Mongers group.  September 2009 is code named Seattle for the
enthusiasm they have shown for Perl 6 during monthly meetings, and the
feedback, encouragement and support given me for the past several years.

Since the 2009-08 release, Rakudo Perl builds from an installed
Parrot instead of using Parrot's build tree.  This release of Rakudo
requires Parrot 1.6.0.  For the latest information on building and
using Rakudo Perl, see the README file section titled Building and
invoking Rakudo.  (Quick note: the --gen-parrot option still
automatically downloads and builds Parrot as before, if you prefer
that approach.)

Also, unlike previous versions of Rakudo Perl, the perl6
(or perl6.exe) executables only work when invoked from the
Rakudo root directory until a make install is performed.
Running make install will install Rakudo and its libraries
into the Parrot installation that was used to build it, and then
the executables will work when invoked from any directory.

Some of the specific major changes and improvements occuring
with this release include:

* Rakudo is now passing 15,497 spectests, an increase of 3,128
  passing tests since the August 2009 release.  With this release
  Rakudo is now passing 71.5% of the available spectest suite.

* Rakudo now supports contextual variables.

* Rakudo now supports the rational (Rat) data type.

* Rakudo now supports overloading of many of the builtin operators,
  many of which are now defined in the core setting.  Many have
  also been improved to be more faithful to the specification
  with respect to types and coercions.

* Substantially improved support for trait handling.  Most of the
  built-in traits are now defined in the core setting.

* The %*ENV variable now works properly for modifying the process environment.

Since the Perl 6 specification is still in flux, some deprecated features
have been removed from Rakudo. Prominently among those are:

 * '=$handle' is deprecated in favor of '$handle.get' (one line)
   and '$handle.lines' (all lines).

 * 'int $obj' is deprecated in favor of '$obj.Int'.

The development team thanks all of our contributors and sponsors for
making Rakudo Perl possible.  If you would like to contribute,
see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org
mailing list, or ask on IRC #perl6 on freenode.

The next release of Rakudo (#22) is scheduled for October 22, 2009.
A list of the other planned release dates and codenames for 2009 is
available in the docs/release_guide.pod file.  In general, Rakudo
development releases are scheduled to occur two days after each
Parrot monthly release.  Parrot releases the third Tuesday of each month.

Have fun!

References:
[1]  Parrot, http://parrot.org/

Re: Why {{}} for regexp closures instead of just {}?

[jerry gay]

On Sun, Oct 26, 2008 at 10:45 PM, Chris Dolan [EMAIL PROTECTED] wrote:
 S05 always uses single curlies for closures, but throughout Parrot, code
 seems to use double curlies in PGE regexps.  Why is that?

 That is, why this:
  m/ foo {{ say found foo }} /
 and not this:
  m/ foo { say found foo } /

 The latter complains about Statement not terminated properly.

this is old PGE syntax that hasn't yet been updated to match S05. it's a bug.

or maybe, you can say that closures inside regexes aren't supported
yet, but rakudo has a feature that allows {{PIR}}} to work.
~jerry

Re: Practical Considerations

[jerry gay]

On Mon, Oct 6, 2008 at 5:49 AM, Elyse M. Grasso
[EMAIL PROTECTED] wrote:
 My company sells an application that links a bugtracking tool with an SCM tool
 so that, for example, the files changed for each bug are recorded in the
 bugtracking tool. It is currently written in (mostly) non-object-oriented
 perl5.

 We are re-architecting the application so that it can work with different
 bugtracking tools and SCM tools, and do things like sync data from specific
 fields between a help desk tool and the bugtracking tool. This would be a good
 time for us to transition to perl6.

yes, it seems perfectly reasonable to consider language choices when
re-designing your product's architecture. certainly, the perl 6
specification makes it an attractive choice.

 As far as I can tell from the various faqs and wikis, the existing
 functionality in rakudo should support most of our needs for the initial
 release. I may need to assist with the porting of some database access and
 other modules from CPAN to C6PAN in the longer term.

the core functionality of rakudo may support what you need, but at
this point i have some concerns with chosing rakudo as the runtime for
a client-facing production product. mainly, there are un- and
under-tested portions of the language implementation, which to me
suggests that there are bugs lurking as it hasn't been proven
otherwise by passing tests. this isn't to suggest that rakudo is not
ready for use, but it is a risk--until we (rakudo project team) have
higher test coverage and more passing tests.

anybody can help, by adding tests which cover the official perl 6
specification (http://spec.pugscode.org/) to the pugs repository
(http://svn.pugscode.org/). anyone who is interested can get commit
priviliges to the repository; the procedure is simple, and approval is
always granted. feel free to contact this list with a commit bit
request. also, there are a number of us with experience writing tests
that cover the spec, and we're happy to share our knowledge on the
subject.

porting modules to perl 6 definitely needs some help. currently there
is no c6pan, there is only the pugs repository, where some previously
ported modules live. i haven't seen much visible work on c6pan lately,
and i'm sure there's no solution nearing production. this means it's
best to package any required modules with your product rather than
relying on an external resource to provide perl 6 modules at
build/configure/install-time.

 However, I am concerned about deployment of a perl6 based product to
 customers. Perl5 can be reasonably specified as a prerequisite for loading our
 application, since it is generally available (and shipped with some of the
 products we integrate). That is not the case with Perl6.

this is another case for concern, for sure. parrot's installation code
is not extremely robust, but is improving quickly. as of last month's
release (0.7.1), parrot is released as a source distribution from the
source repository (http://svn.perl.org/parrot/tags/RELEASE_0_7_1), a
CPAN module (http://search.cpan.org/~pmic/parrot-0.7.1/), a windows
installation package (http://parrotwin32.wiki.sourceforge.net/), a
cygwin package (libparrot0 and libparrot-devel), and a debian package
(http://packages.qa.debian.org/p/parrot.html). these installation
methods are in varying states of maturity, and all are being actively
improved. depending on your user system requirements, these methods
may work well for you. i suggest investigating further.

 Is it practical now to deploy a Perl6/Parrot  runtime with a (possibly
 precompiled) version of our product? Will it be practical any time soon? I can
 probably get away with occasionally requiring Linux and Solaris users to
 rebuild Parrot to fit their local configuration, but Windows is another 
 matter.
 (Shipping a known version of the runtime with our product will also allow us
 to tune our application to a known set of available perl6 functions.)

possible? yes, definitely. practical? that's hard to say. if parrot
and rakudo meet your functionality needs, and the packages are
available, then yes. however, i can't call it practical until i've
tried it successfully at least three times in simulated user
environments.

 The mechanism for generating the packages I ship to my customers does not need
 to be pretty, it just needs to exist. If there are instructions already online
 about how to generate such packages (now or in the near future), I would
 appreciate a pointer  to them.

parrot has a guide for creating the monthly release package, and there
is a guide for debian packaging as well, found at
http://svn.perl.org/parrot/trunk/docs/project/). questions here or on
other related mailing lists are most welcome.


if, during the course of your further examination of parrot and
rakudo, you develop concerns on stability, portability, packaging,
completeness or other topics, there are multiple ways to address those
concerns. firstly, the mailing lists are an excellent 

Re: Perl6 style-guide

[jerry gay]

On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote:

I was wondering if there is (or there should be) a documentation on how
to elegantly write Perl6 code.


yes, there should be.


I am afraid that when I will be starting to write Perl6 code, it will be
too much Perl5-ish, and I will end up rewriting my code in every 3
months because I hate when my code is not elegant (at least to my own
standards).


i think that's a problem you'll share with many other folks, as *very
few* have written anything of substance in perl 6 so far... and the
design is still changing.


I was wondering that some - maybe @Larry - already have (mosf ot) Perl6
in their heads, so they could create such a document/recommendation
before Perl6 gets used widely, and the coding style gets distorted.


i think larry's pretty busy doing what he should be doing at this
point... designing.


Or shall we just leave this to the community? Maybe this documentation
shouldn't/can't be written yet? Shall we let Perl6-style grow from usage
in 1-2 years, and create a guide like this then, when things mature?


don't just leave this to the community. take part! take advantage of
the perl 6 wiki (http://rakudo.org/perl6/index.cgi) and create a page
describing the task. write some code yourself. ask folks to
contribute, and fix the existing code or add their own. create an
outline of what you'd like to see there... and have fun!

be the community.
~jerry