get_namespace Oddity

[chromatic]

Based on my reading of the documentation for get_namespace, this behavior 
isn't surprising, but based on what I want to do with the code, this behavior 
is very surprising:

works.pir:

.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
.end

breaks.pir:

.namespace [ 'Any'; 'Namespace'; 'Will'; 'Do' ]

.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
.end

The problem is that the test_more.pir snippet contains:

.local pmc exports, curr_namespace, test_namespace
curr_namespace = get_namespace
test_namespace = get_namespace [ 'Test'; 'More' ]

The final get_namespace call tries to find a namespace with that key *relative 
to the current namespace*.  That is, in the second example:

[ 'Any'; 'Namespace'; 'Will'; 'Do'; 'Test'; 'More' ]

... which isn't exactly what I want.

What's wrong, my expectation or the documentation/implementation?  (If my 
expectation is wrong, what's the point of get_namespace when it breaks with 
spooky action at a distance depending on if you just so happen to be in 
another namespace with it?)

-- c

Re: get_namespace Oddity

[Jonathan Worthington]

chromatic wrote:
Based on my reading of the documentation for get_namespace, this behavior 
isn't surprising, but based on what I want to do with the code, this behavior 
is very surprising:


works.pir:

.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
.end

breaks.pir:

.namespace [ 'Any'; 'Namespace'; 'Will'; 'Do' ]

.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
.end

The problem is that the test_more.pir snippet contains:

.local pmc exports, curr_namespace, test_namespace
curr_namespace = get_namespace
test_namespace = get_namespace [ 'Test'; 'More' ]

The final get_namespace call tries to find a namespace with that key *relative 
to the current namespace*.  That is, in the second example:

[ 'Any'; 'Namespace'; 'Will'; 'Do'; 'Test'; 'More' ]

... which isn't exactly what I want.

What's wrong, my expectation or the documentation/implementation?  (If my 
expectation is wrong, what's the point of get_namespace when it breaks with 
spooky action at a distance depending on if you just so happen to be in another 
namespace with it?)
  
The behavior looks sane to me. .include is, quite literally, textual 
inclusion, nothing more. The get_namespace instruction is always 
relative. The code should probably be using an absolute namespace op, 
such as get_hll_namespace (or get_root_namespace), which looks up from 
the appropriate root. I understood get_namespace as doing a relative 
lookup within the current namespace.


Jonathan

