Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC

[NotFound]

> I just tried to build parrot with g++ on darwin/intel to see if I could 
> replicate the initial failure
> reported in the ticket, but am unable to. (g++ is detected as gcc, and then 
> we pass it an option
> that makes it explode.)

What Configure options do you used? I usually do:

--cc=g++ --cxx=g++ --ld=g++ --link=g++

-- 
Salu2

Re: Better "sort" spec?

[Larry Wall]

On Fri, Dec 12, 2008 at 11:49:37PM -0500, Uri Guttman wrote:
: so you have not discovered something new in perl or perl6 regarding
: sorting. it has been covered and in depth but never properly integrated
: into the p6 docs.

It will be more useful if you comment relative to the existing design found in:

http://svn.pugscode.org/pugs/docs/Perl6/Spec/S29-functions.pod

Larry

Re: What does a Pair numify to?

[Larry Wall]

On Mon, Dec 15, 2008 at 04:43:51PM -0700, David Green wrote:
> I can't really think of a great example where you'd want to numify a  
> pair, but I would expect printing one to produce something like "a =>  
> 23" (especially since that's what a one-element hash would print,  
> right?).

Nope, would print "a\t23\n" as currently specced.

Larry

Re: What does a Pair numify to?

[Jon Lang]

On Mon, Dec 15, 2008 at 10:26 PM, Larry Wall  wrote:
> On Mon, Dec 15, 2008 at 04:43:51PM -0700, David Green wrote:
>> I can't really think of a great example where you'd want to numify a
>> pair, but I would expect printing one to produce something like "a =>
>> 23" (especially since that's what a one-element hash would print,
>> right?).
>
> Nope, would print "a\t23\n" as currently specced.

The point, though, is that stringification of a pair incorporates both
the key and the value into the resulting string.  This is an option
that numification doesn't have.

As well, I'm pretty sure that "a\t23\n" doesn't numify.  I'm beginning
to think that Pairs shouldn't, either; but if they do, they should
definitely do so by numifying the value of the pair.

-- 
Jonathan "Dataweaver" Lang

[perl #57984] Finish implementing given and check/fix tests in S04-statements\given.t

[Moritz Lenz via RT]

On Sat Aug 16 07:29:43 2008, je...@perl.org wrote:
> - Need resumable exceptions (Parrot)

Fixed in r33942 .

Re: What does a Pair numify to?

[TSa]

HaloO,

Moritz Lenz wrote:

The counter example is if you want to print a pair:

.say for %hash.pairs.sort: { .value };

In that case it would be nice to have the key appear in the stringification.


I see no problem as long as say gets a pair as argument. Then it can
print the key and value separated with a tab. More problematic are
string concatenations of the form

   say "the pair is: " ~ (foo => $bar);

which need to be written so that say sees the pair

   say "the pair is: ", (foo => $bar);

and not a string that only contains the value of the pair. I'm not
sure if the parens are necessary to pass the pair to say as argument
to be printed instead of a named argument that influences how the
printing is done.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Working with files wish list

[Timothy S. Nelson]

On Tue, 16 Dec 2008, jason switzer wrote:


You can already easily mix it in using 'does':

$fstab = open('/etc/fstab', :r);
$fstab does WhitespaceTrim;

I don't think it's really necessary to include that into open(),
though it might be useful syntactic sugar.


I haven't spent the time to understand mix-ins yet, but this does look like
a feasible (clean) idea. However, how do you specify one/more filters? For
example, say you want to :rw a file. How can you provide an input filter and
an output filter (or multiples of either)? Can you layer filters if done
with mix-ins? If so, how do you specify direction?


	I've had somewhat related ideas in the past, but they always involved 
feed operators somehow.  I don't think I've got enough of a grip on things to 
suggest specifics, but I thought I'd throw the idea into the mix.


	Also, if the wishlist covers filesystems as well as files (ie. 
opendir-type stuff), my wishlist involves having general tree-manipulation 
stuff that works with filesystems just as well as with XML; we could use 
XPath-like globs on filesystems, which would completely replace eg. 
File::Find, among other things.  So you could ask for 
"/path/to/directory/child::*", which would get you the children, but not the 
parent ".." or the self ".".  I've actually started code in this direction 
(ie. of a role, not the IO side of things), but stopped while waiting on the 
further development of Rakudo (ie. operator overloading).


Anyway, just some thoughts thrown into the mix.

:)


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

