Re: perl6-synopsis svn

[Agent Zhang]

On 2/23/07, Blair Sutton <[EMAIL PROTECTED]> wrote:


Sorry if this is a silly question but I haven't been able to find the
answer. Is the perl6-synopsis SVN repository publicly available or is it
in the same repository as that of Parrot or Pugs?



I think you're looking for this:

http://svn.perl.org/perl6/doc/trunk/design/syn/

Cheers.

[PATCH] PDD16 NCI update with simple example

[Klaas-Jan Stol]

hi,

I've been playing with NCI calls and more fun (embedding a Parrot, that 
runs a PIR program, which invokes a C function, that then invokes a PIR 
callback function).


As a result, I added a simple example to PDD16. I didnt' put too much 
work in it (there are many more places that could be improved), because 
I didn't know if updating this doc is desirable at this moment (any big 
changes pending?).


If desired, I'd be happy to do more updates. Please let me know.
At least there's full working code to do a simple NCI invocation.

regards,
klaas-jan

Index: docs/pdds/draft/pdd16_native_call.pod
===
--- docs/pdds/draft/pdd16_native_call.pod	(revision 17146)
+++ docs/pdds/draft/pdd16_native_call.pod	(working copy)
@@ -126,8 +126,48 @@
 =head2 Examples
 
 Most of the function parameters are reasonably self-evident. Some, however,
-merit additional explanation. The {{ ??? }}
+merit additional explanation.
 
+This section describes the simplest example for NCI possible. To every NCI
+invocation, there are two parts: the native function to be invoked, and the
+PIR code to do the invocation.
+
+First the native function, to be written in C.
+On Windows, it is necessary to do a DLL export specification of the NCI function:
+
+  /* foo.c */
+
+  /* specify the function prototype */
+
+	void foo(void);
+
+  /* or on Windows using Microsoft Visual Studio: */
+
+  __declspec(dllexport) void foo(void);
+
+  void foo(void) {
+printf("Hello Parrot!\n");
+  }
+
+Then, after having compiled the file as a shared library, the PIR code looks
+like this:
+
+  .sub main :main
+ .local pmc lib, func
+
+ # load the shared library
+ lib = loadlib "hello" # no extension, .so or .dll is assumed
+
+ # get a reference to the function from the library just
+ # loaded, called "foo", and signature "void" (and no arguments)
+ func = dlfunc lib, "foo", "v"
+
+ # invoke
+ func()
+
+  .end
+
+
 =head2 Callbacks
 
 Some libraries, particularly ones implementing more complex functionality such
@@ -224,9 +264,9 @@
 Maintainer: Dan Sugalski
 Class: Internals
 PDD Number: 16
-Version: 1.1
+Version: 1.2
 Status: Developing
-Last Modified: Oct 12, 2004
+Last Modified: Feb 23, 2007
 PDD Format: 1
 Language: English
 
@@ -234,6 +274,10 @@
 
 =over 4
 
+=item version 1.2
+
+Updated with basic example.
+
 =item version 1.1
 
 Changed callback section to reflect current status.
@@ -248,6 +292,10 @@
 
 =over 4
 
+=item version 1.2
+
+Updated with basic example.
+
 =item version 1.1
 
 Changed callback section to reflect current status.

Re: [svn:parrot] r17107 - trunk/src/stm

[jerry gay]

On 2/22/07, Allison Randal <[EMAIL PROTECTED]> wrote:

'mark_extracted' should have the guard added. The same one should work.
As intended, it is marking all the read_records and write_records. There
just happen to be none to mark.


added in r17159, thanks.
~jerry

Re: Porting parrot on PDA

[jerry gay]

On 2/8/07, Hakim Cassimally <[EMAIL PROTECTED]> wrote:

I'm keen to port to maemo (Nokia N800) - I'm guessing this
will be easier as it's based on debian linux and uses
scratchbox for cross compilation, but I believe it doesn't
built out of the box.

I'd like to join the porting effort if there's enough crossover
to be able to help on this,


now that we've finished the latest monthly release, we've got some
time to devote to this effort. we'd love to have parrot ported to
N800. when you've got the time, run C. if there are errors, send the output to E<[EMAIL PROTECTED]>
so we can track the ticket in RT.

~jerry

Re: Cross-compiling Parrot

[Aldo Calpini]

Allison Randal ha scritto:
We do. Unfortunately we can't rely on Perl 5 for the configure system. 
It may seem like an easy way to gain cross-compilation in the short 
term, but in the long term it will hurt us.


Miniparrot is the right way to go. It certainly needs work, though. As 
you're thinking of solutions think of what miniparrot would need to 
become cross-compiler aware.