[perl #46519] [BUG] t/stm/runtime.t test failures

[Seneca Cunningham via RT]

I have just noticed that the trace I posted earlier is one the two
different crash logs that I have seen come out of this.  Once in a rare
while, this test doesn't crash, but instead prints two error messages;
the earlier trace is from the one message variant.  This next trace is
the no message, two thread version.

Process: parrot [85308]
Path:./parrot
Identifier:  parrot
Version: ??? (???)
Code Type:   PPC (Native)
Parent Process:  bash [82688]

Date/Time:   2008-04-05 12:23:06.365 -0400
OS Version:  Mac OS X 10.5.2 (9C31)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0044
Crashed Thread:  0

Thread 0 Crashed:
0   libparrot.dylib 0x008daa00
Parrot_NameSpace_set_pmc_keyed_str + 1344 (namespace.pmc:257)
1   libparrot.dylib 0x006e6c94 pt_ns_clone + 644
(thread.c:574)
2   libparrot.dylib 0x006e6bb0 pt_ns_clone + 416
(thread.c:562)
3   libparrot.dylib 0x006e6bb0 pt_ns_clone + 416
(thread.c:562)
4   libparrot.dylib 0x006e6d28 pt_clone_globals + 88
(thread.c:595)
5   libparrot.dylib 0x0083dc54 clone_interpreter + 1444
(parrotinterpreter.pmc:132)
6   libparrot.dylib 0x00840544 do_thread_run + 100
(parrotthread.pmc:65)
7   libparrot.dylib 0x00840658
do_thread_run_clone_default + 56 (parrotthread.pmc:82)
8   libparrot.dylib 0x006bf1e0 pcf_I_JOPxAT_ + 352
(nci.c:5586)
9   libparrot.dylib 0x008576c8 Parrot_NCI_invoke + 168
(nci.pmc:203)
10  libparrot.dylib 0x00619dc8 Parrot_callmethodcc_p_sc +
472 (object.ops:78)
11  libparrot.dylib 0x006dae80 runops_slow_core + 304
(runops_cores.c:219)
12  libparrot.dylib 0x006a24f0 runops_int + 672
(interpreter.c:916)
13  libparrot.dylib 0x006a31a8 runops + 360 
(inter_run.c:104)
14  libparrot.dylib 0x006a34c8 runops_args + 488
(inter_run.c:230)
15  libparrot.dylib 0x006a366c Parrot_runops_fromc_args +
108 (inter_run.c:299)
16  libparrot.dylib 0x00682e80 Parrot_runcode + 784
(embed.c:941)
17  libparrot.dylib 0x00944d24 imcc_run_pbc + 324
(main.c:794)
18  libparrot.dylib 0x009457b8 imcc_run + 872 (main.c:1082)
19  parrot  0x23f4 main + 148 (main.c:56)
20  parrot  0x2300 start + 64
21  ??? 0x0ffc 0 + 4092

Thread 1:
0   libparrot.dylib 0x0069025c Parrot_dod_trace_pmc_data
+ 156 (dod.c:480)
1   libparrot.dylib 0x00690084 Parrot_dod_trace_children
+ 484 (dod.c:436)
2   libparrot.dylib 0x0068fe78 trace_active_PMCs + 72
(dod.c:373)
3   libparrot.dylib 0x006910bc Parrot_dod_ms_run + 284
(dod.c:1130)
4   libparrot.dylib 0x006911ec Parrot_do_dod_run + 60
(dod.c:1179)
5   libparrot.dylib 0x006d942c run_thaw + 76
(pmc_freeze.c:1673)
6   libparrot.dylib 0x006d97c8 Parrot_thaw_constants + 40
(pmc_freeze.c:1828)
7   libparrot.dylib 0x006d00d4 clone_constant + 196
(packfile.c:2742)
8   libparrot.dylib 0x006d02f8 find_constants + 360
(packfile.c:2808)
9   libparrot.dylib 0x006cff80 Parrot_switch_to_cs + 256
(packfile.c:2705)
10  libparrot.dylib 0x008486e4 Parrot_Sub_invoke + 836
(sub.pmc:299)
11  libparrot.dylib 0x005fbf68 Parrot_invokecc_p + 136
(core.ops:432)
12  libparrot.dylib 0x006dae80 runops_slow_core + 304
(runops_cores.c:219)
13  libparrot.dylib 0x006a24f0 runops_int + 672
(interpreter.c:916)
14  libparrot.dylib 0x006a31a8 runops + 360 
(inter_run.c:104)
15  libparrot.dylib 0x006a34c8 runops_args + 488
(inter_run.c:230)
16  libparrot.dylib 0x006a366c Parrot_runops_fromc_args +
108 (inter_run.c:299)
17  libparrot.dylib 0x006e67cc thread_func + 380
(thread.c:472)
18  libSystem.B.dylib   0x96194b98 _pthread_start + 316

Thread 0 crashed with PPC Thread State 32:
  srr0: 0x008daa00  srr1: 0x0200f030   dar: 0x0044 dsisr: 0x4000
r0: 0xr1: 0xbfffee80r2: 0xr3: 0x023cf8c0
r4: 0x023cf9c0r5: 0xr6: 0x023cf9c0r7: 0x0049
r8: 0x0049r9: 0x023cf8c0   r10: 0x00011054   r11: 0x009e7b34
   r12: 0x009059c0   r13: 0x   r14: 0x   r15: 0x
   r16: 0x   r17: 0x   r18: 0x   r19: 0x
   r20: 0x   r21: 0x   r22: 0x   r23: 0x
   r24: 0x   r25: 0x   r26: 0xb78c   r27: 0x000c
 

[perl #52510] [PATCH] global.c fails C++ build

[Senaka Fernando]

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


Index: src/global.c
===
--- src/global.c(revision 26800)
+++ src/global.c(working copy)
@@ -290,10 +290,10 @@
 PARROT_WARN_UNUSED_RESULT
 PARROT_CAN_RETURN_NULL
 PMC *
-Parrot_ns_get_name(PARROT_INTERP, ARGIN(PMC *namespace))
+Parrot_ns_get_name(PARROT_INTERP, ARGIN(PMC *_namespace))
 {
 PMC *names;
-Parrot_PCCINVOKE(interp, namespace,
+Parrot_PCCINVOKE(interp, _namespace,
 CONST_STRING(interp, "get_name"), "->P", &names);
 return names;
 }
global.c fails C++ build due to the use of C++ keyword, 'namespace' as a
variable name. Patch attached.

Regards,
Senaka

[perl #52506] [PATCH] Refactor ops2c

[Mark Glines via RT]

Additional testing note.  If you try out this patch, you will need to
remove src/ops/*.c before doing a "make".  Otherwise ops2c won't be
re-run, and you won't actually be testing the patch.

Extra points for anyone who tests it on something other than gcc. :)

Mark

[perl #52506] [PATCH] Refactor ops2c

[via RT]

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


Sekana Fernando reported that src/ops/core_ops.c didn't compile under
g++.  It reports an error about "static op_lib_t core_op_lib" being
declared twice, and rightly so, because it is.  There's an initial stub
declaration, and another declaration at the end of the file with an
initializer block.

It seems appropriate to change the order of things output by ops2c, to
avoid the redundant declaration.  So I did so.  Patch attached.

The ops2c libraries are full of values calculated halfway through the
printing process, within functions named like "print_foo".  And other
"print_bar" functions rely on the values calculated by "print_foo",
which makes it difficult to move around sections of output.  Whenever
I found a value calculated within a print_* function, I just moved it
to the end of new(), instead.  A little MVC goes a long way, I think.

This gets g++ to get past core_ops.c, and on to the next error.  It
passes tests on x86-64 linux, and on ppc darwin.  But I'm hoping for a
little more QA and review, before I check in changes to code this vital.

Mark
Index: lib/Parrot/Ops2c/Utils.pm
===
--- lib/Parrot/Ops2c/Utils.pm   (revision 26793)
+++ lib/Parrot/Ops2c/Utils.pm   (working copy)
@@ -203,6 +203,24 @@
 $argsref->{flag} = $flagref;
 my $self = bless $argsref, $class;
 $self->_iterate_over_ops();
+
+my ( $op_info, $op_func, $getop );
+$op_info = $op_func = 'NULL';
+$getop = '( int (*)(const char *, int) )NULL';
+
+if ($self->{suffix} eq '') {
+$op_func = $self->{bs} . "op_func_table";
+$op_info = $self->{bs} . "op_info_table";
+if (!$self->{flag}->{dynamic}) {
+$getop = 'get_op';
+}
+}
+$self->{getop}   = $getop;
+$self->{op_info} = $op_info;
+$self->{op_func} = $op_func;
+
+$self->{names} = {};
+
 return $self;
 }
 
@@ -439,6 +457,12 @@
 
 $self->_print_preamble_source($SOURCE);
 
+$self->_op_info_table($SOURCE);
+
+$self->_op_func_table($SOURCE);
+
+$self->_print_op_lib_descriptor($SOURCE);
+
 $self->_print_ops_addr_decl($SOURCE);
 
 $self->_print_run_core_func_decl_source($SOURCE);
@@ -460,8 +484,9 @@
 #include "$self->{include}"
 
 $self->{defines}
-static op_lib_t $self->{bs}op_lib;
 
+static int get_op(const char * name, int full);
+
 END_C
 
 my $text = $self->{ops}->preamble( $self->{trans} );
@@ -657,21 +682,11 @@
 
 sub print_c_source_bottom {
 my ( $self, $SOURCE ) = @_;
-my @op_func_table = @{ $self->{op_func_table} };
-my $bs= $self->{bs};
-my $index = $self->{index};
 
 $SOURCE = $self->_reset_line_number($SOURCE);
 
-$self->_op_func_table($SOURCE);
-
-$self->{names} = {};
-$self->_op_info_table($SOURCE);
-
 $self->_op_lookup($SOURCE);
 
-$self->_print_op_lib_descriptor($SOURCE);
-
 $self->_generate_init_func($SOURCE);
 
 $self->_print_dynamic_lib_load($SOURCE);
@@ -706,12 +721,7 @@
 sub _op_func_table {
 my ( $self, $fh ) = @_;
 
-my ( $op_info, $op_func, $getop );
-$op_info = $op_func = 'NULL';
-$getop = '( int (*)(const char *, int) )NULL';
-
 if ( $self->{suffix} eq '' ) {
-$op_func = $self->{bs} . q{op_func_table};
 print $fh <{bs}numops$self->{suffix} = $self->{num_ops};
@@ -720,7 +730,7 @@
 ** Op Function Table:
 */
 
-static op_func$self->{suffix}_t ${op_func}\[$self->{num_entries}] = {
+static op_func$self->{suffix}_t $self->{op_func}\[$self->{num_entries}] = {
 END_C
 
 print $fh @{ $self->{op_func_table} };
@@ -732,9 +742,6 @@
 
 END_C
 }
-$self->{op_info} = $op_info;
-$self->{op_func} = $op_func;
-$self->{getop}   = $getop;
 }
 
 sub _op_info_table {
@@ -749,7 +756,6 @@
 );
 
 if ( $self->{suffix} eq '' ) {
-$self->{op_info} = "$self->{bs}op_info_table";
 
 #
 # Op Info Table:
@@ -826,7 +832,6 @@
 my ( $self, $fh ) = @_;
 
 if ( $self->{suffix} eq '' && !$self->{flag}->{dynamic} ) {
-$self->{getop} = 'get_op';
 my $hash_size = 3041;
 my $tot   = $self->{index} + scalar keys( %{ $self->{names} } );
 if ( $hash_size < $tot * 1.2 ) {
@@ -878,8 +883,6 @@
  * returns >= 0 (found idx into info_table), -1 if not
  */
 
-static int get_op(const char * name, int full);
-
 static size_t hash_str(const char * str) {
 size_t key = 0;
 const char * s;

[perl #51980] [PATCH] fixed multiple redefines of snprintf macro

[Mark Glines via RT]

On Fri Mar 21 09:03:08 2008, [EMAIL PROTECTED] wrote:
> there is a definition on my system for PARROT_HAS_SNPRINTF, but not a
> definition for PARROT_HAS_C99_SNPRINTF. I assume, on first glance that
> these two macros are one in the same and should be united.

They are not.  Please see the code in config/auto/snprintf/test.in -
this is a C program built and run by Configure.pl, to determine which
flavor of snprintf exists on a platform.  The semantics of the return
value differ.  So I don't think we should unite those two definitions.

Were there some warnings you were trying to fix?  If so, what were the
warnings?  We can try to find another way to fix them; please reopen the
ticket if this is the case.

Mark

[perl #52506] [PATCH] Refactor ops2c

[James Keenan via RT]

Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system.  You can follow developments there with:

svn co https://svn.perl.org/parrot/branches/ops2c

In that branch, I have applied Infinoid's patch to
lib/Parrot/Ops2c/Utils.pm.  On Debian Linux, I have configured, built
and tested through 'make test' and everything is passing.

So, so far, everything is cool.  More to come.

kid51

[perl #52528] [PATCH]: t/configure/036-config_steps.t: require_ok modules rather than files

[via RT]

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


Since the Parrot buildfest we held at the March 27 Toronto Perlmongers
meeting, Seneca Cunningham has pointed out a number of problems which
occur when you try to configure and build Parrot on Darwin in various
ways.  In RT 52214, for example, she pointed out that you can get
adverse results in certain circumstances when you try to build with the
Apple-supplied version of Perl 5.8 rather than a Perl you have built
yourself from source.

Inspired by that, I decided to try Parrot with the Apple-supplied Perl
5.8.6 and the corresponding version of 'prove' (v1.04, using
Test::Harness v2.42 and Perl v5.8.6).  I encountered two problems in the
pre-configuration tests, one of which I will discuss in this ticket.

Calling '/usr/bin/prove t/configure/036-config_steps.t', almost all the
tests fail with output like this:

t/configure/036-config_stepsWarning: Use of "require" without parentheses 
is ambiguous at (eval 4) line 2.
Bareword found where operator expected at (eval 4) line 2, near "/auto/aio"
(Missing operator before aio?)
# Failed test (t/configure/036-config_steps.t at line 41)
# Tried to require 'config/auto/aio.pm'.
# Error:  syntax error at (eval 4) line 2, near "require config/auto/"
Warning: Use of "require" without parentheses is ambiguous at (eval 5) line 2.
Bareword found where operator expected at (eval 5) line 2, near 
"/auto/alignptrs"
(Missing operator before alignptrs?)
# Failed test (t/configure/036-config_steps.t at line 41)
# Tried to require 'config/auto/alignptrs.pm'.
# Error:  syntax error at (eval 5) line 2, near "require config/auto/"

This test file always passes when I use my own Perl 5 and the latest
version of 'prove'.

The code failing in 036-config_steps.t is this:

foreach my $step (@steps) {
require_ok($step);
}

 where each $step element in @steps has the form 'config/*/*.pm' or
'config/*/*/*.pm'.

The juxtaposition of 'require' and 'bareword' in the error message
called to mind certain parts of 'perldoc -f require':

Test::More::require_ok() does not get much attention in that module's
documentation.  It seems as if it *should* work exactly the same way if
you call:

require_ok($file)
# where $file is 'config/init/defaults.pm' (currently used in 036)

... or:

require_ok($module)
# where $module is 'init::defaults' and 'config/' has been placed in @INC

... but, for reasons I don't understand, it doesn't in this case.

I figured I would rewrite 036-config_steps.t so that a module was being
required rather than a file.  With this modification, the test again
passes with the Apple-supplied Perl 5.8.6 and the associated 'prove'.  I
have tested this with a vendor-supplied Perl 5 and 'prove' on Debian
Linux as well, and it Does No Harm.

Please review and test out on various OSes with both vendor-supplied
Perl and 'prove' and any user-built or installed Perl or 'prove'.

Thank you very much.
kid51



Index: t/configure/036-config_steps.t
===
--- t/configure/036-config_steps.t  (revision 26795)
+++ t/configure/036-config_steps.t  (working copy)
@@ -25,7 +25,13 @@
 =cut
 
 my @steps;
-sub wanted { /^.*\.pm\z/s && push @steps, $File::Find::name; }
+sub wanted { $File::Find::name =~ m{^config\/(.*)\.pm\z}s &&
+do {
+my $mod = $1;
+my $class = join '::', ( split /\//, $mod );
+push @steps, $class;
+};
+}
 find( { wanted => \&wanted }, 'config' );
 
 if ( $^O !~ /win32/i ) {
@@ -33,10 +39,9 @@
 }
 
 my $testcount = @steps + 2;
+plan tests => $testcount;
+unshift @INC, 'config';
 
-# my $testcount = @steps;
-
-plan tests => $testcount;
 foreach my $step (@steps) {
 require_ok($step);
 }

[perl #52506] [PATCH] Refactor ops2c

[James Keenan via RT]

Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system.  You can follow developments there with:

svn co https://svn.perl.org/parrot/branches/ops2c

In that branch, I have applied Infinoid's patch to
lib/Parrot/Ops2c/Utils.pm.  On Debian Linux, I have configured, built
and tested through 'make test' and everything is passing.

So, so far, everything is cool.  More to come.

kid51

Re: [perl #50424] [PROPOSAL][PCT] allow empty PAST::Stmts nodes

[Patrick R. Michaud]

On Thu, Jan 31, 2008 at 03:05:17AM -0800, Klaas-Jan Stol wrote:
> # New Ticket Created by  Klaas-Jan Stol 
> # Please include the string:  [perl #50424]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=50424 >
> 
> as far as I could see, it is not allowed to create empty PAST::Stmts nodes.
> (I might have done something else wrong, but I could not find any other
> reason).
> 
> If such a node is left empty, then incorrect PIR is generated:
> 
> "set $P, "
> 
> Note the missing second operand.

Actually, the problem isn't with the empty PAST::Stmts node but
rather with the parent node (e.g., an 'if' PAST::Op node) wanting
a result value from the PAST::Stmts node and getting an empty
string.

I can see two solutions:
(1) make the parent nodes such as PAST::Op 'if' a little smarter 
so that they know what to do when the child node doesn't have
a result value
(2) when an empty PAST::Stmts node is requested to provide a return
value, have it generate a null PMC as the result

#1 will provide slightly more optimal code, because we won't be
generating null values that ultimately don't get used.  #2 will
cause things to "always work" as far as the PIR is concerned, but make 
it harder to produce the optimal code that #1 can generate.

Pm

Re: postfix and postcircumfix

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

I only mean that you can't simply rewrite

$foo.($bar)

as

$foo.postcircumfix:<( )>.($bar)

and think you've gotten anywhere, since you'd then have to rewrite it
again:

$foo.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
$foo.postcircumfix:<( )>.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
...

Something has to recognize it as a special form.

  
You lost me.  Why does it apply operator(), er, postcircumfix:<( )> 
multiple times on successive return results?




Well, it's possible the subscript itself isn't the magical part there.
At minimum, the semilist rule probably needs to recognize @@ and ** at the
top level (or @@ and ** need to recognize that they're at the top
level of a context that wants them to interpolate multiple dimensions
rather than just one).

It's also possible that even this amount of syntactic magic is evil,
but I'd like [1;**;3] to know it has an arbitrary number of dimensions,
while [1;$two;3] should know that it has exactly three dimensions even
if $two happens to contain ** or @@.
  
Your previous description of handing * in array subscripting explained 
that it was done at run-time.  From that earlier discussion, nothing in 
the parsing of the text between the brackets interacts with the declared 
properties of the array.


So, in slice context 1;$two;3 will contain 3 lists.  Even without slice 
context, a scalar variable like $two never interpolates but adds a 
single value to the list (so it is writ).  So when postcircumfix:<[ ]> 
looks at its argument at runtime, it would see [ [1], [**], [3] ], 
assuming I'm writing that correctly.  What $two happens to contain 
should not matter, or you've lot a lot more revising to do.



It's also possible I'm just nuts, and slice context should be a purely
run-time activity.

  
That doesn't mean that the standard postcircumfix<[ ]> should be defined 
to handle what it sees as ** inside one of its arguments.  Perhaps it 
should use the cardinality of its argument (a list of lists) as an 
indication of what it should do, and then if it finds something in one 
of those sublists that is not a list of indexes, it is an error.


That means if you wanted to compose the number of dimensions at 
run-time, you would have to explicitly use a construct that did the 
proper amount of flattening, e.g. [1; @@ $two; 3].


--John

Re: postfix and postcircumfix

[Brandon S. Allbery KF8NH]

On Apr 6, 2008, at 12:07 , John M. Dlugosz wrote:

Larry Wall larry-at-wall.org |Perl 6| wrote:

and think you've gotten anywhere, since you'd then have to rewrite it
again:

$foo.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
$foo.postcircumfix:<( )>.postcircumfix:<( )>.postcircumfix:<( ) 
>.($bar)

...

Something has to recognize it as a special form.
You lost me.  Why does it apply operator(), er, postcircumfix:<( )>  
multiple times on successive return results?


You've rewritten a method call... into a method call.  Point being  
that treating postcircumfix tokens as method calls doesn't work when  
the postcircumfix token *indicates* a method call; that has to be  
primitive.  Put another way, method call syntax is postcircumfix for  
lexing/syntax, but extending that to semantic analysis won't work.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH

Re: Comparison of Harmony GC_Gen vs. Parrot

[Senaka Fernando]

Hi all,

I have almost finished comparing the two interfaces of Harmony and Parrot.
However, I'm not 100% sure on whether I got everything right, but I believe
that most of it is. Therefore, it would be really great if you could review
the wiki page and let me know whether it is correct and precise.

Sections marked as TBD are not yet finalized. And, I have omitted some
instances of where Harmony supports something and Parrot doesn't for
simplicity.

The wiki page is found at [1]

[1] http://wiki.apache.org/harmony/gc_comparison/gc_gen_harmony_vs_parrot

Regards,
Senaka

Re: get_namespace Oddity

[chromatic]

On Sunday 06 April 2008 09:33:06 chromatic wrote:

> On Sunday 06 April 2008 02:17:07 Jonathan Worthington wrote:

> > The behavior looks sane to me. .include is, quite literally, textual
> > inclusion, nothing more. The get_namespace instruction is always
> > relative. The code should probably be using an absolute namespace op,
> > such as get_hll_namespace (or get_root_namespace), which looks up from
> > the appropriate root. I understood get_namespace as doing a relative
> > lookup within the current namespace.

> That's what the documentation suggests as well, but I have difficulty
> imagining code where I'd *want* the existing behavior of get_namespace.

... compounded by the fact that I can't seem to get any of the existing 
namespace ops to do what I want in a concise, non-hacky way.  What am I 
missing?

.namespace [ 'Foo' ]

.sub 'main' :main
load_bytecode 'runtime/parrot/library/Test/More.pbc'

# get the testing functions
.local pmc exports, curr_namespace, test_namespace
curr_namespace = get_namespace
test_namespace = get_root_namespace [ 'Test'; 'More' ]
exports = split " ", "plan diag ok is is_deeply like isa_ok 
skip"

$I0 = defined test_namespace
say $I0
test_namespace."export_to"(curr_namespace, exports)
.end

-- c

Comparison of Harmony GC_Gen vs. Parrot

[Senaka Fernando]

Hi all,

I have almost finished comparing the two interfaces of Harmony and Parrot.
However, I'm not 100% sure on whether I got everything right, but I believe
that most of it is. Therefore, it would be really great if you could review
the wiki page and let me know whether it is correct and precise.

Sections marked as TBD are not yet finalized. And, I have omitted some
instances of where Harmony supports something and Parrot doesn't for
simplicity.

Regards,
Senaka

Re: [perl #52506] [PATCH] Refactor ops2c

[chromatic]

On Saturday 05 April 2008 20:29:45 Mark Glines wrote:

> Sekana Fernando reported that src/ops/core_ops.c didn't compile under
> g++.  It reports an error about "static op_lib_t core_op_lib" being
> declared twice, and rightly so, because it is.  There's an initial stub
> declaration, and another declaration at the end of the file with an
> initializer block.
>
> It seems appropriate to change the order of things output by ops2c, to
> avoid the redundant declaration.  So I did so.  Patch attached.

+1 here

-- c

Re: get_namespace Oddity

[chromatic]

On Sunday 06 April 2008 02:17:07 Jonathan Worthington wrote:

> The behavior looks sane to me. .include is, quite literally, textual
> inclusion, nothing more. The get_namespace instruction is always
> relative. The code should probably be using an absolute namespace op,
> such as get_hll_namespace (or get_root_namespace), which looks up from
> the appropriate root. I understood get_namespace as doing a relative
> lookup within the current namespace.

That's what the documentation suggests as well, but I have difficulty 
imagining code where I'd *want* the existing behavior of get_namespace.

-- c

Re: get_namespace Oddity

[Bob Rogers]

   From: chromatic <[EMAIL PROTECTED]>
   Date: Sun, 6 Apr 2008 09:52:34 -0700

   ... compounded by the fact that I can't seem to get any of the existing 
   namespace ops to do what I want in a concise, non-hacky way.  What am I 
   missing?

I notice that changing "get_root_namespace" to "get_hll_namespace" makes
the code you posted work.  That seems completely backwards, though, so I
can't say that I understand it either . . .

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: get_namespace Oddity

[Bob Rogers]

   From: Bob Rogers <[EMAIL PROTECTED]>
   Date: Sun, 6 Apr 2008 13:25:33 -0400

  From: chromatic <[EMAIL PROTECTED]>
  Date: Sun, 6 Apr 2008 09:52:34 -0700

  ... compounded by the fact that I can't seem to get any of the existing 
  namespace ops to do what I want in a concise, non-hacky way.  What am I 
  missing?

   I notice that changing "get_root_namespace" to "get_hll_namespace" makes
   the code you posted work.  That seems completely backwards, though, so I
   can't say that I understand it either . . .

Aha!  It's because they're both in the default "HLL", the namespace for
which is called "parrot".  So this also works:

test_namespace = get_root_namespace [ 'parrot'; 'Test'; 'More' ]

Not sure if that's any more intuitive, though.

-- Bob

Re: get_namespace Oddity

[jerry gay]

On Sun, Apr 6, 2008 at 10:30 AM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>From: Bob Rogers <[EMAIL PROTECTED]>
>Date: Sun, 6 Apr 2008 13:25:33 -0400
>
>
>
>   From: chromatic <[EMAIL PROTECTED]>
>   Date: Sun, 6 Apr 2008 09:52:34 -0700
>
>   ... compounded by the fact that I can't seem to get any of the existing
>   namespace ops to do what I want in a concise, non-hacky way.  What am I
>   missing?
>
>I notice that changing "get_root_namespace" to "get_hll_namespace" makes
>the code you posted work.  That seems completely backwards, though, so I
>can't say that I understand it either . . .
>
>  Aha!  It's because they're both in the default "HLL", the namespace for
>  which is called "parrot".  So this also works:
>
> test_namespace = get_root_namespace [ 'parrot'; 'Test'; 'More' ]
>
>  Not sure if that's any more intuitive, though.
>
by default, everything you write in pir is in the [ 'parrot' ] hll
namespace. therefore,
get_root_namespace [ 'parrot', 'Foo' ]
is equivalent to
get_hll_namespace [ 'Foo' ]
unless there's been a previous HLL directive for the non-default hll.

clear as mud?
~jerry

[perl #39988] [DOCS] Stackless vtable calls to Parrot functions

[Bob Rogers]

   From: "James Keenan via RT" <[EMAIL PROTECTED]>
   Date: Sun, 16 Mar 2008 10:46:15 -0700

   On Sun Mar 16 10:02:32 2008, rgrjr wrote:

   > I think it ought to happen, though I think Allison just wanted a ticket
   > for updating existing PDDs, and not for a whole new PDD.  I asked
   > Allison for a clarification on 11-Mar in Will's "[oops; continuation
   > 0xb6926320 of type 22 is trying to jump from runloop 15008 to runloop
   > 1]" thread, and had been waiting for that.
   > 
   >But I do agree that it ought to be a separate ticket.  The underlying
   > issue is still with us, but has outgrown the original ticket.
   > 

   Okay.  I will now close this ticket.  For more granular tracking, I
   recommend that a separate RT be opened for each existing PDD which needs
   updating.

   Thank you very much.
   kid51

OK, I've finished the writeup for one or more new tickets; please advise
on whether this is on target, and how to file it.  My personal
recommendation is for a single design/documentation ticket, the
satisfaction of which will generate a number of implementation tickets.

   FWIW, the issue seems much less scary for having written it up.  It
probably also helps that I've let go of the notion that we can ever
remove all continuation barriers; it's a big job, and I still can't
think of a compelling use case for needing to do so.

-- Bob

   In between instructions, all Parrot control and data state is
captured in Parrot runtime data structures.  During the execution of an
instruction, some state may be kept temporarily in the C calling stack.
If the C code happens to enter an inferior runloop, e.g. to run a vtable
method, and that code creates a continuation, this continuation has no
way to capture the extra C program state for the partially-executed
instruction.  If such a continuation were used to resume the inferior
runloop after returning to the main one [1], the resumed PIR would
execute normally, but when it returned, the latter half of the partial
instruction would be skipped.  This is a relatively obscure case, but
would likely result in a serious failure if the partial instruction was
expected to set registers.

   Coroutines are similarly affected, though it seems strange to want to
yield or resume a coroutine from within a vtable method.  On the other
hand, a coroutine can be thought of as just an application of
continuations, so users have a right to expect this to work.

   The continuation barrier issue is separable into a handful of
subproblems, and could be addressed in stages.  The topic of this issue,
therefore, is to research and document the desired long-term solution to
the overall problem, in such PDDs as are appropriate, before starting
down the garden path.

   As a guideline, here is an outline of the subproblems:

   1.  Currently, it is not even possible to jump from the current
inferior runloop to another currently-executing runloop.  (The
destination runloop in this case belongs to an outer dynamic scope, so
this is equivalent to transfer of control to a still-active outer frame
in a stack-based implementation.)  This "outward continuation" case is
commonly encountered in error handling and control structure
implementations.  The current implementation just runs the new PIR code
in the current runloop (after printing a warning), which is almost
certainly the wrong thing.  In order to fix it, it is only necessary to
record a separate longjmp address for each runloop, storing it in a
place where Continuation:invoke can use it (after testing that it is
still valid!).  The original runloop (plus any intervening runloops)
would need to be marked as invalid, as their portion of the C stack is
being unwound.  Languages without continuations or coroutines would need
nothing more, so fixing at least this much would help in most cases.

   2.  Attempts to re-enter a non-existent runloop could be made to work
transparently for operations which have limited side effects and return
the same result when re-run.  For example, most get_integer or
store_pmc_indexed_int implementations should fit that description (but
obviously not push_pmc).  To do this, the code that sets up the inferior
runloop can create a return continuation that *restarts* the interrupted
instruction.  If the return continuation is invoked when its runloop
still exists, then that runloop exits normally; otherwise, we stay in
the same runloop and return to the instruction that got us into that
mess in the first place.

   3.  Bugs will then be reported for instructions that cannot be
restarted this way.  It may be possible to fix at least some of them by
reordering vtable method calls so that the ones that are expected to
have nontrivial side effects are done last.  In any case, such bugs
should be relatively rare.

   4.  That leaves a hard-core residue of cases that cannot be fixed
without rewriting to eliminate the inferior runloop.  At a minimum, this
requires a

Re: [perl #47289] [PATCH] Move executable code out of jit/i386/exec_dep.h

[Paul Cochrane]

On 01/04/2008, Mark Glines via RT <[EMAIL PROTECTED]> wrote:
> On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote:
> > I ran a fulltest with this patch applied, and everything's fine on x86
> > (where it matters).
>
> Hi,
>
> The root.in portion of this patch breaks non-i386, JIT capable
> platforms.  Problem is, the patch created an exec_dep.c for i386, but
> added a Makefile dependency for $(SRC_DIR)/exec_dep.c on *ALL*
> platforms, and that file doesn't exist anywhere except for x86.
>
> So, tetragon is now reporting on IRC that builds fail on ppc.  Sounds
> like reverting r26636 will result in a successful build... testing that now.

IIRC there's a special flag one can set inside Makefile.pm (I think...
:-/ ) which will allow this dependency to only be added for x86
platforms.  My guess is that this would be the appropriate way to get
this patch working on all platforms.

Paul

Re: [perl #43753] [TODO] $language should be the name of the test Module

[Paul Cochrane]

Hallo Bernhard,

On 06/04/2008, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> On Di. 10. Jul. 2007, 07:15:27, ptc wrote:
> > In the file lib/Parrot/Test.pm there is the todo item:
> >
> > # TODO: $language should be the name of the test Module
> > #   that would open the door for Scheme::Test
> >
> > This needs to be implemented.
>
> I think that no action needs to be taken on that, so I removed that idle
> comment.

That means we can close this ticket or?

Paul

What in lieu of the C opcode?

[Bob Rogers]

   I notice that C is deprecated in favor of "methods on the
ParrotIO object" (per RT #48589), but I can't figure out what.  Is this
because the new methods have not been implemented yet?  TIA,

-- Bob Rogers
   http://rgrjr.dyndns.org/

Fundraising follow-up

[Conrad Schneiker]

 Pleases direct follow-ups to just perl6-users. 

It’s been about a month and a half since the first time that I
brought up the topic of fundraising. So I want to find out what
the prospects are of decisively resolving the earmarked funding
issue within The Perl Foundation any time soon. 

Otherwise, I would like to take the initiative to set up a Parrot
Platform Foundation specifically to handle earmarked grants for
Rakudo, the Parrot VM, C6PAN, and any other Perl 6 projects of
interest, such as SMOP. (I want to avoid using Perl in the
Foundation's name, to avoid any confusion with TPF.)

I know that others have differing strong opinions and grand
visions on how they want things to be done. That fine. 

In the mean time, I want to pursue several more modest and
presently-available opportunities for supporting Perl 6
developers, which are presently falling through the cracks.

TIMTOWTDI.

You know what I want for Christmas. The clock is ticking.

Best regards,
Conrad Schneiker

www.AthenaLab.com

Official Perl 6 Wiki — http://www.perlfoundation.org/perl6 
Official Parrot Wiki — http://www.perlfoundation.org/parrot 

[perl #49910] "3e4" does not parse as 30000

[Patrick R. Michaud via RT]

On Fri Mar 07 23:08:14 2008, songmaster wrote:
> On Tue Feb 05 13:41:02 2008, [EMAIL PROTECTED] wrote:
> > The fix is straightforward, but this change should also be made in
> > STD.pm.  This fixes RT #49910.
> 
> This patch would make 3e-4 a valid integer literal, even though it's not
> an integer.  Now 300e-2 *is* a whole number, but I'm not sure it should
> be accepted as an integer literal.

STD.pm has since been updated to have the correct parsing -- the answer
is that an integer literal never has a dot or 'e'.

In r26812 I've just updated rakudo to match STD.pm, so this ticket can
be closed.

> This is part of the question of what distinguishes an integer from a
> floating point number; it can't just be the presence of a decimal point
> as the above examples show, but S02 isn't specific.  [...]
> Here are a few examples that need answers from the language lawyers:
>   .1Legal, or is a leading 0 required?
>   1e1   Integer or Float?
>   1e-1  Integer or Float?
>   10e-1 Integer or Float?
>   .1e1  If legal, Integer or Float?
>   1.e1  Legal?

Just for completeness:

   .1 Not a legal number (leading digit required)
   1e1Float
   1e-1   Float
   10e-1  Float
   .1e1   Not a legal number (leading digit required)
   1.e1   Not a legal number (digits required after dot)

Closing ticket, thanks!

Pm

[perl #52506] [PATCH] Refactor ops2c

[Mark Glines via RT]

On Sun Apr 06 07:39:09 2008, [EMAIL PROTECTED] wrote:
> Following discussion on #parrot with Infinoid, I created the 'ops2c'
> branch in our SVN repository to handle refactoring of this area of the
> build system.  You can follow developments there with:
> 
> svn co https://svn.perl.org/parrot/branches/ops2c
> 
> In that branch, I have applied Infinoid's patch to
> lib/Parrot/Ops2c/Utils.pm.  On Debian Linux, I have configured, built
> and tested through 'make test' and everything is passing.
> 
> So, so far, everything is cool.  More to come.

Ok.  The branch is now at r26827, and I feel like I've run out of
hammers to hit this code with.  Here's what I've done:

* Move all the filehandling/opening/closing/renaming nonsense into a new
function, print_c_source_file().  This complements print_c_header_file,
and removes all the weird filehandle juggling stuff.
* Update t/tools/ops2cutils/ accordingly.
* Reorganize the file so public methods are on top.
* Fix a few things in the POD.

I think a TODO list would help at this point.  Here are some
possibilities I can think of (but don't necessarily feel very strongly
about):

* Honestly, I'm not really sure print_c_source_top and
print_c_source_bottom need to be public methods any more.  In fact, they
could be merged into print_c_source_file entirely.  But separating the
filehandling from the printing is useful for testing... maybe they
should be merged into a print_c_source_contents, or some such.
* We ought to reduce the amount of boilerplate in t/tools/ops2cutils/. 
  I changed the API of 2 functions, and had to update 5 or 6 places in
the test suite.
* Speaking of the test suite, is execution between "Configure.pl" and
"make" really necessary?  Some of the errors I was getting seemed to
indicate it was generating temporary directories, so the documentation
in these tests might be misleading.
* So far I've been ignoring the private methods as much as possible. 
But they could probably use a once-over.
* Even though new() delegates a lot of the work to _iterate_over_ops, it
is still ginormous.  Maybe it should delegate more?  Its length is not
necessarily a bad thing, but it makes it harder for me to understand
what's going on.
* Should probably get someone to test it on win32/msvc.

Is there anything else that's been bugging people about this code?

Mark

Re: [perl #52506] [PATCH] Refactor ops2c

[ajr]

On Windows, make, make perl6, and make test all function in ops2c branch
with no more than the customary grumbling.



--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com

[svn:parrot-pdd] r26829 - in trunk/docs/pdds: . draft

[rgrjr]

Author: rgrjr
Date: Sun Apr  6 18:15:44 2008
New Revision: 26829

Modified:
   trunk/docs/pdds/draft/pdd06_pasm.pod
   trunk/docs/pdds/pdd03_calling_conventions.pod

Log:
* docs/pdds/draft/pdd06_pasm.pod:
   + Remove refs to old pad ops.
* docs/pdds/pdd03_calling_conventions.pod:
   + Remove unmatched ")".


Modified: trunk/docs/pdds/draft/pdd06_pasm.pod
==
--- trunk/docs/pdds/draft/pdd06_pasm.pod(original)
+++ trunk/docs/pdds/draft/pdd06_pasm.podSun Apr  6 18:15:44 2008
@@ -573,37 +573,12 @@
 
 =over 4
 
-=item new_pad ix
-
-=item new_pad Px, iy
-
-=item push_pad Px
-
-=item pop_pad
-
-=item pop_pad Px
-
-=item peek_pad Px
-
-Instructions for creating scratchpads and manipulating the lexical stack.
-
 =item store_lex sx, Py
 
-=item store_lex ix, sy, Pz
-
-=item store_lex ix, iy, Pz
-
 =item find_lex Px, sy
 
-=item find_lex Px, iy, sz
-
-=item find_lex Px, iy, iz
-
-Instructions for storing in, and retrieving from the scratchpad currently at
-the top of the lexical stack.  For each of these operations there is an
-equivalent form that uses keyed versions of the set instruction. The keyed
-variants require that a scratchpad be specified rather than implicitly
-operating on the scratchpad on the top of the stack.
+Instructions for storing in, and retrieving from, the scratchpad associated
+with the current context.
 
 =item find_global Px, sy, sz
 

Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod   (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod   Sun Apr  6 18:15:44 2008
@@ -54,7 +54,7 @@
 FAQ: Given Parrot's internal use of continuation-passing style ["CPS"], it
 would be possible to use one pair of opcodes for both call and return, since
 under CPS returns I calls.  And perhaps someday we will have only two
-opcodes.  But for now, certain efficiency hacks are easier with four opcodes.)
+opcodes.  But for now, certain efficiency hacks are easier with four opcodes.
 
 The common syntax of these opcodes is:
 

Re: [perl #51980] [PATCH] fixed multiple redefines of snprintf macro

[Mark Glines]

On Sun, 06 Apr 2008 17:50:27 -0700
"Andrew Whitworth via RT" <[EMAIL PROTECTED]> wrote:
> Just warnings about redefining the snprintf macro. It was defined in
> two different places, and it's definition was based on both of those
> two flags above. I was looking for a way to unify the definitions for
> snprintf, and I wanted to know if a unification could go further then
> that as well. 

Ok, thanks for the clarification.  How do you think we should fix it?

Mark

Re: Fundraising follow-up

[Richard Dice]

Conrad,

Regarding targeted, earmarked funding - I have investigated the legalities,
tax implications, etc. of what is involved.  The result of my investigation
is that it is do-able within the construct of TPF.

The other question is one of creation of a technical platform for
implementing this.  There is a discussion within TPF of how we might
accomplish this, or how it might otherwise be accomplished.  For instance,
one member of TPF pointed out that http://www.thepoint.com/ already exists
and could provide the necessary infrastructure.  So if the goal is (and only
is) to connect Perl 6 developers with funding collected from various sources
piggybacking off of this site could be the easiest way.

My concern and the concern of TPF is maximum and best possible support of
Perl, including Perl 6, given our resource limitations.  I try to direct my
time to what can be best accomplished in that context.  This particular
matter has received considerable attention, but so have other matters in the
past 6 weeks as well.

It seems to me that you too are energetic in your support of Perl 6 and have
capability in this regard.  If there is a project that you think you can
devote attention to in such a way that the likelihood of success is
maximized while not incurring the trouble of having anyone else on the
critical path of the project plan then I would not want you to feel
encumbered by TPF or anyone else.  I think the main thing that TPF can offer
is a legal structure:  we have experience in meeting world-wide tax code
requirements (as various countries will look upon grants of this kind as
being income), and we have experience dealing with Things Going Wrong,
including legal council identified and retained, insurance policies, limited
liability of directors of the corporation, and similar.  These things are
important in Real Life and they are difficult and costly to replicate.

Something I would ask you to consider is that 1.5 months _is not_ a lot of
time, _especially_ for a volunteer organization.  If that isn't going to
work for you then I understand;  there's a lot to be said for individual
JDFI, which can be very efficient.  But it doesn't scale into certain
realms.  Maybe this is one of those realms, maybe it isn't.

The plan currently under discussion within TPF is the one written up by
Richard Hainsworth on March 11, with body beginning "Richard Dice covered
some crucial questions below."  I will email Karen Pauley, the new TPF
Steering Committee chair, with your email address.  If this matches the kind
of program you are interested in then maybe you could be the "implementation
volunteer" on the TPF version of the project?

Cheers,
 - Richard

On Sun, Apr 6, 2008 at 8:25 PM, Conrad Schneiker <[EMAIL PROTECTED]>
wrote:

>  Pleases direct follow-ups to just perl6-users. 
>
> It's been about a month and a half since the first time that I
> brought up the topic of fundraising. So I want to find out what
> the prospects are of decisively resolving the earmarked funding
> issue within The Perl Foundation any time soon.
>
> Otherwise, I would like to take the initiative to set up a Parrot
> Platform Foundation specifically to handle earmarked grants for
> Rakudo, the Parrot VM, C6PAN, and any other Perl 6 projects of
> interest, such as SMOP. (I want to avoid using Perl in the
> Foundation's name, to avoid any confusion with TPF.)
>
> I know that others have differing strong opinions and grand
> visions on how they want things to be done. That fine.
>
> In the mean time, I want to pursue several more modest and
> presently-available opportunities for supporting Perl 6
> developers, which are presently falling through the cracks.
>
> TIMTOWTDI.
>
> You know what I want for Christmas. The clock is ticking.
>
> Best regards,
> Conrad Schneiker
>
> www.AthenaLab.com
>
> Official Perl 6 Wiki — http://www.perlfoundation.org/perl6
> Official Parrot Wiki — http://www.perlfoundation.org/parrot
>
>
>

[perl #52506] [PATCH] Refactor ops2c

[James Keenan via RT]

As per discussion on #parrot, the remaining TODO questions posed no
obstacle to merging the branch back into trunk.  So I did so in r26830.

Re: [perl #51980] [PATCH] fixed multiple redefines of snprintf macro

[Andrew Whitworth]

On Sun, Apr 6, 2008 at 9:20 PM, Mark Glines via RT
<[EMAIL PROTECTED]> wrote:

>  Ok, thanks for the clarification.  How do you think we should fix it?

The patch I submitted for this ticket earlier addresses the multiple
redefinitions issue without doing anything funny with the
PARROT_HAS_SNPRINTF macro and family. However, mine might not be the
best solution to it. As I understand it, the logic is:

1) If PARROT_HAS_SNPRINTF is defined, the system has a native snprintf
definition, and no new macro needs to be created.
2) If PARROT_HAS_C99_SNPRINTF is defined, define snprintf to use
Parrot_secret_snprintf instead. Originally, and this was not changed
in my patch, PARROT_HAS_C99_SNPRINTF and PARROT_HAS_SNPRINTF are both
defined, the C99 one takes precidence, and Parrot_secret_snprintf is
used instead of the native snprintf. This might be worth changing.
3) If _MSC_VER is defined, we use the MS-specific _snprintf function
instead. In this case, it is unlikely that we have a native snprintf
implementation, and it is also unlikely that we want to use
Parrot_secret_snprintf instead of _snprintf.

Actually, now that I think about it, let me go back and redo the patch
that I submitted to be more comprehensive. I'll post it as soon as I
have something that makes sense.

--Andrew Whitworth

Re: What in lieu of the C opcode?

[jerry gay]

On Sun, Apr 6, 2008 at 4:13 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>I notice that C is deprecated in favor of "methods on the
>  ParrotIO object" (per RT #48589), but I can't figure out what.  Is this
>  because the new methods have not been implemented yet?  TIA,
>
precisely. allison and i were talking about this today. i/o
implementation is due on 1 may, as per
http://www.perlfoundation.org/parrot_grant_from_nlnet. however, it
will likely be delivered late, as concurrency isn't yet complete and
mmd is next on allison's list.

i don't think there's anything blocking it's implementation other than
a short supply of tuits. if you find any, let me know.
~jerry

RE: Fundraising follow-up

[Conrad Schneiker]

Richard,

 

That's great news!

 

(The time to get an answer wasn't an issue per se, but whether and when any
answer at all might be forthcoming, especially given the previously
expressed concerns and doubts of others that a positive answer would likely
result. Under such conditions, it would be pointless to wait in the dark for
3, 6, 9, or whatever more months, instead of pursuing other options.)

 

For purposes of earmarked development grants, does TPF prefer and recommend
http://www.thepoint.com/ to channel earmarked donations to TPF? Or would it
be best to wait a little longer for more conclusive TPF discussions on this?

 

In this context, 2 specific cases of interest from past discussions are:

 

(1) Getting 10 $500 commitments to fund chromatic's proposed month of
intensive Parrot project work.

 

(2) Providing a means to arrange (some number of) monthly contributions to
fund ruoso's proposed work on SMOP's runtime.

 

Once the means to handle these 2 paradigm cases is in place, a lot of useful
work could be handled by replicating these cases with suitable substitutions
of numbers, people, and tasks.

 

I am certainly interested in helping with setting this up, if there's
something useful I can do.

 

(And of course, once this is set up, I am still interested in soliciting
donations along such lines.)

 

Best regards,

Conrad Schneiker

 

www.AthenaLab.com  

 

Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 

Official Parrot Wiki - http://www.perlfoundation.org/parrot 

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Dice
Sent: Sunday, April 06, 2008 6:29 PM
To: Conrad Schneiker
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Fundraising follow-up

 

Conrad,

Regarding targeted, earmarked funding - I have investigated the legalities,
tax implications, etc. of what is involved.  The result of my investigation
is that it is do-able within the construct of TPF.

The other question is one of creation of a technical platform for
implementing this.  There is a discussion within TPF of how we might
accomplish this, or how it might otherwise be accomplished.  For instance,
one member of TPF pointed out that http://www.thepoint.com/ already exists
and could provide the necessary infrastructure.  So if the goal is (and only
is) to connect Perl 6 developers with funding collected from various sources
piggybacking off of this site could be the easiest way.

My concern and the concern of TPF is maximum and best possible support of
Perl, including Perl 6, given our resource limitations.  I try to direct my
time to what can be best accomplished in that context.  This particular
matter has received considerable attention, but so have other matters in the
past 6 weeks as well.

It seems to me that you too are energetic in your support of Perl 6 and have
capability in this regard.  If there is a project that you think you can
devote attention to in such a way that the likelihood of success is
maximized while not incurring the trouble of having anyone else on the
critical path of the project plan then I would not want you to feel
encumbered by TPF or anyone else.  I think the main thing that TPF can offer
is a legal structure:  we have experience in meeting world-wide tax code
requirements (as various countries will look upon grants of this kind as
being income), and we have experience dealing with Things Going Wrong,
including legal council identified and retained, insurance policies, limited
liability of directors of the corporation, and similar.  These things are
important in Real Life and they are difficult and costly to replicate.  

Something I would ask you to consider is that 1.5 months _is not_ a lot of
time, _especially_ for a volunteer organization.  If that isn't going to
work for you then I understand;  there's a lot to be said for individual
JDFI, which can be very efficient.  But it doesn't scale into certain
realms.  Maybe this is one of those realms, maybe it isn't.

The plan currently under discussion within TPF is the one written up by
Richard Hainsworth on March 11, with body beginning "Richard Dice covered
some crucial questions below."  I will email Karen Pauley, the new TPF
Steering Committee chair, with your email address.  If this matches the kind
of program you are interested in then maybe you could be the "implementation
volunteer" on the TPF version of the project?

Cheers,
 - Richard

On Sun, Apr 6, 2008 at 8:25 PM, Conrad Schneiker
<[EMAIL PROTECTED]> wrote:

 Pleases direct follow-ups to just perl6-users. 

It's been about a month and a half since the first time that I
brought up the topic of fundraising. So I want to find out what
the prospects are of decisively resolving the earmarked funding
issue within The Perl Foundation any time soon.

Otherwise, I would like to take the initiative to set up a Parrot
Platform Foundation specifically to handle earmarked grants for
Rakudo, the Parrot VM, C6PA