[perl #61394] Re: unicode and macosx

[via RT]

# New Ticket Created by  Stephane Payrard 
# Please include the string:  [perl #61394]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61394 >


my $s = " "; say  $s.chars  #  now returns 1

Note : the bug was reported on macintel 32 bits which died. I am now
testing on a macintel 64 bits.
I don't know if it can affect the test.

On Mon, May 19, 2008 at 6:28 PM, Stéphane Payrard  wrote:
> On a macintel 10.5 I have some problem with unicode. unicode
> characters are not recognized as such. See the rakudo test below
>
> The configuring phase gives :
>
> Determining whether ICU is installed...yes.
>
> The compiling phase finish with an error but it apprently causes no
> problems except I can't run 'make test' because of
> the dependance on a successful compilation.
>
> ar: blib/lib/libparrot.a is a fat file (use libtool(1) or lipo(1) and
> ar(1) on it)
> ar: blib/lib/libparrot.a: Inappropriate file type or format
> make: *** [blib/lib/libparrot.a] Error 1
>
> rakudo is generated without problem
>
> But the following test fails. I pasted the content of the literal
> string with a character that emacs says to be #x8a0
>
>
>> my $s = " "; say  $s.chars  # $s == "\x8a0"
> 2
>
>
> I expected one.
>
> --
> cognominal stef
>



-- 
cognominal stef

[perl #59244] [TODO] Implement infix: for Pairs

[Patrick R. Michaud via RT]

On Wed Sep 24 17:24:16 2008, pmichaud wrote:
> On Wed, Sep 24, 2008 at 04:53:54PM -0700, chromatic wrote:
> > On Tuesday 23 September 2008 09:35:05 Moritz Lenz wrote:
> > 
> > > %hash.pairs.sort needs infix: to work properly with Pair as
input.
> > >
> > > It should be easy to add a multi that does this by first comparing the
> > > key, and if they are equal the value.
> [...]
> Alas, there was another thread that shows that Parrot's 'sort'
> method can't seem to handle comparison functions that have :multi
> on them.
> 
> Once that's fixed (or we come up with an alternative 'sort'),
> then this patch or something like it will probably work.

Now fixed in r33959, by providing an alternate interface to sort (one
that also produces a stable sort).

Closing ticket, thanks!

Pm

[perl #61364] sort() should implement a stable sort

[Patrick R. Michaud via RT]

On Sun Dec 14 11:47:58 2008, moritz wrote:
> S29 says:
> 
> : If all criteria are exhausted when comparing two elements, sort should
> : return them in the same relative order they had in @values.
> 
> or in terms of computer science, the sort should be stable.
> 
> Rakudo r33895 doesn't do this, as a few tests show that I've added to
> t/spec/S29-list/sort.t, for example: [...]

It does now, r33959.

Thanks!

Pm

Re: Support for ensuring invariants from one loop iteration to the next?

[David Green]

On 2008-Dec-6, at 7:37 am, Aristotle Pagaltzis wrote:
Funnily enough, I think you’re onto something here that you didn’t  
even notice: [...]
if we had a NOTFIRST (which would run before ENTER just as FIRST  
does, but on *every* iteration *except* the first), then we could  
trivially attain the correct semantics and achieve all desired  
results:


   repeat {
   @stuff = grep { !.valid }, @stuff };
   NOTFIRST {
   .do_something( ++$i ) for @stuff;
   }
   } while @stuff;

The really nice thing about this is that the blocks are nested, so  
that any variable in scope for the invariant enforcement will also  
be in scope in the NOTFIRST block without the user ever having to  
arrange another enclosing scope.


Oh, yes!  So what if we had "LOOP $n {}" that executed on the nth  
iteration?  "LOOP 0 {}" at the beginning would be like FIRST {}, "LOOP  
* {}" at the end would be like LAST {}, and "LOOP 1..* {}" would give  
us the NOTFIRST block.  Presumably you could have multiple LOOP blocks  
too.


(Actually, you couldn't quite do FIRST/LAST using LOOP $n, because  
FIRST/LAST occur outside ENTER/LEAVE, whereas LOOP would occur  
inside.  But perhaps you could have LOOP blocks inside ENTER/LEAVE  
blocks?)



-David

[perl #59394] [PATCH] Implementation of Pair.pairs.

[Patrick R. Michaud via RT]

Added in r33963, thanks!

Pm

Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Andrew Whitworth]

I'll pick up borland and play with it, although I won't get to it
until the next cycle. I've got a really old version of Turbo C++ 4.52
left over from school, and free versions of Turbo C++ Explorer are
available for download. I don't promise any miracles, but at least I
will be able to prove that some errors still exist or not.

--Andrew Whitworth

On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT
 wrote:
> On Thu Jan 11 09:55:40 2007, stmpeters wrote:
>> On Thu Jan 11 08:57:22 2007, coke wrote:
>> > Need details.
>>
>> A recent patch has gotten Parrot to the point that it can be compiled
>> with Borland C++ on Win32.  Unfortunately, it does not link correctly to
>> actually create a valid parrot executable.  Additional configuration is
>> needed to make Borland compile and link Parrot so that it can actually
>> be run and tested.
>
> Without a champion for this compiler, there's not much we can do; Our current 
> targets for
> Windows include, as I understand it, cygwin, strawberry perl and its build 
> system, and recent
> versions of VisualC++. Borland isn't in our core list for the upcoming 1.0 
> release.
>
> If we do find a Borland champion, they should open a new ticket at 
> https://trac.parrot.org/.
>
> Rejecting this ticket; Regards.
>
> --
> Will "Coke" Coleda
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Re: Proposal: Make @a and @@a different variables

[TSa]

HaloO,

Daniel Ruoso wrote:

That being said, we should note that this example looks simple because
we have almost no lazyness implied (since there's an assignment in the
first line), every list access requires the evaluation of the flatenning
of the list.

  my @@a = ((),(1,2,3),());


Mustn't that be written as (();(1,2,3);()) to produce a three
element outer view?


  # the following will require a flatenning to get the actual index
  say @a[3];


Could we not shift the problem into a more complicated form
of the size of the array? Here it has size 0+3+0 but each of the
summands could be lazy and hence infinite or at least finite with
unknown value. In any case the flat view @a has to step at most
the first iterator in the array whereas @@a can look beyond that
when indexed with a slice, that is something with semicolon in it.
An out of bounds access like @a[3] can be answered without flattening,
right?

In general I'm in favor of making @a and @@a distinct because
otherwise the first @ in @@a feels like an operator instead like
a twigil that belongs to the variable like $ belongs to $a which
is also distinct from @a. Since one could also go with a shaped
@a I think the choice of @@a versus @a is a bit like the choice
between a @a and an anonymous array in a $ var ala $a = [] which
can be handled through $a almost like @a.



  @a =!= @@a :test;


BTW, what does the :test mean there?


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: [perl #61092] JSON/pge2pir.pir segaful on amd64

[Илья]

Hi!
Yes I use Ubuntu.
libicu36-dev 3.6-2etch1

Parrot 33940 maked on my box, but make test fail:
Test Summary Report
---
t/pmc/fixedfloatarray.t   (Wstat: 11 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 24 tests but ran 0.
t/pmc/multisub.t  (Wstat: 11 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 8 tests but ran 0.
t/pmc/pmc.t   (Wstat: 256 Tests: 16 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
t/pmc/pmcproxy.t  (Wstat: 11 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 44 tests but ran 0.
t/pmc/resizablepmcarray.t (Wstat: 11 Tests: 111 Failed: 0)
  Parse errors: Bad plan.  You planned 118 tests but ran 111.
t/pmc/resizablestringarray.t  (Wstat: 11 Tests: 161 Failed: 0)
  Parse errors: Bad plan.  You planned 184 tests but ran 161.
t/pmc/scalar.t(Wstat: 11 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
t/compilers/pct/complete_workflow.t   (Wstat: 65280 Tests: 17 Failed: 3)
  Failed tests:  9, 16-17
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 54 tests but ran 17.
t/compilers/pge/p5regex/p5rx.t(Wstat: 11 Tests: 18 Failed: 0)
  Parse errors: Bad plan.  You planned 960 tests but ran 18.
t/compilers/pge/perl6regex/01-regex.t (Wstat: 11 Tests: 45 Failed: 0)
  Parse errors: No plan found in TAP output
t/compilers/tge/grammar.t (Wstat: 512 Tests: 3 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
t/library/mime_base64.t   (Wstat: 11 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 550 tests but ran 0.
Files=396, Tests=9300, 491 wallclock secs ( 1.77 usr  1.37 sys +
115.60 cusr 46.91 csys = 165.65 CPU)
Result: FAIL
make: *** [test] Error 1

make perl6 fail too:
make -C languages/perl6 perl6
make[1]: Entering directory `/home/ihrd/parrot/languages/perl6'
../../parrot  /home/ihrd/parrot/compilers/nqp/nqp.pbc
--output=src/gen_actions.pir \
--encoding=fixed_8 --target=pir src/parser/actions.pm
make[1]: *** [src/gen_actions.pir] Segmentation fault
make[1]: Leaving directory `/home/ihrd/parrot/languages/perl6'
make: *** [perl6] Error 2



2008/12/16 Mark Glines via RT :
>> ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir
>> --output=PGE/builtins_gen.pir PGE/builtins.pg
>> make[1]: *** [PGE.pbc] Segmentation fault
>
> [snip]
>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 47236244385456 (LWP 24325)]
>> 0x2af6098b097a in Parrot_Iterator_shift_string ()
>> from /home/ihrd/parrot/blib/lib/libparrot.so.0.8.1
>
> This segfault looks very similar to the issue reported as Trac #26 (
> https://trac.parrot.org/parrot/ticket/26 ), I believe they are the same
> issue.
>
> @Reporter, which linux distro are you using?  Unfortunately I can't
> reproduce this on my gentoo x86-64 box (I just tried with r33853).  If
> you are using Ubuntu, that may be helpful in figuring out what the
> difference is.  I do notice I have a different version of libicudata
> than you do, likely other things differ as well.
>
> Thanks,
>
> Mark
>
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

Re: What does a Pair numify to?

[Jon Lang]

TSa wrote:
> I see no problem as long as say gets a pair as argument. Then it can
> print the key and value separated with a tab. More problematic are
> string concatenations of the form
>
>   say "the pair is: " ~ (foo => $bar);
>
> which need to be written so that say sees the pair
>
>   say "the pair is: ", (foo => $bar);
>
> and not a string that only contains the value of the pair. I'm not
> sure if the parens are necessary to pass the pair to say as argument
> to be printed instead of a named argument that influences how the
> printing is done.

That's a good point.  Is there an easy way to distinguish between
passing a pair into a positional parameter vs. passing a value into a
named parameter?  My gut instinct would be to draw a distinction
between the different forms that Pair syntax can take, with "foo =>
$bar" being treated as an instance of the former and ":foo($bar)"
being treated as an instance of the latter.  That is:

  say 'the pair is: ', foo => $bar;

would be equivalent to:

  say 'the pair is: ', "foo\t$bar\n";

while:

  say "the pair is: ", :foo($bar);

would pass $bar in as the value of the named parameter 'foo' (which, I
believe, would cause 'say' to squawk, as its signature doesn't allow
for a named parameter 'foo').

-- 
Jonathan "Dataweaver" Lang

Proposal: Make @a and @@a different variables

[Daniel Ruoso]

Hi,

One of the hardest features in Perl 6 is the slice context. It is
undoubtfully usefull, since it provides semantics to acces each
iteration of a map, for instance.

But there's one thing in the spec that makes not only slices, but the
lists themselves considerably harder to implement, and that is the idea
that a slice is a view of a list.

  my @@a = map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
  say @a[0]; # this should print 1.
  say @@a[0]; # this should print ().
  say @a[1]; # this should print 2.
  say @@a[1;0]; # this should print 1.

That happens because '@a' and '@@a' are the same variable, just
different views of that variable.

That being said, we should note that this example looks simple because
we have almost no lazyness implied (since there's an assignment in the
first line), every list access requires the evaluation of the flatenning
of the list.

  my @@a = ((),(1,2,3),());
  # the following will require a flatenning to get the actual index
  say @a[3];

This looks much more complicated when you have a lazy list...

  my @a <== map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
  # the line below will require two map iterations to get a value,
  # and at that time, there will be three values available
  say @a[0];
  # having to support a slice view here will require the lazy list
  # to always be a lazy slice, and each access will require a flatenning
  # of the values already obtained to only then decide if it has to
  # obtain more items
  say @a[2];

This all makes me think that it would be much easier if the slice
existed on its own, which would mean:

  # this will provide only a flatenned view
  my @a <== map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
  # and this will provide a slice view
  my @@a <== map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
  # but @a and @@a are different values
  @a =!= @@a :test;
  # and trying to get the slice on @a will fail
  say @a[0;1]; # fail
  # and you still can flatten the slice if you want to...
  # and it can preserve the lazyness
  my @b <== @@a;
  # or enforce a mostly eager level
  my @c = @@a;

So, what do you think?

daniel

Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Ron Blaschke]

Andrew Whitworth wrote:
> I'll pick up borland and play with it, although I won't get to it
> until the next cycle. I've got a really old version of Turbo C++ 4.52
> left over from school, and free versions of Turbo C++ Explorer are
> available for download. I don't promise any miracles, but at least I
> will be able to prove that some errors still exist or not.
> 
> --Andrew Whitworth
> 
> On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT
>  wrote:
>> On Thu Jan 11 09:55:40 2007, stmpeters wrote:
>>> On Thu Jan 11 08:57:22 2007, coke wrote:
 Need details.
>>> A recent patch has gotten Parrot to the point that it can be compiled
>>> with Borland C++ on Win32.  Unfortunately, it does not link correctly to
>>> actually create a valid parrot executable.  Additional configuration is
>>> needed to make Borland compile and link Parrot so that it can actually
>>> be run and tested.
>> Without a champion for this compiler, there's not much we can do; Our 
>> current targets for
>> Windows include, as I understand it, cygwin, strawberry perl and its build 
>> system, and recent
>> versions of VisualC++. Borland isn't in our core list for the upcoming 1.0 
>> release.
>>
>> If we do find a Borland champion, they should open a new ticket at 
>> https://trac.parrot.org/.
>>
>> Rejecting this ticket; Regards.

Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
and 5.82, and failed miserably.  But that may just be my bad bcc-foo.
Unless someone's keen for this platform and has access to a fairly new
("within two years") version (is it called C++ Builder now?), I'm not
sure if this is worth pursuing.

Ron

Re: What does a Pair numify to?

[Jon Lang]

Moritz Lenz wrote:
> Off the top of my head, see S06 for the gory details:
>
> my $pair = a => 'b';
>
> named(a => 'b');
> named(:a);
> named(|$pair);
>
> positional((a => 'b'));
> positional((:a));
> positional($pair);

As you say: the gory details, emphasis on gory.  But if that's the way
of things, so be it.

-- 
Jonathan "Dataweaver" Lang

Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Andrew Whitworth]

On Tue, Dec 16, 2008 at 1:20 PM, Ron Blaschke  wrote:
> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
> and 5.82, and failed miserably.  But that may just be my bad bcc-foo.
> Unless someone's keen for this platform and has access to a fairly new
> ("within two years") version (is it called C++ Builder now?), I'm not
> sure if this is worth pursuing.

The free version of "Turbo C++ Builder" is called "Turbo C++
Explorer". Should be the same thing, minus some features. If I can get
it to work with the most recent version of that, I can try digging
back through older versions to find compatibility problems.

--Andre Whitworth

Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Will Coleda]

Unless this task would make you exceedingly happy, I wouldn't bother.

IMO, there are much higher priority things requiring tuits than trying
to add a fourth compiler for windows, especially before the 1.0
release.

Regards.

On Tue, Dec 16, 2008 at 1:24 PM, Andrew Whitworth  wrote:
> On Tue, Dec 16, 2008 at 1:20 PM, Ron Blaschke  wrote:
>> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
>> and 5.82, and failed miserably.  But that may just be my bad bcc-foo.
>> Unless someone's keen for this platform and has access to a fairly new
>> ("within two years") version (is it called C++ Builder now?), I'm not
>> sure if this is worth pursuing.
>
> The free version of "Turbo C++ Builder" is called "Turbo C++
> Explorer". Should be the same thing, minus some features. If I can get
> it to work with the most recent version of that, I can try digging
> back through older versions to find compatibility problems.
>
> --Andre Whitworth
>



-- 
Will "Coke" Coleda

Re: Perl as a better web language ?

[Timothy S. Nelson]

On Sun, 14 Dec 2008, Marc Chantreux wrote:


On Sat, Dec 13, 2008 at 01:34:44PM +1100, Timothy S. Nelson wrote:

On Sat, 13 Dec 2008, howard chen wrote:
What I think is more likely to happen in reality is that people will
make various Perl6 "distros", ie. the Perl6 core + whatever modules are
suitable to the purpose.  So we could have, for example:


 and confuse the users by adding more names in the perl6 world. There
is allready too much words about perl6. Please concider that a newbie
will hear words like PGE,perl6,rakudo,pugs,parrot,PIR,PASM ...


	Hopefully no newbie will hear of PIR and PASM once the final Perl6 is 
out.  And I assume that the distros are easier than worrying about 1001 
modules.



The next point, for me, is that distributions and bundles are just
useless: there are a lot of modules that comes with de standard
distribution i never used and i imagine that no sysop can imagine what
are *my* needs as netop:

- do i need to generate pdf reports to my boss?
- does my servers deal with apple or windows world?
- what kind of applications are running on my servers?


	Well, when I reinstall my machine every few years, there are a few 
software packages that I download and install.  But that's easier than going 
with Linux from Scratch :).  I'm not suggesting that this will be a magic 
bullet any more than Fedora, Debian, or Ubuntu is a magic bullet.



depending to the answers, a lot of modules that would be very important
for one sysop will be useless for me.

when i compare my expects to my observations of others computers users,
i thinks that the best way to distribute perl6 and make it popular is to
provide a minimal installation with a powerfull tool to discover and
install perl6 modules (as dpkg/aptitude/synaptic does).

searching by tags, description, names, using cpan as we use google ...


	Why bother creating a separate tool?  Let's have something that 
automatically feeds CPAN into repositories for apt, yum, and whatever.


Btw, in case you haven't seen it:

http://svn.pugscode.org/pugs/docs/Perl6/Spec/S22-cpan.pod

If you haven't seen that, then you'll want to bookmark this:

http://perlcabal.org/syn/


Diamonds: Perl6 for the web distro (Web people make mony, buy diamonds)
Clubs: Perl6 for systems administrators (club users, before they club you)
Spades: Perl6 for gravediggers (??? :) )

Naturally, the "Diamonds" mentioned above would include a particular
templating system, some XML support, modules for various useful
protocols, and the like.



- my sysop tasks requires template systems, do i have to install diamonds?
 (i think that you think about install Clubs and adding templating
 modules but this is confusing for new people)


	Well, if I were designing Clubs, I'd have put templating in there 
already, but if that wasn't what had happened, then you'd do exactly as you 
said; install Clubs, plus a templating system.



- my minimal set for Diamonds contains LMTP,IPP,XMPP,... but a lot of
 web developpers don't deal with them .. so what to choose ?


	Hmm.  Well, while I think most web developers would want something 
that does e-mail (LMTP), the others would be, as you said, things that people 
would add on to Diamonds.



I guess I can see the value in many of the existing templating systems,
but would like to see a single one designed in a "postmodern" fashion
that can accomodate the supporters of all existing templating systems.


this could be called Utopia!


Quite possibly.  See my other post for more details.


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

Re: Proposal: Make @a and @@a different variables

[Daniel Ruoso]

Em Ter, 2008-12-16 às 18:47 +0100, TSa escreveu:
> >   # the following will require a flatenning to get the actual index
> >   say @a[3];
> Could we not shift the problem into a more complicated form
> of the size of the array? Here it has size 0+3+0 but each of the
> summands could be lazy and hence infinite or at least finite with
> unknown value.

The number of "summands" might be also unknown. i.e.: map.

when you have

  my @a <== map { ... } <== something()

you can't really know how many elements you have in the first
dimension...

> In any case the flat view @a has to step at most the first iterator in
> the array

I'm not sure I see what you mean, but I presume you mean "the first
iteration". In that case, if that iteration returns an empty capture, it
will continue iterating until it returns at least one item. But that
iteration can then return several items which need to be stored in the
lazy list.

> whereas @@a can look beyond that when indexed with a slice, that is
> something with semicolon in it.

Or the iterations of "map" and "grep"...

> An out of bounds access like @a[3] can be answered without flattening,
> right?

I consider counting the number of items in the inner dimension to be (a
simplified) flattening, think of:

  my @@a <== map { $^a == 2 ?? 
  map { $^b == 2 ??
map { $^c == 2 && $b == 2 && $a == 2 ?? (1,2,3)
  !! () }, 1, 2, 3
!! () }, 1, 2, 3
  !! () }, 1, 2, 3;

That would result in

  (();(();(1,2,3);());())

Which is considerably more complex than the first example and have the
following example slice accesses:

  @@a[1]; # returns (();(1,2,3);())
  @@a[1;1]; # returns (1,2,3) 
  @@a[1;1;0] # returns 1

Trying to access @a[0] would result in a recursive flattening until it
gets to the element that would otherwise be accessed by the slice

  @@a[1;1;0]

So it's not just a matter of counting 0-3-0, because to get the first 0,
you need to recursively flatten the inner dimmension until you realize
it's really empty.

If we allow that to be flattened at the beginning, it will simply
consume the iterator until it gets an element.

> In general I'm in favor of making @a and @@a distinct because
> otherwise the first @ in @@a feels like an operator instead like
> a twigil that belongs to the variable like $ belongs to $a which
> is also distinct from @a.

That's an important point. I think it would be consistent that '@@a'
should be the variable name, just as '@a', '$a' or any other. Specially
since '@@' is not a sigil and a twigil, but a sigil of two characters. 

> Since one could also go with a shaped @a I think the choice of @@a
> versus @a is a bit like the choice between a @a and an anonymous array
> in a $ var ala $a = [] which can be handled through $a almost like @a.

I'm not sure I understood that, but I think you're saying that slice
context could be seen just as a regular context, as scalar and list
context, which is something that I agree.

> >   @a =!= @@a :test;
> BTW, what does the :test mean there?

This is the proposed syntax for integration of test-driven-development
in the language built-ins.

daniel

Re: Out of CONTROL...?

[Larry Wall]

On Mon, Dec 08, 2008 at 02:32:14PM -0600, Patrick R. Michaud wrote:
: A very interesting question came up on #perl today, so I'm
: forwarding it to p6l for discussion/decision.
: 
: Given the following code:
: 
: sub foo() { return 1; }
: sub bar() { warn "oops"; }
: 
: {
: CONTROL { ... }
: foo();
: bar();
: }
: 
: S04 seems to clearly indicate that the CONTROL block above would 
: be invoked by the C exception thrown by bar().  The #perl6
: question is, do the same semantics apply for C -- i.e., 
: would the return exception thrown in foo() also invoke the 
: CONTROL block in the caller?
: 
: Both interpretations have validity, which is why I'm bringing
: it here for further reflection and guidance.

foo()'s implicit CONTROL handles the return after checking that the
exception's target context happens to match &?ROUTINE, so the outward
search for a handler terminates at that point.  Doing it the other way
would make it impossible to optimize return into a goto end-of-routine.
Unlike warn, return is normal control flow, and we need to be careful
not to mandate largely useless overhead.

Larry

[svn:parrot-pdd] r33979 - trunk/docs/pdds

[kjs]

Author: kjs
Date: Tue Dec 16 12:09:02 2008
New Revision: 33979

Modified:
   trunk/docs/pdds/pdd19_pir.pod

Log:
[pdd19] change some {{ }} notes in more formal notes, indicating the current 
behaviour, and what it will be like. More cleanups of pdd19 will come after 
more deprecated stuff is removed from the implementation (IMCC). + remove 
example with stack calling conventions.

Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Tue Dec 16 12:09:02 2008
@@ -434,7 +434,9 @@
 constants at compile time, provided that (a) the generated constant can be
 computed at compile time (i.e. doesn't depend on the runtime environment), and
 (b) the constant value is of a PMC class that supports saving in a bytecode
-file [need a freeze/thaw reference].
+file.
+
+{{ TODO: need a freeze/thaw reference }}.
 
 For example, C contains the following (slightly
 abbreviated) definition:
@@ -735,13 +737,15 @@
 A keyed C operation for PMCs or a substring operation for string
 arguments and an integer key.
 
-{{ DEPRECATION NOTE: Possibly deprecate the substring variant. }}
+{{ DEPRECATION NOTE: The substring operation for string arguments is
+   deprecated, and will be removed after the 0.8.2 release. }}
 
 =item  =  [  ]
 
 {{ NOTE: keyed assignment is still valid in PIR, but the C<..> notation in
 keys is deprecated [See RT #48561], so this syntactic sugar for slices is also
-deprecated. See the (currently experimental) C opcode instead. }}
+deprecated. See the (currently experimental) C opcode instead, but
+this, too, is deprecated. }}
 
 where C is:
 
@@ -944,16 +948,17 @@
 
 can also be expanded by writing either C<.foo> or C<.foo()>.
 
-{{ NOTE: this is a change from the current implementation, which requires the
-definition and call of a zero-parameter macro to match in the use of
-parentheses. }}
+B
 
 =over
 
 =item * Heredoc arguments
 
-Heredoc arguments are not allowed when expanding a macro. This means that
-the following is not allowed:
+Heredoc arguments are not allowed when expanding a macro. The next
+implementation of PIR ("PIRC") will be able to handle this correctly.
+This means that, currently, when using IMCC, the following is not allowed:
 
.macro foo(bar)
...
@@ -965,9 +970,6 @@
 
  EOS
 
-{{ NOTE: This is because the parsing of heredocs happens later than the
-preprocessing of macros. Might be nice if we could parse heredocs at the macro
-level, but not a high priority. compilers/pirc/new can do this. }}
 
 Using braces, { }, allows you to span multiple lines for an argument.
 See runtime/parrot/include/hllmacros.pir for examples and possible usage.
@@ -1016,6 +1018,8 @@
 
 =head3 Unique local variables
 
+B.
+
 Within the macro body, the user can declare a local variable with a unique
 name.
 
@@ -1123,62 +1127,73 @@
 
 =head2 Subroutine Definition
 
-  .sub _sub_label []*
-   .param int a
-   .param int b
-   .param int c
-  ...
-  .begin_return
-   .set_return xy
-  .end_return
-  ...
-  .end
+A simple subroutine, marked with C<:main>, indicating it's the entry point
+in the file. Other sub flags include C<:load>, C<:init>, etc.
+
+.sub sub_label :main
+  .param int a
+  .param int b
+  .param int c
+
+  .begin_return
+.set_return xy
+  .end_return
+
+.end
 
 =head2 Subroutine Call
 
-  .const "Sub" $P0 = "_sub_label"
-  $P1 = new 'Continuation'
-  set_addr $P1, ret_addr
-  ...
-  .local int x
-  .local num y
-  .local str z
-  .begin_call
-  .set_arg x
-  .set_arg y
-  .set_arg z
-  .call $P0, $P1# r = _sub_label(x, y, z)
+Invocation of a subroutine. In this case a continuation subroutine is
+created.
+
+.const "Sub" $P0 = "sub_label"
+$P1 = new 'Continuation'
+set_addr $P1, ret_addr
+# ...
+.local int x
+.local num y
+.local string z
+.begin_call
+  .set_arg x
+  .set_arg y
+  .set_arg z
+  .call $P0, $P1# r = _sub_label(x, y, z)
   ret_addr:
-  .local int r  # optional - new result var
-  .get_result r
-  .end_call
+  .local int r  # optional - new result var
+  .get_result r
+.end_call
 
 =head2 NCI Call
 
-  load_lib $P0, "libname"
-  dlfunc $P1, $P0, "funcname", "signature"
-  ...
-  .begin_call
-  .set_arg x
-  .set_arg y
-  .set_arg z
-  .nci_call $P1 # r = funcname(x, y, z)
-  .local int r  # optional - new result var
-  .get_result r
-  .end_call
+load_lib $P0, "libname"
+dlfunc $P1, $P0, "funcname", "signature"
+# ...
+.begin_call
+  .set_arg x
+  .set_arg y
+  .set_arg z
+  .nci_call $P1 # r = funcname(x, y, z)
+  .local int r  # optional - new result var
+  .get_result r
+.end_call
 
 =head2 Subroutine Call Syntactic Sugar
 
-  ...  # variable decls
-  r = _sub_label(x, y, z)
-  (r1[, r2 ...]) = _sub_label(x, y, z)
-  _sub_label(x, y, z)
+Below there are three different ways

Re: Proposal: Make @a and @@a different variables

[Larry Wall]

I think I'm fine with making them separate.  Recursive lazy flattening
seems too evil; slice and list contexts should not try to do the work of
captures.  Thanks.

Larry

Re: Resume from exception

[Larry Wall]

On Mon, Dec 15, 2008 at 03:06:44PM -0700, Stephen Weeks wrote:
: do {
: die 'some text';
: say 'after the exception';
: CATCH {
: say 'caught the exception';
: ...; # what goes here?
: }
: }
: 
: My proposal is to call .resume() on the exception object.

It could just be .thrower.leave, if .thrower can return the &?ROUTINE
of fail() or equivalent.  Note that fail() has not been exited yet,
so it can be left via a simple .leave without requiring continuation
support.  That's one of the reasons we don't unwind the stack while
we're running exception handlers.  Not every VM will provide efficient
continuation support.

That doesn't answer the question of whether resumption *should*
be allowed from a failure that isn't expecting it to continue.
The control flow may well be written such that returning from fail() is
just going to mess things up worse, if the user is not expecting fail()
to return.  On the other hand, returning from warn() is expected, and
other such routines might have such expectations as well.  And the
Resumable role is just moving the arbitrary decision elsewhere,
I suspect.  In the absence of an obvious peg to hang the decision on,
it's going to have to be a process of negotiation between broken code
and exception handlers.

Maybe we just make it easy to leave warnings and other known resumables
with a .resume, and for the dicey cases force the exception handler to
do a caller scan to find the correct fail() to leave if it wants to go
to that trouble.  And we presume that if it goes to that much trouble
to handle an exception, it knows somehow that leaving the fail() is
appropropriate.  But just as likely it will want to throw a 'last',
'next', or 'redo' exception to some outer loop, or maybe enter some
kind of safe mode, if it's a spacecraft.  So I think the exception
handlers have to be trusted to make the final determination of how
to handle exceptions, which seems reasonable.  Engineers who write
bad exception handlers will lose control of their work.

Larry

[svn:parrot-pdd] r33985 - trunk/docs/pdds

[allison]

Author: allison
Date: Tue Dec 16 14:03:21 2008
New Revision: 33985

Modified:
   trunk/docs/pdds/pdd22_io.pod

Log:
[pdd] Remove section on Deprecated Opcodes from I/O PDD, now that all of them
have been removed.


Modified: trunk/docs/pdds/pdd22_io.pod
==
--- trunk/docs/pdds/pdd22_io.pod(original)
+++ trunk/docs/pdds/pdd22_io.podTue Dec 16 14:03:21 2008
@@ -492,8 +492,7 @@
   $P0 = readline $P1, $P2
 
 Retrieves a single line from a stream into a string. Calling
-C flags the stream as operating in line-buffer mode (see
-C below).
+C flags the stream as operating in line-buffer mode.
 
 The asynchronous version takes an additional final PMC callback
 argument, and only returns a status object. When the readline operation
@@ -575,52 +574,6 @@
 
 =back
 
-=head3 Deprecated opcodes
-
-=over
-
-=item *
-
-C provides low-level access to the attributes of a stream
-object. It takes a stream object, an integer flag to select a command,
-and a single integer argument for the command. It returns an integer
-indicating the success or failure of the command.
-
-This opcode has been replaced with methods on the FileHandle object, but
-is kept here for reference. See RT #48589
-
-The following constants are defined for the commands that C can
-execute:
-
-  0PIOCTL_CMDRESERVED
-   No documentation available.
-  1PIOCTL_CMDSETRECSEP
-   Set the record separator. [This doesn't actually work at the
-   moment.]
-  2PIOCTL_CMDGETRECSEP
-   Get the record separator.
-  3PIOCTL_CMDSETBUFTYPE
-   Set the buffer type.
-  4PIOCTL_CMDGETBUFTYPE
-   Get the buffer type
-  5PIOCTL_CMDSETBUFSIZE
-   Set the buffer size.
-  6PIOCTL_CMDGETBUFSIZE
-   Get the buffer size.
-
-The following constants are defined as argument/return values for the
-buffer-type commands:
-
-  0PIOCTL_NONBUF
-   Unbuffered I/O. Bytes are sent as soon as possible.
-  1PIOCTL_LINEBUF
-   Line buffered I/O. Bytes are sent when a newline is
-   encountered.
-  2PIOCTL_BLKBUF
-   Fully buffered I/O. Bytes are sent when the buffer is full.
-
-=back
-
 =head2 Filesystem Opcodes
 
 [Okay, I'm seriously considering moving most of these to methods on the

Re: [perl #37700] [TODO] Changing Default STDOUT/STDERR Filehandles for PIR Code

[chromatic]

On Tuesday 16 December 2008 15:40:32 Allison Randal via RT wrote:

> The simple solution is to add opcodes for 'setstdin', 'setstdout', and
> 'setstderr' that change the interpreter's stored FileHandle PMCs to a
> PMC passed in as an argument. This will not effect any C code that
> directly calls the low-level read/write functions instead of using the
> Parrot_io_* functions, but then C code should pretty much always use the
> Parrot_io_* functions. (Some exceptions to the general rule apply, like
> when the code specifically needs to override any user changes to
> STD[IN|OUT|ERR]).

Do these need to be opcodes?  Can they be methods on the interpreter instead?

-- c

[svn:parrot-pdd] r33998 - trunk/docs/pdds/draft

[chromatic]

Author: chromatic
Date: Tue Dec 16 16:05:40 2008
New Revision: 33998

Modified:
   trunk/docs/pdds/draft/pdd14_numbers.pod

Log:
[PDD] Updated link to IBM's decimal arithmetic library (thanks to Geraud for
finding its new location).

Modified: trunk/docs/pdds/draft/pdd14_numbers.pod
==
--- trunk/docs/pdds/draft/pdd14_numbers.pod (original)
+++ trunk/docs/pdds/draft/pdd14_numbers.pod Tue Dec 16 16:05:40 2008
@@ -582,8 +582,8 @@
 
 =head1 REFERENCES
 
-IBM's Standard Decimal Arithmetic, with tests (sadly, link appears to have
-disappeared)
+IBM's Standard Decimal Arithmetic, with tests
+(L)
 
 The Perl modules Math::BigInt and Math::BigFloat.
 

Re: Proposal: Make @a and @@a different variables

[Moritz Lenz]

TSa wrote:
> HaloO,
> 
> Daniel Ruoso wrote:
>> That being said, we should note that this example looks simple because
>> we have almost no lazyness implied (since there's an assignment in the
>> first line), every list access requires the evaluation of the flatenning
>> of the list.
>> 
>>   my @@a = ((),(1,2,3),());
> 
> Mustn't that be written as (();(1,2,3);()) to produce a three
> element outer view?

Aye, it must.

>>   @a =!= @@a :test;
> 
> BTW, what does the :test mean there?

We discussed the option to change our testing syntax from

ok(@a =!= @@a, '@a and @aa mean different things')
to
  @a =!= @@a :ok('@a and @aa mean different things')
or maybe with :test instead of :ok.

I'll open a thread about that in January, in the hope that the outcome
will enable me to draft S24.

Cheers,
Moritz

[perl #61412] [BUG] binding hash values fails with 'rtype not set'

[via RT]

# New Ticket Created by  Jeff Horwitz 
# Please include the string:  [perl #61412]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61412 >


In r33954 this succeeds in Rakudo:

> my %hash; %hash = 'bar'; say %hash;
bar

but this fails during PAST->POST:

> my %hash; %hash := 'bar'; say %hash;
rtype not set

This worked fine as of r33837.

-jeff

Re: What does a Pair numify to?

[Moritz Lenz]

Jon Lang wrote:
> That's a good point.  Is there an easy way to distinguish between
> passing a pair into a positional parameter vs. passing a value into a
> named parameter?  

Off the top of my head, see S06 for the gory details:

my $pair = a => 'b';

named(a => 'b');
named(:a);
named(|$pair);

positional((a => 'b'));
positional((:a));
positional($pair);

Cheers,
Moritz

Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Steve Peters]

On Tue, Dec 16, 2008 at 12:20 PM, Ron Blaschke  wrote:
> Andrew Whitworth wrote:
>> I'll pick up borland and play with it, although I won't get to it
>> until the next cycle. I've got a really old version of Turbo C++ 4.52
>> left over from school, and free versions of Turbo C++ Explorer are
>> available for download. I don't promise any miracles, but at least I
>> will be able to prove that some errors still exist or not.
>>
>> --Andrew Whitworth
>>
>> On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT
>>  wrote:
>>> On Thu Jan 11 09:55:40 2007, stmpeters wrote:
 On Thu Jan 11 08:57:22 2007, coke wrote:
> Need details.
 A recent patch has gotten Parrot to the point that it can be compiled
 with Borland C++ on Win32.  Unfortunately, it does not link correctly to
 actually create a valid parrot executable.  Additional configuration is
 needed to make Borland compile and link Parrot so that it can actually
 be run and tested.
>>> Without a champion for this compiler, there's not much we can do; Our 
>>> current targets for
>>> Windows include, as I understand it, cygwin, strawberry perl and its build 
>>> system, and recent
>>> versions of VisualC++. Borland isn't in our core list for the upcoming 1.0 
>>> release.
>>>
>>> If we do find a Borland champion, they should open a new ticket at 
>>> https://trac.parrot.org/.
>>>
>>> Rejecting this ticket; Regards.
>
> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
> and 5.82, and failed miserably.  But that may just be my bad bcc-foo.
> Unless someone's keen for this platform and has access to a fairly new
> ("within two years") version (is it called C++ Builder now?), I'm not
> sure if this is worth pursuing.
>
> Ron
>

The issue I ran into at the time was that dmake, which was the usual
make program used with bcc32, is not capable of handling the Parrot
make file.  I believe it could work with gmake on win32, but I hadn't
really attempted anything down that direction since I was encountering
too many other issues following a major restructuring of the headers
that had occurred.

Steve

[perl #61420] [PATCH] Add support for .succ and .pred for Int, Num and Str

[Eric Hodges]

# New Ticket Created by  "Eric Hodges" 
# Please include the string:  [perl #61420]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61420 >



Index: src/classes/Int.pir
===
--- src/classes/Int.pir	(revision 33937)
+++ src/classes/Int.pir	(working copy)
@@ -37,6 +37,24 @@
 .end
 
 
+=item succ and pred
+
+Increment and Decrement Methods
+
+=cut
+
+.sub 'succ' :method
+$P0 = clone self
+inc $P0
+.return ($P0)
+.end
+
+.sub 'pred' :method
+$P0 = clone self
+dec $P0
+.return ($P0)
+.end
+
 =item ACCEPTS()
 
 =cut
Index: src/classes/Str.pir
===
--- src/classes/Str.pir	(revision 33937)
+++ src/classes/Str.pir	(working copy)
@@ -113,7 +113,25 @@
 .return ($P0)
 .end
 
+=item succ and pred
 
+Increment and Decrement Methods
+
+=cut
+
+.sub 'succ' :method
+$P0 = clone self
+inc $P0
+.return ($P0)
+.end
+
+.sub 'pred' :method
+$P0 = clone self
+dec $P0
+.return ($P0)
+.end
+
+
 =item WHICH()
 
 Returns the identify value.
Index: src/classes/Num.pir
===
--- src/classes/Num.pir	(revision 33937)
+++ src/classes/Num.pir	(working copy)
@@ -67,6 +67,25 @@
 .end
 
 
+=item succ and pred
+
+Increment and Decrement Methods
+
+=cut
+
+.sub 'succ' :method
+$P0 = clone self
+inc $P0
+.return ($P0)
+.end
+
+.sub 'pred' :method
+$P0 = clone self
+dec $P0
+.return ($P0)
+.end
+
+
 =item WHICH()
 
 Returns the identify value.

Re: Support for ensuring invariants from one loop iteration to the next?

[Timothy S. Nelson]

On Tue, 16 Dec 2008, David Green wrote:


On 2008-Dec-6, at 7:37 am, Aristotle Pagaltzis wrote:
Funnily enough, I think you?re onto something here that you didn?t even 
notice: [...]
if we had a NOTFIRST (which would run before ENTER just as FIRST does, but 
on *every* iteration *except* the first), then we could trivially attain 
the correct semantics and achieve all desired results:


  repeat {
  @stuff = grep { !.valid }, @stuff };
  NOTFIRST {
  .do_something( ++$i ) for @stuff;
  }
  } while @stuff;

The really nice thing about this is that the blocks are nested, so that any 
variable in scope for the invariant enforcement will also be in scope in 
the NOTFIRST block without the user ever having to arrange another 
enclosing scope.


Oh, yes!  So what if we had "LOOP $n {}" that executed on the nth iteration? 
"LOOP 0 {}" at the beginning would be like FIRST {}, "LOOP * {}" at the end 
would be like LAST {}, and "LOOP 1..* {}" would give us the NOTFIRST block. 
Presumably you could have multiple LOOP blocks too.


(Actually, you couldn't quite do FIRST/LAST using LOOP $n, because FIRST/LAST 
occur outside ENTER/LEAVE, whereas LOOP would occur inside.  But perhaps you 
could have LOOP blocks inside ENTER/LEAVE blocks?)


	Or, instead of having a new block, just add the iterator indicator to 
the NEXT block, and get rid of ENTER and LEAVE.  That way, you'd have this 
sequence:


-   FIRST {}
-   NEXT 0 {} # Replaces ENTER
-   NEXT 1..* {} # Does NOTFIRST
-   NEXT * {} # Replaces LEAVE
-   LAST {}

Would that do it?

	The difficulty to my mind would be sequencing the NEXT blocks; does 
the NEXT 1..* run before or after NEXT 2..(*-2) ?  Maybe we need a NEXT stack.


:)


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

Re: Support for ensuring invariants from one loop iteration to the next?

[Jon Lang]

How do you compute '*'?  That is, how do you know how many more
iterations you have to go before you're done?

Should you really be handling this sort of thing through an "iteration
count" mechanism?  How do you keep track of which iteration you're on?
 Is it another detail that needs to be handled behind the scenes, or
is the index of the current iteration available to the programmer?
(Remember, we're dealing with 'while' and 'loop' as well as 'for'.)

-- 
Jonathan "Dataweaver" Lang

Re: Support for ensuring invariants from one loop iteration to the next?

[Timothy S. Nelson]

On Tue, 16 Dec 2008, Jon Lang wrote:


How do you compute '*'?  That is, how do you know how many more
iterations you have to go before you're done?


	In some cases, it won't have to be computed, in some cases it won't be 
computeable (which should be an error).  I'd say it'd be fair enough to say 
that 1..(*-1) should be an error in non-bounded(?) loops (ie. while).  Just 
figure things out when we can, and when we can't, give an error.



Should you really be handling this sort of thing through an "iteration
count" mechanism?  How do you keep track of which iteration you're on?
Is it another detail that needs to be handled behind the scenes, or
is the index of the current iteration available to the programmer?
(Remember, we're dealing with 'while' and 'loop' as well as 'for'.)


	I'd say track it if necessary, kinda like the regex variables in Perl5 
that imposed a performance hit.  Have a magic variable that tracks the loop 
count if:

-   The variable is referred to anywhere
-   Any of the NEXTs require it

	It seems like the NEXT queue I suggested is already specced (although 
without the iterator count thingies).


	I'm also starting to wonder what we do with the return values of the 
NEXT blocks :).


:)


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

Re: Working with files wish list

[Leon Timmermans]

On Tue, Dec 16, 2008 at 7:04 AM, jason switzer  wrote:
> I hadn't seen a Nameable role mentioned yet, so I wasn't able to understand
> any such concept.

The list was not meant to be exhaustive. There are a lot more roles
that have something to do with IO but were missing: Asynchronous IO,
Datagram sockets, and more (specially when you add in platform
specific stuff). The whole idea is that almost any operation you can
do on one kind of handle can be done on some other kind too. There is
a lot of overlap between seemingly unrelated types of handles. In this
case, files and unix domain sockets are created and used in rather
different ways, but both have a place in the filesystem, so it would
be appropriate that they share the interface for retrieving that
location.

> That is a good idea, but the idea is so general that
> anything can be nameable and thus the specificity of the role could quickly
> become lost. I was suggesting specific naming functionalities be added to
> the File role. If you want to abstract that, that's fine, but beware that
> something like Nameable can be too broad of a role (maybe just IONameable?).

I agree Nameable isn't the best name. How about Locatable? Having said
that, I suppose a generic Nameable role providing a human readable
designation to a handle (as opposed to one for computers) would be
useful too, if only for error messages.

> I haven't spent the time to understand mix-ins yet, but this does look like
> a feasible (clean) idea. However, how do you specify one/more filters? For
> example, say you want to :rw a file. How can you provide an input filter and
> an output filter (or multiples of either)? Can you layer filters if done
> with mix-ins?

Stacking can be done:

$fstab does WhitespaceTrim does TranslateKlingon;

I'm not sure if this is the best way to approach the problem though.
This is a power drill, a screwdriver will also do in many cases.

> If so, how do you specify direction?

That would be a problem with this approach. You'd probably need
separate roles for readers and writers.


Regards,

Leon Timmermans

Re: [perl #61412] [BUG] binding hash values fails with 'rtype not set'

[Patrick R. Michaud]

On Tue, Dec 16, 2008 at 10:02:23AM -0800, Jeff Horwitz wrote:
> # New Ticket Created by  Jeff Horwitz 
> # Please include the string:  [perl #61412]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=61412 >
> 
> 
> In r33954 this succeeds in Rakudo:
> 
> > my %hash; %hash = 'bar'; say %hash;
> bar
> 
> but this fails during PAST->POST:
> 
> > my %hash; %hash := 'bar'; say %hash;
> rtype not set
> 
> This worked fine as of r33837.

The addition of the capability to do array and hash slices has
cause binding of array and hash elements to fail.  I decided
that slices and list assignment were more important right now
than binding elements of aggregates, so we've regressed there
for now.

I don't see a short-term fix on the horizon, as we'll have to
figure out exactly how we're going to handle such bindings/references
in the future.  Parrot isn't exactly set up for handling this
easily in a HLL like Perl 6, I'm afraid.

Pm

6PAN idea

[Timothy S. Nelson]

	Hi all.  I've been working on some stuff that's vaguely, tangentially 
CPAN-related.


	My basic assumption is that there's going to be some kind of packaging 
system written around 6PAN.


	One thing I've been working on recently is a (Perl 5) object that 
models package metadata.  In theory, it should be able to model the metadata 
from a .rpm, a .deb, a CPAN package, or whatever.  Then you read the data 
using a "metadata input class", and write it using a "metadata output class". 
This would mean that eg. CPAN metadata could be turned into RPM metadata, but 
also vice versa.  Debian would naturally be convertible into either of these.


	The model isn't CPAN-specific, but relying on such a setup would save 
work for everyone.


Thoughts?

:)


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

Re: r24325 - docs/Perl6/Spec

[Patrick R. Michaud]

On Mon, Dec 15, 2008 at 11:18:54PM -0500, Mark J. Reed wrote:
> On Mon, Dec 15, 2008 at 5:41 PM, Moritz Lenz  wrote:
> > I know at least of infix:(Num $a, Num $b) (which does the same as
> > Perl 5's <=>) and infix:(Pair $a, Pair $b) (which does $a.key cmp
> > $a.key || $a.value cmp $b.value), so numbers and pairs DWIM.
> 
> 
> Hm.  Rakudo doesn't let me cmp pairs at all currently:
> 
> >  (a => 2) cmp (a => 10)
> >
> Multiple Dispatch: No suitable candidate found for 'cmp', with signature
> > 'PP->I'

It does now:

> say (a => 2) cmp (a => 10);
-1

S02:1600 somewhat implies that comparison of pairs is based on
keys by default, then on values if keys are equal.  Rakudo
implements this behavior.

In particular, one can now quickly print out a hash sorted by key
using C<<  .say for %hash.sort  >>:

my %hash =  Z 1..4;  
.say for %hash.sort;

language4
parrot  1
speaks  2
your3

Pm

[perl #61420] [PATCH] Add support for .succ and .pred for Int, Num and Str

[Patrick R. Michaud via RT]

Applied in r34011, thanks!

Pm

Re: 6PAN idea

[Brandon S. Allbery KF8NH]

On 2008 Dec 16, at 23:00, Timothy S. Nelson wrote:
	One thing I've been working on recently is a (Perl 5) object that  
models package metadata.  In theory, it should be able to model the  
metadata from a .rpm, a .deb, a CPAN package, or whatever.  Then you  
read the data using a "metadata input class", and write it using a  
"metadata output class". This would mean that eg. CPAN metadata  
could be turned into RPM metadata, but also vice versa.  Debian  
would naturally be convertible into either of these.


	The model isn't CPAN-specific, but relying on such a setup would  
save work for everyone.


Thoughts?



You might want to look at "alien" first, to get an idea of what can be  
done --- and what can't.


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

Re: 6PAN idea

[Timothy S. Nelson]

On Tue, 16 Dec 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Dec 16, at 23:00, Timothy S. Nelson wrote:
	One thing I've been working on recently is a (Perl 5) object that 
models package metadata.  In theory, it should be able to model the 
metadata from a .rpm, a .deb, a CPAN package, or whatever.  Then you read 
the data using a "metadata input class", and write it using a "metadata 
output class". This would mean that eg. CPAN metadata could be turned into 
RPM metadata, but also vice versa.  Debian would naturally be convertible 
into either of these.


	The model isn't CPAN-specific, but relying on such a setup would save 
work for everyone.


Thoughts?



You might want to look at "alien" first, to get an idea of what can be done 
--- and what can't.


Good idea.  Just to clarify some things:
-   The package I'm talking about only models metadata; it doesn't worry
about the rest of the stuff
-   My idea was to support all reasonable metadata (within reason, but I
haven't yet run across anything I think unreasonable), and then emit
warnings  when metadata isn't supported by a particular backend.

:)


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

Re: Support for ensuring invariants from one loop iteration to the next?

[David Green]

On 2008-Dec-16, at 6:21 pm, Timothy S. Nelson wrote:
	Or, instead of having a new block, just add the iterator indicator  
to the NEXT block, and get rid of ENTER and LEAVE.  That way, you'd  
have this sequence:

-   FIRST {}
-   NEXT 0 {} # Replaces ENTER
-   NEXT 1..* {} # Does NOTFIRST
-   NEXT * {} # Replaces LEAVE
-   LAST {}

Would that do it?


Not quite -- the idea is that you could put the LOOP block anywhere in  
the body of the loop, and it would execute at that point.  NEXT and  
friends always occur at the end (or beginning) of their block.


Nor would it work to take an existing block like NEXT and allow it to  
be positioned in the middle of the body, because it wouldn't be  
possible to duplicate what they already do -- in this example, the  
NEXT wouldn't get executed when "next if something()" occurs:


loop
{
next if something();
a;
NEXT { ... }
b;
}



On Tue, 16 Dec 2008, Jon Lang wrote:

How do you compute '*'?  That is, how do you know how many more
iterations you have to go before you're done?


	In some cases, it won't have to be computed, in some cases it won't  
be computeable (which should be an error).  I'd say it'd be fair  
enough to say that 1..(*-1) should be an error in non-bounded(?)  
loops (ie. while).


That sounds right to me.  Does 'for @foo' take a snapshot of @foo, or  
can you change the bounds by changing @foo while the loop is running?   
In which case trying to count back from * might be an error for  
anything except constant bounds.



-David

[perl #61410] Resolved [Re: perl6 build errors on Debian stable "Etch" (parrot svn trunk rev 33776 and before)

[via RT]

# New Ticket Created by  Jochen Plumeyer 
# Please include the string:  [perl #61410]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=61410 >


Hi again, 

just to give the positive feedback: No build issues anymore since parrot svn 
revision 33960 ( and it seems some revisions before )

All perl6 tests are running successfully.

Cheers, and keep up the good work,

Jochen

On Wednesday December 10 2008 16:54, Jochen Plumeyer wrote:
> Hi folks,
>
> in the last days I tried several times with the respective latest svn trunk
> of parrot to build perl6 to play with it, but always the build failed. I
> use Debian stable vanilla Linux, no strange configurations. I can  verify
> this with a fresh install in a virtual machine if that helps.
>
> I tried it with perl 5.8.8 (Debian package) and 5.10.0 (installed
> in /opt/perl/ ).
>
> What I did (here using perl-5.10.0):
>
> svn up
> svn export . /tmp/parrot
> cd /tmp/parrot
> /opt/perl/bin/perl Configure.pl
> make
> make -C languages/perl6/ perl6
>
> Error message:
> ==
> error:imcc:syntax error, unexpected VAR, expecting '(' ('var')
> in file 'src/builtins/op.pir' line 430
> included from 'src/gen_builtins.pir' line 25
> included from 'perl6.pir' line 1
> ==
>
> Did I miss something?
>
> Cheers,
>
> Jochen