ok. I can't say that that I fully understand why, but I trust you.


> woot! I am _not_ going to become a pir programmer, sorry :-)

You'll be surprised at how easy it is to pick up, especially if you 
have experience with dynamic languages. There are, of course, plenty 
of Parrot tasks that don't require PIR skills, but don't give up 
before you try it. You might like it.


please, don't get me wrong. I have absolutely nothing against PIR, is 
just that I'm so damn fluent in Perl5 :-)


I follow Parrot from the day it was born, I even wrote some - crude, I 
admit it - code in PASM something like 4 years ago 
(http://dada.perl.it/shootout/parrot_allsrc.html). but when the first 
IMCC appeared, I felt it was just too much. maybe PIR nowadays isn't as 
complicated as it was when I left it, I don't know. I will certainly 
give it a closer look.


That being the case, let's start you out submitting patches. It's 
where everyone starts, and having a mentor to review patches at first 
is a great way to pass along the knowledge of the experienced Parrot 
hackers.


For a change this size, we generally start with a proposal, review it 
as a group, and then dive into implementation. In this case, given the 
nature of the problem and your experience with the codebase, go ahead 
and start experimenting with code, but write up your plans as you go. 
We'll do an architecture review before too long to see how well the 
idea fits with the overall plans for Parrot.


I just sent a first patch today (which is small and mostly^W harmless), 
commenting what will be my next step(s). I have no "big plan" yet, it's 
just a configure-fix-patch-reconfigure cycle, so I try to approach 
obstacles as they pop out. when I come to the point that I will need a 
"stronger" patch, something that may impact the overall architecture, I 
intend to sit down and think about it for a while, write it down and 
submit it for your approval.


thank you for your attention and wise words :-)

cheers,
Aldo

Weekly Perl 6 mailing list summary for 21-28 January, 2007

[Ann Barcomb]

 This week on the Perl 6 mailing lists

"Take the longest token, lie down and if the unease persists, write
some code..."

-- Brad Bowman, in 'DFA/NFA context is non-local '


 perl6-language

  RAII in Perl6/Parrot 

Previously on this thread, Blair Sutton asked if Perl 6 would be able
to do RAII. He cited some articles which expressed the view that it
was not possible in Python due to the fact that garbage collection
does not offer deterministic finalization. This led to the question of
whether Perl 6 would suffer from the same problem due to Parrot's
style of garbage collection.

Larry Wall replied that deterministic reference counting was only one
way to provide transactional security and timely destruction. He
assured Blair that Perl 6 has ways to let you not care about some
dependencies, while paying attention to others.

Blair appreciated Larry's explanation, and admitted to relying on the
deterministic nature of C++, and using RAII to manage locks between
threads and tear apart sockets cleanly. He asked for an example of
Perl 6 offering the capability to execute code once every reference to
an object has been removed. Luke Palmer replied that the LEAVE closure
trait was a general method for addressing this.

This week, Blair posted a script in Perl 5 with a multi-threaded RAII
idiom. Blair asked if the LEAVE closure trait takes the previous role
of P5's DESTROY or if it will always be executed when one falls out of
scope.

  Numeric Semantics 

Last week, the subthread was further expanded, with TSa suggesting
that all rounding functions such as floor, round and trunc take an
optional second argument which defines the jump size. TSa also
proposed a number of division function pairs, such as fdiv and fmod
for flooring division and modulus, or tdiv and tmod for truncating
division and modulus. Smylers felt that this would introduce far too
many functions in to the Perl core, given that few people would use
them. Smylers felt that it was more appropriate to have them as
modules. Jonathan Lang added that it was unlikely anyone would need
multiple definitions of division and modulus at any given time, so
modules made sense. The only question he saw was which definition was
default, the mathematically elegant one or the industry standard one.

The main thread was revived when TSa replied to Luke Palmer's question
of whether 1 is different from 1.0. TSa wanted 1 to be an Int and 1.0
to be a Num. There was some discussion with Jonathan Lang over the
relationship between Int and Num, specifically which one does the
other.

This week, Larry Wall put his foot down and stated that the default
`/` operator is not going to do integer division and that this is not
negotiable. Later in the thread, Larry said that for various practical
reasons, he didn't think that Int can be treated as a subset of Num.
He agreed that `1.0 == 1 !=== 1.0`.

Larry's messages generated praise from Smylers, but TSa was not
satisfied. However, he did not receive a noteworthy response this
week.

  [svn:perl6-synopsis] r13523 - doc/trunk/design/syn 

This commit message by Larry Wall logged the following: "Tweak `|` to
provide longest-token instead of short-circuit semantics. Now use `||`
for old short-circuit semantics!" In a follow-up message, Larry
elaborated:

This checking majorly changes the semantics of `|` within regex to
support required longest-token matching semantics rather than
left-to-right matching. It will enable us to write parsers more
consistently, and it also opens up normal regexes to better
optimization via tries and such. You can now use `||` for the old `|`
semantics, which is majorly consistent with how `|` and `||` work
outside of regexen.

Patrick Michaud asked if a similar situation would arise for `&`
versus `&&`. Larry answered that, for reasons of consistency, that
would indeed be the case.

  The S13 "is commutative" trait 

After reading that binary operators may be declared as commutative,
Dave Whipp asked if this is restricted to only binary operators, or if
he could tag any function/method with the trait. After a brief
discussion, Larry replied that he had decided "is commutative" must
die of ill-definedness. See instead the recent S13 change to support
multiple signatures on a single body.

  [svn:perl6-synopsis] r13529 - doc/trunk/design/syn 

This commit, by Larry Wall, changes how regular expressions are
analyzed. They are seen as pattern/action pairs and grammars as
collections of those pairs. In addition 'token' is defined more
rigorously.

  Remember: Outlaw to declare a lexical twice in the sa

Re: [svn:parrot] r17107 - trunk/src/stm

[chromatic]

On Thursday 22 February 2007 00:28, you wrote:

> chromatic wrote:

> >> +if (saved_log_data == NULL)
> >> +return;
> >> +
> >>  saved = saved_log_data;
> >>  mem_sys_free(saved->reads);
> >>  mem_sys_free(saved->writes);

> > I'm not sure this is the right fix; there's little reason to use an
> > STMLog PMC if it doesn't get a valid transaction log.  My vote is for the
> > PMC's init() to throw an exception.

> > If that's not the case, then at least both of Parrot_STM_mark_extracted()
> > and Parrot_STM_replay_extracted() need similar null guards.
>
> It makes sense here to return with no action, since all the routine does
> is free memory. If the memory wasn't used, it doesn't need to be freed.

Yes, if STMLog can ever possibly hold a null pointer.  I'm asking if that 
should ever be possible.

All these guards do is protect against STMLog being in an inconsistent state.  
Now that may be the right solution.  It may not.  I dug into this a bit more 
to try to find out *why* STMLog can be in an inconsistent state.

In src/pmc/stmlog.pc, init() calls Parrot_STM_extract() and uses the return 
value, unchecked, for the PMC's struct val.  destroy(), mark(), and replay() 
all pass the struct val unchecked to other Parrot_STM_*() functions.

particle's test exposed a condition in which that struct val can be a null 
pointer, and dereferencing that in Parrot_STM_*() causes segfaults.

Putting the null guard in the Parrot_STM_*() functions papers over that 
symptom, but it also means that we have to catch every use of the STMLog 
PMC's struct val and add a null guard there too, or we'll have more code 
paths that cause segfaults.

How could the struct val be a null pointer?  It's in src/stm/backend.c, the 
function Parrot_STM_extract(), on line 1241.  If there's no current 
transaction, it's not possible to return a pointer for the transaction log, 
and so this function returns null, and the STMLog PMC stores a null pointer.

Semantically, to me that means that there *is* no valid STMLog PMC.

I don't know if that means that STMLog should throw an exception in its init() 
if there's no transaction log available, or if it should morph to Undef, or 
if it should continue doing what it's doing, but I do think it should be 
clearer that there's no valid transaction log at this point, as it's outside 
of any transaction.

Fixing the problem there--not allowing an STMLog PMC to have a null struct 
val--would mean never having to worry if it's in an inconsistent state, and 
we could remove all of the null guards and never have to worry if we've 
missed one.

I think that's an important characteristic of the right solution, whatever the 
right solution is.

-- c

[S09] "Whatever" indices and shaped arrays

[Jonathan Lang]

From S09:

"When you use * with + and -, it creates a value of Whatever but Num,
which the array subscript interpreter will interpret as the subscript
one off the end of that dimension of the array."

"Alternately, *+0 is the first element, and the subscript dwims from
the front or back depending on the sign. That would be more
symmetrical, but makes the idea of * in a subscript a little more
distant from the notion of 'all the keys', which would be a loss, and
potentially makes +* not mean the number of keys."

If '*+0' isn't the first element, then '*+$x' is only meaningful if $x < 0.

That said, I think I can do one better:

Ditch all of the above.  Instead, '*' always acts like a list of all
valid indices when used in the context of postcircumfix:<[ ]>.

If you want the last index, say '*[-1]' instead of '* - 1'.
If you want the first index, say '*[0]' instead of '* + 0'.

So the four corners of a two-dimensional array would be:

 @array[ *[0]; *[0] ];  @array[ *[-1]; *[0] ];
 @array[ *[0]; *[-1] ]; @array[ *[-1]; *[-1] ];

The only thing lost here is that '@array[+*]' is unlikely to point
just past the end of a shaped array.  But then, one of the points of
shaped arrays is that if you point at an invalid index, you get a
complaint; so I don't see why one would want to knowingly point to
one.

--

Also, has the syntax for accessing an array's shape been determined
yet?  If not, I'd like to propose the following:

@array.shape returns a list of lists, with the top-level list's
indices corresponding to the dimensions of the shape and each nested
list containing every valid index in that dimension.  In boolean
context, the shape method returns true if the array is shaped and
false if not - though an unshaped array will otherwise pretend to be a
one-dimensional, zero-based, non-sparse, shaped array.

So:

 @array.shape[0][2] # the third valid index of the first dimension of the shape
 @array.shape[-1][0] # the first valid index of the last dimension of the shape
 @array.shape[1] # every valid index of the second dimension of the shape
 @array.shape[1][*] # same as @array.shape[1]

 [EMAIL PROTECTED] # is this a shaped array?

 exists @array.shape[2] # does the array have a third dimension?
 exists @array.shape[3][4] # does the fourth dimension have a fifth element?

 [EMAIL PROTECTED] # how many dimensions does the shape have?
 [EMAIL PROTECTED] # how many indices does the first dimension have?

If we use this notation, then

 @array[ *; * ]

is shorthand for

 @array[ @array.shape[0]; @array.shape[1] ]

--
Jonathan "Dataweaver" Lang

[perl #40626] [BUG] :vtable fails for subclasses of core classes

[Jerry Gay via RT]

this bug seems to be resolved as of r17163. however, i'm not closing
this ticket until the example code in the original post is added as a test.
~jerry

[PATCH] languages/PIR update pirgrammar.pod

[Klaas-Jan Stol]

hi,

attached an update for languages/PIR/docs/pirgrammar.pod

fixing:

0.1.3

   *

 Updated short sub invocation for NCI invocations.

   *

 Added an example for |.globalconst|.

   *

 Added some remarks at section for Macros.

   *

 Added some remarks here and there, and fixed some style issues.


The document languages/PIR/docs/pirgrammar.html should be removed from 
the repository -- don't know how to do this. Then later, we can 
generated it via the make file.


regards,
klaas-jan

Index: languages/PIR/docs/pirgrammar.pod
===
--- languages/PIR/docs/pirgrammar.pod	(revision 17146)
+++ languages/PIR/docs/pirgrammar.pod	(working copy)
@@ -16,10 +16,16 @@
 The grammar includes some constructs that B in the IMCC parser,
 but are not implemented. An example of this is the C<.global> directive.
 
+Please note that languages/PIR is B the official definition of the
+PIR language. The reference implementation of PIR is IMCC, located
+in C. However, languages/PIR tries to be as close
+to IMCC as possible. IMCC's grammar could use some cleaning up;
+languages/PIR might be a basis to start with a clean reimplementation of
+PIR in C (using Lex/Yacc).
 
 =head1 VERSION
 
-0.1.2
+0.1.3
 
 =head1 LEXICAL CONVENTIONS
 
@@ -375,6 +381,7 @@
   local_decl
 | lexical_decl
 | const_def
+| globalconst_def
 | conditional_stat
 | assignment_stat
 | open_namespace
@@ -502,6 +509,27 @@
 assign a floating point number to an integer constant. The PIR parser will
 check for this.
 
+
+=head2 Global constant definitions
+
+  globalconst_def:
+".globalconst" type identifier "=" constant_expr
+
+=head3 Example global constant definitions
+
+This directive is similar to C, except that once a C
+has been defined, it is accessible from B subroutines.
+
+  .sub main :main
+.global const int answer = 42
+foo()
+  .end
+
+  .sub foo
+print answer # prints 42
+  .end
+
+
 =head2 Conditional statements
 
   conditional_stat:
@@ -518,7 +546,7 @@
 
   if null $P0 goto L1
 
-Checks whether $P0 is C, if it is, flow of control jumps to label L1
+Checks whether C<$P0> is C, if it is, flow of control jumps to label C
 
   unless $P0 goto L2
   unless x   goto L2
@@ -725,6 +753,26 @@
 are  stored as well.
 
 
+In IMCC, a heredoc identifier can be specified as an argument, like this:
+
+foo(42, "hello", <<'EOS')
+
+This is a heredoc text argument.
+
+  EOS
+
+In IMCC, only B such argument can be specified. The languages/PIR implementation
+aims to allow for B number of heredoc arguments, like this:
+
+foo(<<'STR1', <<'STR2')
+
+  	argument 1
+  STR1
+argument 2
+  STR2
+
+B
+
 =head2 Invoking subroutines and methods
 
   sub_invocation:
@@ -880,8 +928,27 @@
   arr[1] = 43
   foo(arr :flat, $I0 :named('intArg'))
 
-Please note that the short subroutine call does B allow for C calls.
+In order to do a Native Call Interface invocation, the subroutine to be invoked needs to be in referenced
+from a PMC register, as its name is B visible from Parrot. A NCI call looks like this:
 
+  .local pmc nci_sub, nci_lib
+  .local string c_function, signature
+
+  nci_lib = loadlib "myLib"
+
+  # name of the C function to be called
+  c_function = "sayHello"
+
+  # set signature to "void" (no arguments)
+  signature  = "v"
+
+  # get a PMC representing the C function
+  nci_sub = dlfunc nci_lib, c_function, signature
+
+  # and invoke
+  nci_sub()
+
+
 =head2 Return values from subroutines
 
 
@@ -1056,12 +1123,21 @@
 "(" id_list? ")"
 
   macro_body:
-.*?
+*
 ".endm" nl
 
   macro_invocation:
 macro_id parenthesized_args?
 
+
+Note that before a macro body will be parsed, some grammar rules
+will be changed. In a macro body, local variable declaration can
+B be done using the C<.sym> directive. The C<.local> directive
+is only available for declaring labels.
+
+  macro_label:
+".local" "$"identifier":"
+
 =head3 Example Macros
 
 When the following macro is defined:
@@ -1079,7 +1155,7 @@
 .add2(myNum)
 print myNum  # prints 44
   .end
-
+
 =head2 PIR Pragmas
 
   pragma:
@@ -1256,6 +1332,9 @@
 appreciated. Moreover, if you find any missing constructs that are in
 IMCC, indications of these would be appreciated as well.
 
+Please see the PROPOSALS document for some proposals of the author to
+clean up the official grammar of PIR (as defined by the IMCC compiler).
+
 =back
 
 =head1 REFERENCES
@@ -1286,6 +1365,29 @@
 
 =head1 CHANGES
 
+0.1.3
+
+=over 4
+
+=item *
+
+Updated short sub invocation for NCI invocations.
+
+=item *
+
+Added an example for C<.globalconst>.
+
+=item *
+
+Added some remarks at section for Macros.
+
+=item *
+
+Added some remarks here and there, and fixed some style issues.
+
+=back
+
+
 0.1.2
 
 =over 4
@@ -1295,7 +1397,7 @@
 Removed C<.immediate>, it is C<:immediate>, and thus not a PIR directive, but a flag.
 This was a mistake.
 
-=item * 
+=

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

[chromatic]

Author: chromatic
Date: Fri Feb 23 12:45:02 2007
New Revision: 17164

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

Log:
[PDD] Added an NCI invocation example (Klaas-Jan Stol <[EMAIL PROTECTED]>).

Modified: trunk/docs/pdds/draft/pdd16_native_call.pod
==
--- trunk/docs/pdds/draft/pdd16_native_call.pod (original)
+++ trunk/docs/pdds/draft/pdd16_native_call.pod Fri Feb 23 12:45:02 2007
@@ -126,7 +126,47 @@
 =head2 Examples
 
 Most of the function parameters are reasonably self-evident. Some, however,
-merit additional explanation. The {{ ??? }}
+merit additional explanation.
+
+This section describes the simplest example for NCI possible. To every NCI
+invocation, there are two parts: the native function to be invoked, and the
+PIR code to do the invocation.
+
+First the native function, to be written in C.
+On Windows, it is necessary to do a DLL export specification of the NCI 
function:
+
+  /* foo.c */
+
+  /* specify the function prototype */
+
+   void foo(void);
+
+  /* or on Windows using Microsoft Visual Studio: */
+
+  __declspec(dllexport) void foo(void);
+
+  void foo(void) {
+printf("Hello Parrot!\n");
+  }
+
+Then, after having compiled the file as a shared library, the PIR code looks
+like this:
+
+  .sub main :main
+ .local pmc lib, func
+
+ # load the shared library
+ lib = loadlib "hello" # no extension, .so or .dll is assumed
+
+ # get a reference to the function from the library just
+ # loaded, called "foo", and signature "void" (and no arguments)
+ func = dlfunc lib, "foo", "v"
+
+ # invoke
+ func()
+
+  .end
+
 
 =head2 Callbacks
 
@@ -224,9 +264,9 @@
 Maintainer: Dan Sugalski
 Class: Internals
 PDD Number: 16
-Version: 1.1
+Version: 1.2
 Status: Developing
-Last Modified: Oct 12, 2004
+Last Modified: Feb 23, 2007
 PDD Format: 1
 Language: English
 
@@ -234,6 +274,10 @@
 
 =over 4
 
+=item version 1.2
+
+Updated with basic example.
+
 =item version 1.1
 
 Changed callback section to reflect current status.
@@ -248,6 +292,10 @@
 
 =over 4
 
+=item version 1.2
+
+Updated with basic example.
+
 =item version 1.1
 
 Changed callback section to reflect current status.

Re: [PATCH] PDD16 NCI update with simple example

[chromatic]

On Friday 23 February 2007 05:16, Klaas-Jan Stol wrote:

> As a result, I added a simple example to PDD16. I didnt' put too much
> work in it (there are many more places that could be improved), because
> I didn't know if updating this doc is desirable at this moment (any big
> changes pending?).

> If desired, I'd be happy to do more updates. Please let me know.
> At least there's full working code to do a simple NCI invocation.

Please do.  There are no big changes pending.

Thanks, applied as r17164.

-- c

Re: [PATCH] languages/PIR update pirgrammar.pod

[chromatic]

On Friday 23 February 2007 11:28, Klaas-Jan Stol wrote:

> attached an update for languages/PIR/docs/pirgrammar.pod
> The document languages/PIR/docs/pirgrammar.html should be removed from
> the repository -- don't know how to do this. Then later, we can
> generated it via the make file.

Patch applied and HTML file removed as of r17165.

-- c

[perl #41600] [BUG] PMC docs are missing from parrotcode.org

[via RT]

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


http://parrotcode.org/docs/pmc/ seems to be missing the documents from
src/pmc/*.pmc -- it lists only docs from docs/pmc/.

~jerry

Re: [perl #40626] [BUG] :vtable fails for subclasses of core classes

[jerry gay]

On 2/23/07, Klaas-Jan Stol via RT <[EMAIL PROTECTED]> wrote:

On Fri Feb 23 11:16:01 2007, particle wrote:
> this bug seems to be resolved as of r17163. however, i'm not closing
> this ticket until the example code in the original post is added as a
test.
> ~jerry

Attached a patch adding a test to t\pmc\objects.t using the original
example code of this bug, so the ticket can be closed.


thanks for the quick turnaround. this test is perfect for the
'executed from pir test case', and will be applied shortly. but as
patrick later provided an example of executing a .pbc file, we'll also
need a test for this before the ticket is closed.
~jerry

Re: [S09] "Whatever" indices and shaped arrays

[Larry Wall]

On Fri, Feb 23, 2007 at 10:49:34AM -0800, Jonathan Lang wrote:
: That said, I think I can do one better:
: 
: Ditch all of the above.  Instead, '*' always acts like a list of all
: valid indices when used in the context of postcircumfix:<[ ]>.

Ooh, shiny!  Or at least, shiny on the shiny side...

: If you want the last index, say '*[-1]' instead of '* - 1'.
: If you want the first index, say '*[0]' instead of '* + 0'.

So the generic version of leaving off both ends would be *[1]..*[-2]
(ignoring that we'd probably write *[0]^..^*[-1] for that instead).

: So the four corners of a two-dimensional array would be:
: 
:  @array[ *[0]; *[0] ];  @array[ *[-1]; *[0] ];
:  @array[ *[0]; *[-1] ]; @array[ *[-1]; *[-1] ];

A point against it visually is the nested use of [].

: The only thing lost here is that '@array[+*]' is unlikely to point
: just past the end of a shaped array.  But then, one of the points of
: shaped arrays is that if you point at an invalid index, you get a
: complaint; so I don't see why one would want to knowingly point to
: one.

I would expect that to point to one off the end in the first dimension only,
which might make sense if that dimension is extensible:

my @array[*;2;2];

Adding something at +* would then add another 2x2 under it.

: Also, has the syntax for accessing an array's shape been determined
: yet?  If not, I'd like to propose the following:
: 
: @array.shape returns a list of lists, with the top-level list's
: indices corresponding to the dimensions of the shape and each nested
: list containing every valid index in that dimension.  In boolean
: context, the shape method returns true if the array is shaped and
: false if not - though an unshaped array will otherwise pretend to be a
: one-dimensional, zero-based, non-sparse, shaped array.

That's more or less how I was thinking of it, though I hadn't got as
far as boolean context.

: So:
: 
:  @array.shape[0][2] # the third valid index of the first dimension of the 
:  shape
:  @array.shape[-1][0] # the first valid index of the last dimension of the 
:  shape
:  @array.shape[1] # every valid index of the second dimension of the shape
:  @array.shape[1][*] # same as @array.shape[1]
: 
:  [EMAIL PROTECTED] # is this a shaped array?
: 
:  exists @array.shape[2] # does the array have a third dimension?
:  exists @array.shape[3][4] # does the fourth dimension have a fifth element?
: 
:  [EMAIL PROTECTED] # how many dimensions does the shape have?
:  [EMAIL PROTECTED] # how many indices does the first dimension have?
: 
: If we use this notation, then
: 
:  @array[ *; * ]
: 
: is shorthand for
: 
:  @array[ @array.shape[0]; @array.shape[1] ]

Note also that multidimensional whatever gives us

@array[ ** ]

to mean

@array[ @@( @array.shape[*] ) ]

or some such.  Though ** might want to be even smarter than that if
we want

@array[ 0; **; 42]

to dwim.  That'd have to turn into something like:
 
@array[ 0; @@( @array.shape[*[1]..*[-2]] ); 42 ]

Also +** might return a shape vector, or maybe +«**.

Larry

Re: [S09] "Whatever" indices and shaped arrays

[Jonathan Lang]

Larry Wall wrote:

On Fri, Feb 23, 2007 at 10:49:34AM -0800, Jonathan Lang wrote:
: That said, I think I can do one better:
:
: Ditch all of the above.  Instead, '*' always acts like a list of all
: valid indices when used in the context of postcircumfix:<[ ]>.

Ooh, shiny!  Or at least, shiny on the shiny side...


Thank you...


: If you want the last index, say '*[-1]' instead of '* - 1'.
: If you want the first index, say '*[0]' instead of '* + 0'.

So the generic version of leaving off both ends would be *[1]..*[-2]
(ignoring that we'd probably write *[0]^..^*[-1] for that instead).


Correct - although that assumes that the indices are consecutive (as
opposed to, say, 1, 2, 4, 8, 16...); this version of * makes no such
assumption.

I do find myself wondering what *[-1] would be for an infinite array,
such as @nums[0..*:by(2)].

One possible answer: Inf.

Another possible answer: the shape sets limits on the indices; it does
not set requirements.  For instance:

 my @nums[0..*:by(2)];
 @nums[2 * $_] = $_ for 0..5];
 say @nums[ *[-1] ]; # same as 'say @nums[10];'
 @nums[42] = 21;
 say @nums[ *[-1] ]; # same as 'say @nums[42];'
 say @nums[ *[-2] ]; # same as 'say @nums[40];' - whatever that means.


: Also, has the syntax for accessing an array's shape been determined
: yet?  If not, I'd like to propose the following:
:
: @array.shape returns a list of lists, with the top-level list's
: indices corresponding to the dimensions of the shape and each nested
: list containing every valid index in that dimension.  In boolean
: context, the shape method returns true if the array is shaped and
: false if not - though an unshaped array will otherwise pretend to be a
: one-dimensional, zero-based, non-sparse, shaped array.

That's more or less how I was thinking of it, though I hadn't got as
far as boolean context.


I'm still debating the boolean context myself.  I _think_ it will
work; but I have a tendency to miss intricacies.  You might instead
want to require someone to explicitly check for definedness or
existence instead of merely truth; or you might not.


: If we use this notation, then
:
:  @array[ *; * ]
:
: is shorthand for
:
:  @array[ @array.shape[0]; @array.shape[1] ]

Note also that multidimensional whatever gives us

@array[ ** ]

to mean

@array[ @@( @array.shape[*] ) ]

or some such.


Like I said, I tend to miss intricacies.  For instance, I never
considered what would be involved in applying a subscriptor to a
multidimensional Whatever (e.g., what can you do with '**[...]'?).
Part of that is that I'm not yet comfortable with multidimensional
slices (or arrays, for that matter); when reading about them, I keep
on getting the feeling that there's something going on here that the
big boys know about that I don't - implicit assumptions, et al.


Though ** might want to be even smarter than that if
we want

@array[ 0; **; 42]

to dwim.  That'd have to turn into something like:

@array[ 0; @@( @array.shape[*[1]..*[-2]] ); 42 ]

Also +** might return a shape vector, or maybe +«**.


If by "shape vector" you mean something that says "the array has a
length of 5, a width of 3, and a height of 2", +«** would seem to be
the more appropriate syntax.  Why you'd want that inside an array's
subscriptor is beyond me, for a similar reason to +*.  But that's what
the logic of the syntax gives.

But I _could_ see using '[EMAIL PROTECTED]' to get an array's measurements.

Hmm...

 my @@square = (1, 2; 3, 4);
 say +@@square; # say what?  '2', as in 2 dimensions?  Or '4', as in 4 items?

Answer that, and you'll know what +** would give you.

--

BTW: could the parser handle the following?

 @array[ *[0] * 2; 2 ** **[ [;] 0 x *] ]

--
Jonathan "Dataweaver" Lang

[PATCH] Update DEPRECATED.pod

[Klaas-Jan Stol]

hi,

attached a patch updating DEPRECATED.pod.
it adds the deprecated ops from http://www.parrotcode.org/docs/ops/var.html

(ops: store_global and friends)

regards,
kjs
Index: DEPRECATED.pod
===
--- DEPRECATED.pod	(revision 17165)
+++ DEPRECATED.pod	(working copy)
@@ -29,6 +29,25 @@
 
 =back
 
+=head1 Deprecated ops
+
+From http://www.parrotcode.org/docs/ops/var.html, the following ops are 
+deprecated:
+
+=over 4
+
+=item store_global
+
+=item find_global
+
+=item find_name
+
+=back
+
+There are several variants of some of the above ops; all are deprecated,
+and are replaced by the ops {set,get}_[hll,root]_global. See also
+http://www.parrotcode.org/docs/ops/var.html.
+
 =head1 FUTURE changes
 
 Not yet deprecated, but it's recommended to use the new syntax and

[perl #41455] [NEW] and [PATCH]: tools/build/ops2pm.pl refactored

[James Keenan via RT]

Following discussion with particle on Feb 19 2007, these patches and new files 
were committed 
to trunk in r17061.  Ticket may be closed.

Re: [S09] "Whatever" indices and shaped arrays

[Luke Palmer]

On 2/23/07, Jonathan Lang <[EMAIL PROTECTED]> wrote:
'> I'm still debating the boolean context myself.  I _think_ it will

work; but I have a tendency to miss intricacies.  You might instead
want to require someone to explicitly check for definedness or
existence instead of merely truth; or you might not.


I should chime in something here.  It may not be practical for Perl,
given how much we have already relied on its opposite, but it is still
worth considering:

I have been extremely satisfied with Ruby's boolean truth model:  nil
and false are false, everything else is true.  So the empty string is
true, 0 is true, "0" is certainly true.  I think it's the same reason
that I like Haskell's function call model: that is, function
application binds most tightly, everything else has various looser
precedence.

I think the nice thing about these two is their extreme simplicity.
In Haskell, when I read:

   foo x ! bar

I don't need to think for a fraction of a second to associate that
correctly in my mind.  Likewise, in Ruby, when I write:

   while line = gets

I don't need to think for a fraction of a second about edge cases of
gets.  Gets returns a string when it reads something, and nil on EOF,
that's all I need to know.  And the simplicity has a way of
propagating to other areas of the language, as in that example, where
gets is able to return the most obvious thing for EOF and have it work
correctly.

So, yeah, simple rules can be a blessing if you find the right ones.
In particular, since I use boolean context a lot (i.e. without
explicit compare operators), I'm a fan of as much boolean
predictability as I can get.  Even if we don't get the same simple
model of booleans as ruby, I'd like to keep the number of
boolean-context overloaded objects reasonably small.  This gives
functions the freedom to return false or undef as a failure mode, when
it is convenient for it to function that way.

Luke

[perl #41607] t/compilers/pge/p5regex/dummy.t failure

[via RT]

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


Tonight while running 'make test' I got errors in 1 test file.  Here  
is the output of 'prove -v t/compilers/pge/p5regex/dummy.t':

prove -v t/compilers/pge/p5regex/dummy.t t/doc/pod.t
t/compilers/pge/p5regex/dummyFAILED before any test output arrived

Opening up that file, I see that its entire content is:

#!/usr/bin/perl
# this is a dummy test file

Why do we have this in our distribution -- particularly if it causes  
the sole failure in 266 test files?

kid51

Re: [perl #41607] t/compilers/pge/p5regex/dummy.t failure

[jerry gay]

On 2/23/07, via RT James Keenan <[EMAIL PROTECTED]> wrote:

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


Tonight while running 'make test' I got errors in 1 test file.  Here
is the output of 'prove -v t/compilers/pge/p5regex/dummy.t':

prove -v t/compilers/pge/p5regex/dummy.t t/doc/pod.t
t/compilers/pge/p5regex/dummyFAILED before any test output arrived

Opening up that file, I see that its entire content is:

#!/usr/bin/perl
# this is a dummy test file

Why do we have this in our distribution -- particularly if it causes
the sole failure in 266 test files?


this test file is not in the repository. i don't have it in my working
copy, and svnweb says it's not there, either:
 http://svn.perl.org/parrot/trunk/t/compilers/pge/p5regex/

try 'svn st' and see if it shows up with a ? -- it's probably just in
your working copy. how it got there is beyond me.
~jerry