Re: Pugs File-Util tests

[Moritz Lenz]

Mark A. Hershberger wrote:
> The recent perl6 brouhaha got me to try out pugs again.
> 
> After grabbing pugs from svn and running the smoke tests
> (http://xrl.us/bdipe), I noticed some ext/File-Util/t/03.dirs.t was
> failing and looked like it would be a relatively easy fix.
> 
> Diff attached.

... and applied as r19288 by Larry.

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

[perl #49310] Make perl6 support -c

[via RT]

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


Syntax checking of perl6 programs is crucial.

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[perl #49308] config/auto/alignptrs.pm fails if required alignment > 1

[via RT]

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


Here's the output of Configure.pl --verbose on a SPARC where the required 
alignment is 4.  The test correctly deduces that alignments of 64, 32, 16, 
8, and 4 all work, but apparently throws that information away when the 2 
and 1 byte alignment tests fail.

Determining your minimum pointer alignment...
gcc [ options omitted ] -I./include -c test.c
test.c:14: warning: no previous prototype for 'bletch'
test.c: In function 'main':
gcc  test.o  -o test  -lsocket -lnsl -ldl -lm -lpthread -lrt
./test 64
64 OK
./test 32
32 OK
./test 16
16 OK
./test 8
8 OK
./test 4
4 OK
./test 2
./test 1

step auto::alignptrs died during execution: Can't determine alignment!

 at Configure.pl line 349

-- 
Andy Dougherty  [EMAIL PROTECTED]

Zombie code?

[ajr]

While trying to understand Parrot::Vtables.pm, I came across what seems
to be some "zombie" code, possibly left after RT 48877.

1. Two references to src/pmc/null.pl, which does not appear to exist.
2. The method "vtbl_embed", which is used only in
parrot/tools/build/vtable_extend.pl That writes
include/parrot/extend_vtable.h and src/extend_vtable.c, neither of which
exist.
3. Some odd pod in the method around lines 368-372, which makes me think
the expression that spans 367-379 would behave rather oddly if the method
was ever used.

Have I overlooked something?




--

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

[perl #49238] [PATCH] pbc_to_exe compile failure on Win32 / MSVC9

[Cosimo Streppone via RT]

On Lun. 31 Dic. 2007 01:09:28, [EMAIL PROTECTED] wrote:
> On Sunday 30 December 2007 14:05:38 Cosimo Streppone wrote:
> 
> > I tried to follow chromatic's instructions to obtain a perl6 binary
> > but had some problems [...]
> 
> > 3) In the final generated "pbc_to_exe.c" and
> "languages\perl6\perl6.c"
> > there's something like:
> >
> >int8_t program code[] = { bla bla bla...
> >
> > int8_t seems undefined on my system (vista + msvc 2008 express), so
> I
> > brutally replaced it with "unsigned char" and it worked like a
> charm.

Thanks for the building process explanation.
After your changes (r24437) I still have problems building perl6.exe.
I'm trying to use `nmake perl6'. Two problems here:

1) The `int8_t' define doesn't work for me. Seems like `signed__int8' 
is also undefined.
2) There's a small typo in gen/makefiles/root.in

The attached diff corrects wfm, even if 1) is resolved
using `unsigned char', which is ignorant, I think.


win32_msvc_perl6_build.patch
Description: Binary data

Re: Sequential bias in S04 (and Perl6 in general)

[Moritz Lenz]

Dave Whipp wrote:
> I was reading Synopsis 4 with regards to multi core programming. It 
> seems to be infused with a bias towards non-parallel models of 
> computation. Concurrently appears to be an add-on feature -- whereas we 
> should have a mindset that explicit sequential constraints are the 
> add-on feature.

That sounds really like a bad idea for simple "just do it" scripts. Just
imagine explaining concurrency issue to a beginner who is not even
confident with variables and blocks...

> Two statements that are missing from S04 (feel free to change the names) 
> are C; and a form of C that tests/executes multiple 
> C clauses in arbitrary order (without needing the sequential 
> C statement).
> 
> 
>forall @a -> $x { ... }
> 
> runs the code block on each element of @a (no defined order). 

You can achieve that with the "hyper" list-op (see S02).
Also note that an optimizer is free to automatically add the "hyper"
list op if it can prove that the executed block has no side effects.

...
> Similarly, C, C, C, C, ... should all 
> accept this ":sequential" adverb to force them to iterate their lists 
> sequentially -- and should otherwise iterate in arbitrary/concurrent order.

Some of this can be written with hyper ops, just as the dot for method
calls has a "hyper dot" Object>>.method

> I'm not too concerned about the exact details: my point is that we 
> should be fully aware of the fact that perl6 will be released into a 
> multicore (some people use the term many-core for devices with hundreds 
> of cores) world, and that exploitation of these parallel resources 
> should be the default (easy) behavior. We shouldn't have a "concurrency" 
> synopsis (we don't -- but we do have Spec/concurrency.pod). Instead, we 
> should have "sequential.pod" that defines how to impose additional 
> sequential constraints (e.g. ":atomic", ":sequential") on top of the 
> those inferred from data dependencies.

I think that the concurrency synopsis is still useful for explicit
threading, STM and the like.

Also note that Perl 6 tries to preserver Perl's soul, and is not an
Erlang based language ;-)

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

Re: Sequential bias in S04 (and Perl6 in general)

[Darren Duncan]

At 5:22 PM -0800 1/2/08, Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It 
seems to be infused with a bias towards non-parallel models of 
computation. Concurrently appears to be an add-on feature -- whereas 
we should have a mindset that explicit sequential constraints are 
the add-on feature.


I agree with this idea in principle.

Most of the time when people are working with lists, the tasks being 
done aren't conceptually dependent on being executed in a certain 
order, even if for some (sequences/arrays) it is important to 
reassemble results in corresponding order to the inputs.  Needing 
things to seemingly execute in a certain order only really matters 
when I/O with extra-process entities like the user is involved, I 
think.  Or if the output of one iteration is an input for another, 
which is rare I think.  Realistically, the user will want to be lazy 
and will tend to default to shorter versions of things, so making all 
possible list handling tasks non-sequential by default is good 
huffman coding.


As an aside, one design decision I made in my Muldis D language (for 
relational DBMSs, whose spec is on CPAN) was to have a clear 
separation of concerns.  The language has both functional and 
procedural aspects, and each routine you define in the language is 
just one or the other.  A function is pure functional and has no 
side-effects (no monads even), and sees no globals, has no variables. 
Most code one would write would be functional, and so most code gets 
implicit autoparallelization.  Since there are no side effects here, 
it is implicitly safe.  A procedure is pure-ish procedural, and each 
statement in it executes (conceptually) in sequence following the 
previous one, it sees globals and has side effects.  Bridging the 2 
is a multi-update operator; it is like an assignment statement 
targeting N procedure vars; procedures only invoke functions by way 
of update operators, as functions are the arguments of the latter, 
functions don't invoke non-functions.


Now, I realize that for Perl 6 to adopt such an approach as this may 
be undesirable to the majority, since afaik Perl 6 wants every kind 
of routine to be able to have side-effects, as per Perl 5 and many 
other languages, so to maximize the TIMTOADY factor.


But if it *were* possible in Perl 6 to mark routines, or have routine 
kinds, that are forbidden from side-effects, which extends to 
anything they invoke, then this is also a huffman-efficient and easy 
to use way to auto-parallelize.


Maybe either have a new routine declaration keyword, or maybe a :pure 
trait?  Or conversely have that be the default and have an :impure 
trait on the others.  Where those things aren't just implied by other 
things.  Note that supporting this wouldn't change the language much 
per se, but essentially be a flag to the compiler to be more strict 
about some things within the scope of the routine declaration, and 
therefore be more confident that it is safe to use some optimizations.


-- Darren Duncan

[perl #49314] [PATCH] pbc_to_exe should list libraries last

[via RT]

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


In order to get pbc_to_exe to work with the Solaris linker, I had to move 
the libraries to the end of the link line.  That's not surprising -- 
traditional Unix linkers process items in the link line in order.  At the 
point where libparrot.a is mentioned, no parrot objects have been listed 
on the command line yet, so libparrot isn't needed at all.  
This patch re-orders the command line to mention parrot_config.o first 
before mentioning libparrot.  (I also put the LINKFLAGS before the 
libraries, in case some of them were needed to help actually locate the 
libraries.)

--- parrot-current/config/gen/makefiles/root.in Wed Jan  2 08:59:40 2008
+++ parrot-andy/config/gen/makefiles/root.inWed Jan  2 13:13:12 2008
@@ -767,8 +767,8 @@
 pbc_to_exe.pir : $(PARROT) tools/dev/pbc_to_exe_gen.pl
$(PERL) tools/dev/pbc_to_exe_gen.pl \
 "$(BUILD_DIR)/CFLAGS $(CC) \"\" $(CFLAGS) -I$(BUILD_DIR)/include \
-@rpath_blib@ $(ALL_PARROT_LIBS) $(LINKFLAGS) \
-$(BUILD_DIR)/src/parrot_config$(O)" \
+$(BUILD_DIR)/src/parrot_config$(O) \
+$(LINKFLAGS) @rpath_blib@ $(ALL_PARROT_LIBS)" \
 > pbc_to_exe.pir
 
 pbc_to_exe : pbc_to_exe.pir

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[ajr]

>
> A quick cage cleaner task. Create a script to generate the file
> ports/debian/parrot-doc.docs

I've attached a quickie shell script, in case that's what you want. It's a
naive little thing, but I think you'll be amused by its presumption.

A properly formatted and tested Perl script will take a little longer.


--

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

debian_docs
Description: Binary data

[perl #49316] [PATCH] Fix 45 test failures with a 1-line patch!

[via RT]

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


Although include/parrot/dynext.h says that the third argument of 
Parrot_init_lib is nonnull, that's actually not correct.  A number of 
places (45 in the test suite) actually do pass in a null value, and 
Parrot_init_lib is designed to handle that case.

However, with the attribute_nonnull, gcc's optimizer optimizes away the
code in Parrot_init_lib to handle the null value!  The result is a nice 
core dump.

This patch fixes it by removing the nonnull attribute.

diff -ru parrot-current/include/parrot/dynext.h 
parrot-andy/include/parrot/dynext.h
--- parrot-current/include/parrot/dynext.h  Wed Jan  2 08:59:39 2008
+++ parrot-andy/include/parrot/dynext.h Wed Jan  2 14:23:13 2008
@@ -34,8 +34,7 @@
 ARGIN(void (*init_func)(PARROT_INTERP,
 ARGIN_NULLOK(PMC *
 __attribute__nonnull__(1)
-__attribute__nonnull__(2)
-__attribute__nonnull__(3);
+__attribute__nonnull__(2);
 
 PARROT_API
 PARROT_WARN_UNUSED_RESULT

-- 
Andy Dougherty  [EMAIL PROTECTED]

[perl #49238] [PATCH] pbc_to_exe compile failure on Win32 / MSVC9

[Cosimo Streppone via RT]

On Mer. 02 Gen. 2008 05:40:32, cosimo wrote:
> On Lun. 31 Dic. 2007 01:09:28, [EMAIL PROTECTED] wrote:
> > On Sunday 30 December 2007 14:05:38 Cosimo Streppone wrote:
> > 
> > > I tried to follow chromatic's instructions to obtain a perl6 
binary
> > > but had some problems [...]
> > [...] 
> 
> Thanks for the building process explanation.
> After your changes (r24437) I still have problems building perl6.exe.

Works for me in r24440.

[perl #49328] [BUG] problem between PBC loading and garbage collection

[via RT]

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



I've isolated one problem between PBC loading and garbage collection.
(remember: on Lua, LuaFunction extends Sub, LuaClosure extends Closure)

$ cat outer.pir # a small script
.HLL 'Lua', 'lua_group'

.sub 'foo' :lex
 print "foo\n"
.end

.sub 'bar' :lex :outer(foo) # closure
 print "bar\n"
.end

.sub '__start' :main
 print "__start\n"
 sweep 1
 bar()
 foo()
.end

$ parrot outer.pir  # With PIR, all is fine
 init LuaFunction 6ca8c8
 init LuaClosure 6ca8a8
 init LuaFunction 6ca888
__start
 mark LuaFunction 6ca888 __start
 mark LuaFunction 6ca8c8 foo
 mark LuaClosure 6ca8a8 bar
 outer: 6ca8c8 foo
bar
foo
 destroy LuaFunction 6ca888 __start
 destroy LuaClosure 6ca8a8 bar
 destroy LuaFunction 6ca8c8 foo

$ parrot -o outer.pbc outer.pir
...
$ parrot outer.pbc  # Now, the problem
 init LuaFunction 6ca568
 init LuaClosure 6ca4c8
 init LuaFunction 6ca4a8
 init LuaFunction 6ca408
__start
 mark LuaFunction 6ca408 __start
 mark LuaFunction 6ca568 foo
 mark LuaClosure 6ca4c8 bar
 outer: 6ca568 foo
 destroy LuaFunction 6ca4a8 foo
bar
foo
 destroy LuaFunction 6ca408 __start
 destroy LuaClosure 6ca4c8 bar
 destroy LuaFunction 6ca568 foo

During the PBC loading, 'foo' is created two times :
- first as the outer of LuaClosure 'bar' (6ca568)
- second as the LuaFunction 'foo' (6ca4a8)
During the mark stage, only one is marked (the outer one),
so the second is destroyed.

With the full implementation of Lua, this behavior causes a crash
when 'foo' is called because the call references the instance that
is really destroyed (and/or its memory is reused ?).

(without specific HLL, the behavior is same with Sub & Closure).

Francois.

NB: attached files :
- outer.pir
- a patch for Lua PMC instrumentation

.HLL 'Lua', 'lua_group'

.sub 'foo' :lex
print "foo\n"
.end

.sub 'bar' :lex :outer(foo)
print "bar\n"
.end

.sub '__start' :main
print "__start\n"
sweep 1
bar()
foo()
.end


Index: languages/lua/pmc/luaclosure.pmc

===

--- languages/lua/pmc/luaclosure.pmc	(revision 24441)

+++ languages/lua/pmc/luaclosure.pmc	(working copy)

@@ -36,6 +36,17 @@

 hll Lua
 maps Closure {
 
+void init() {
+PIO_eprintf(INTERP, "\tinit LuaClosure %p\n", SELF);
+SUPER();
+}
+
+void destroy() {
+const Parrot_sub * const sub = PMC_sub(SELF);
+PIO_eprintf(INTERP, "\tdestroy LuaClosure %p %s\n", SELF, Parrot_string_cstring(INTERP, sub->name));
+SUPER();
+}
+
 /*
 
 =item C
@@ -44,6 +55,7 @@

 
 */
 void init_pmc(PMC* sub) {
+PIO_eprintf(INTERP, "\tinit_pmc LuaCLosure %p\n", SELF);
 if (VTABLE_isa(INTERP, sub, const_string(INTERP, "Closure"))) {
 PMC_struct_val(SELF) = mem_allocate_typed(struct Parrot_sub);
 PMC_pmc_val(SELF)= PMCNULL;
@@ -68,6 +80,10 @@

 
 */
 void mark() {
+const Parrot_sub * const sub = PMC_sub(SELF);
+PMC *outer_sub = sub->outer_sub;
+PIO_eprintf(INTERP, "\tmark LuaClosure %p %s\n", SELF, Parrot_string_cstring(INTERP, sub->name));
+PIO_eprintf(INTERP, "\t\touter: %p %s\n", outer_sub, Parrot_string_cstring(INTERP, PMC_sub(sub->outer_sub)->name));
 SUPER();
 if (PMC_metadata(SELF))
 pobject_lives(INTERP, (PObj *)PMC_metadata(SELF));
Index: languages/lua/pmc/luafunction.pmc

===

--- languages/lua/pmc/luafunction.pmc	(revision 24441)

+++ languages/lua/pmc/luafunction.pmc	(working copy)

@@ -37,6 +37,17 @@

 hll Lua
 maps Sub {
 
+void init() {
+PIO_eprintf(INTERP, "\tinit LuaFunction %p\n", SELF);
+SUPER();
+}
+
+void destroy() {
+const Parrot_sub * const sub = PMC_sub(SELF);
+PIO_eprintf(INTERP, "\tdestroy LuaFunction %p %s\n", SELF, Parrot_string_cstring(INTERP, sub->name));
+SUPER();
+}
+
 /*
 
 =item C
@@ -47,6 +58,8 @@

 
 */
 void mark() {
+const Parrot_sub * const sub = PMC_sub(SELF);
+PIO_eprintf(INTERP, "\tmark LuaFunction %p %s\n", SELF, Parrot_string_cstring(INTERP, sub->name));
 SUPER();
 if (PMC_metadata(SELF))
 pobject_lives(INTERP, (PObj *)PMC_metadata(SELF));

Re: am I doing something wrong - hanoi example with 0.5.1 parrot release

[Aaron Trevena]

On 02/01/2008, jerry gay <[EMAIL PROTECTED]> wrote:
> @*ARGS and infix:// have been implemented in perl6 thanks to patrick,
> so hanoi.pl works with the svn head in parrot repo.

Yup - hanoi page on the wiki has been updated to reflect that.

I plan to try a few more programs out on the next monthly release -
starting with hilbert, and probably trying some cookbook recipes for
directorys, file access, command line args (i.e. like GetOpt), etc.

I have to say I'm astonished at what the perl6 guys have acheived in
only 8 or so weeks - even allowing for building on and learning from
NQP and Pugs, the next monthly release will likely have a perl 6
executable I can try code out on.

A.

-- 
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting

Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[Allison Randal]

Alan Rocker wrote:

I've attached a quickie shell script, in case that's what you want. It's a
naive little thing, but I think you'll be amused by its presumption.


Good start. Committed in r24479, with a small change to run it from the 
top-level directory instead of tools/dev. A little extra polish would be 
to make it skip docs/Makefile, and skip any files that start with "." 
(like .filename.pod.swp)


Thanks,
Allison

Re: S03 - Str autodecrement

[hv]

"Patrick R. Michaud" <[EMAIL PROTECTED]> wrote:
:Howeven, "returns a Failure object" in this context (autodecrement)
:still seems a bit ambiguous, because the return values of autoincrement
:and autodecrement are often ignored, as in:
:
:my $s = 'A00';
:$s--;
:say $s;
:
:So, what happens in the above?  Does $s become a Failure object?
:Does autodecrement recognize that it's in void context and thus
:becomes immediately fatal?

I'm not sure what the answer is, but it should be the same as for:
  my $s = 0;
  $s = 1 / $s;
  say $s;

In both cases, it is a domain error.

Hugo

Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[James E Keenan]

Allison Randal wrote:

Alan Rocker wrote:
I've attached a quickie shell script, in case that's what you want. 
It's a

naive little thing, but I think you'll be amused by its presumption.


Good start. Committed in r24479, with a small change to run it from the 
top-level directory instead of tools/dev. A little extra polish would be 
to make it skip docs/Makefile, and skip any files that start with "." 
(like .filename.pod.swp)




For portability reasons, however, shouldn't it be converted to Perl 5? 
I don't think we proceed on the assumption that all our target OSes can 
handle shell.

Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[Allison Randal]

James E Keenan wrote:


For portability reasons, however, shouldn't it be converted to Perl 5? I 
don't think we proceed on the assumption that all our target OSes can 
handle shell.


The difference here is that you can only generate Debian packages on a 
Debian-based system, so portability to non-Linux systems isn't a concern.


A Perl 5 script would be more flexible in the long-term, but for now 
this is a nice time-saver.


Allison

Re: [svn:parrot] r24439 - in trunk/languages/perl6: . config/makefiles

[jerry gay]

On Jan 2, 2008 3:51 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Wednesday 02 January 2008 08:39:51 [EMAIL PROTECTED] wrote:
>
> > Modified:
> >trunk/languages/perl6/   (props changed)
> >trunk/languages/perl6/config/makefiles/root.in
> >
> > Log:
> > [perl6]
> > - add suffixe .exe on Win32
>
> I'm not sure about this change.  None of our other Makefile targets have file
> extensions, and if this stays, we have to say "run make perl6 if you're on a
> Unixy platform and make perl6.exe if you're not".
>
that's how the $(PARROT) target works in root.in, also $(PBC_MERGE),
etc. earlier up in the template you'll see PARROT =
$(CUR_DIR)/@[EMAIL PROTECTED](EXE). i can't say i love it, but that *is* how
it works, so this patch makes that match up.

i modified the help message in parrot to be more clear about the make
target names:
@echo "Following targets are available for the user:"
...
@echo "  $(PBC_TO_EXE):"
@echo " Generate C, compile and link bytecode files"

so, yeah, it's a different target on different OSes, but it's
consistent with current usage elsewhere. i'd say this utility belongs
under either the 'all' or the 'world' target anyway, so it's built by
default, or when other utilities are requested (make world).

~jerry

Re: [perl #47391] Current status on Solaris 8/SPARC

[Andy Dougherty]

On Wed, 2 Jan 2008, James E Keenan wrote:

> Andy Dougherty wrote:
> > After fixing various minor little things, here's where I stand
> > on Solaris 8/SPARC after the recent changes.
> > 

> > Failed TestStat Wstat Total Fail  List of Failed
> > 
> > ---
> > t/configure/115-auto_warnings-02.t7  179222   14  16-22
> > t/configure/115-auto_warnings-03.t7  179222   14  16-22
> > t/configure/115-auto_warnings-04.t7  179222   14  16-22
> > t/configure/115-auto_warnings-05.t8  204823   16  16-23
> > t/configure/115-auto_warnings-06.t8  204823   16  16-23
> > t/configure/115-auto_warnings-07.t9  230424   18  16-24
> > t/configure/146-auto_snprintf-01.t   13  332830   26  18-30
> 
> Could you open an RT ticket for these -- or perhaps one for auto::warnings and
> one for aut::snprintf?  I will then re-work the tests, as I have a general
> idea of the problem.
> 
> What also would be helpful:  (1) Output of prove -v on these.  (2) How did you
> configure?  I.e., which (of your many!) perls did you use? which command-line
> options?  any interactive configuration?

It's the same problem I already reported on at length in #47391.  (I have
adjusted the subject line to reference that ticket so RT will pick it up.)
My perl was built with cc, but I don't have cc available for this build
of parrot.  I supplied all the correct flags on the Configure.pl command
line, but the tests are still assuming the values from the underlying perl
configuration.  The tests are still using init::defaults.  That is wrong.
They should be using the results stored in Parrot::Config instead.

Here, in gory detail, is the diagnosis.  I configured with perl5.10,
which was built with Sun's cc.

$ perl5.10 -V:cc
cc='cc';

Sun's cc is not available for this build of parrot.  However, gcc is.
I supplied all the appropriate flags to Configure.pl to use gcc:

$ perl5.10 Configure.pl --cc=gcc --link=gcc --ld=gcc --cxx=g++
[ ... successful Configure.pl output omitted ...]

However, 115-auto_warnings-0[2-7].t and 146-auto_snprintf-01.t all fail
in the same way:

$ prove -v t/configure/115-auto_warnings-02.t
t/configure/115-auto_warnings-021..22
ok 1 - use config::init::defaults;
ok 2 - use config::init::hints;
ok 3 - use config::inter::progs;
ok 4 - use config::auto::warnings;
ok 5 - init::defaults constructor returned defined value
ok 6 - The object isa init::defaults
ok 7 - init::defaults has description
ok 8 - init::defaults runstep() returned defined value
ok 9 - init::hints constructor returned defined value
ok 10 - The object isa init::hints
ok 11 - init::hints has description
ok 12 - init::hints runstep() returned defined value
ok 13 - inter::progs constructor returned defined value
ok 14 - The object isa inter::progs
ok 15 - inter::progs has description
Compilation failed with 'cc'
# Looks like you planned 22 tests but only ran 15.
dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 16-22
Failed 7/22 tests, 68.18% okay
Failed TestStat Wstat Total Fail  List of Failed

---
t/configure/115-auto_warnings-02.t  255 6528022   14  16-22
Failed 1/1 test scripts. 7/22 subtests failed.
Files=1, Tests=22,  2 wallclock secs ( 1.73 cusr +  0.49 csys =  2.22 CPU)
Failed 1/1 test programs. 7/22 subtests failed.

The failure is because the tests are not honoring my command-line settings
for the compiler and linker.  If config/inter/progs.pm had proper error
reporting (see my long rant in #41168) it would direct you to look in
the file test.ldo.

$ cat test.ldo
Can't exec "CC": No such file or directory at lib/Parrot/Configure/Utils.pm 
line 91.

Where did that 'CC' come from?  It came from config/init/hints/solaris.pm,
which tries to guess the appropriate linker to use based on the current
value of the compiler.  Since my underlying perl configuration used
Sun's cc, and the hint file apparently does not know about my command
line settings, it guesses that the appropriate linker to use is Sun's CC.

In short, the hint file is being run in an environment where it does
not have access to my command line arguments, where I explicitly
set everything appropriately already.  It is relying, instead, on
init::defaults, which, as I have pointed out, is incorrect.

The simplest, most obvious, fix is to never use init::defaults (except
in the one case where you wish to test config/init/defaults.pm itself).
Use the correct values in Parrot::Config instead.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: Multiline comments in Perl6

[Larry Wall]

On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote:
: Paul Hodges wrote:
: > http://perl6.org/doc/design/syn/S02.html still says:
: >  "Intra-line comments will not be supported in standard Perl"
: 
: This is wrong, since S02 also defines intra-line comments, under
: "Whitespace and Comments".  It calls them 'embedded comments'.  You
: don't need a 'use' statement.

Note that the document on perl6.org is nearly three years out-of-date!
Anyone know who runs that site?  We need a better GC algorithm. :)

The best place to read synopses right now is probably perlcabal.org/syn
because it has the test suite interspersed, so you can easily click
to see test examples if you don't understand a particular passage.

Larry

Re: Sequential bias in S04 (and Perl6 in general)

[Dave Whipp]

Moritz Lenz wrote:


You can achieve that with the "hyper" list-op (see S02).
Also note that an optimizer is free to automatically add the "hyper"
list op if it can prove that the executed block has no side effects.


Yes, there are some places where things are better than others, which is 
why I called out S04 specifically. The concern I have is that it is 
necessary to use a "functional" subset to explicitly tell Perl6 that I 
want it to do the right thing on many-core systems.


The bias that I see is the perceived need to say that hypers (and 
junctions) may "auto-thread", without needing to be explicit that 
control statements "auto-sequentialize". That latter is assumed, but the 
former is explicit: this asymmetry is the bias.


In as much as it is possible to talk about core features for Perl6, the 
control structures of S04 are "core". Given generic iteration and 
selection mechanisms that are unbiased with respect to concurrency, it 
is moderately straight forward to define the sequentially constrained 
versions as an "add on" feature. The reverse is more difficult: 
concurrency as an add-on feature is hard.



That sounds really like a bad idea for simple "just do it" scripts. Just
imagine explaining concurrency issue to a beginner who is not even
confident with variables and blocks...


Just like hyper-operators, the form of the statements that are less 
biased towards sequentialization need not be dangerous for beginners, if 
the language design is careful.


One could start simply by defining the order of iteration to be 
undefined, and adding a form that does guarantee the order for those 
cases where it does matter. From there, it is a fairly small jump from 
"unordered" to "concurrent", assuming the bulk of the language has 
semantics that preserve safety for concurrent operations (admittedly, a 
non-trivial assumption).

$obj.can("bark"); # or can it?

[Ovid]

I don't know if this was considered a non-issue when I last raised it,
but in this synopsis:

  http://dev.perl.org/perl6/doc/design/syn/S12.html

I see that the behavior of .can() metamethod hasn't been updated.  My
concern is that someone calls $object.can('bark') and they expect to
pass an integer to the method but there is no method 'bark' which
accepts an argument.  .can() will still dutifully return a method (or
methods) to you.  Thus, .can() will lie to you because you can't say:

  $object.HOW.can( ... some signature ... )

Perl 5 couldn't really solve this and programmers just had to "know"
that all methods were implicitly variadic.  I seem to recall that Larry
had an idea about how to specify a signature (I could be misremembering
and I can't find the response).

Has there been any more thought about how to appropriately deal with
this?  Though I could be in the minority, this does seem like a glaring
hole in Perl 6's OO behavior.

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Re: Multiline comments in Perl6

[Gabor Szabo]

On Jan 3, 2008 6:36 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote:
> : Paul Hodges wrote:
> : > http://perl6.org/doc/design/syn/S02.html still says:
> : >  "Intra-line comments will not be supported in standard Perl"

> Note that the document on perl6.org is nearly three years out-of-date!
> Anyone know who runs that site?  We need a better GC algorithm. :)
>
> The best place to read synopses right now is probably perlcabal.org/syn
> because it has the test suite interspersed, so you can easily click
> to see test examples if you don't understand a particular passage.


What about http://dev.perl.org/perl6/synopsis/ ?
Is that also out of date?
http://www.pugscode.org/ links there...

Gabor

operator minmax

[herbert breunung]

just a small question, what speak against this construct:

$min, $max = @a.minmax;

Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[ajr]

> James E Keenan wrote:
>>
>> For portability reasons, however, shouldn't it be converted to Perl 5?
>
> The difference here is that you can only generate Debian packages on a
> Debian-based system, so portability to non-Linux systems isn't a concern.
>
That was my assumption. (Along with the need for immediacy.) I'll put in
the refinements Allison suggested, then use that as the spec. for a Perl
script, if somebody doesn't beat me to it.


--

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

Re: $obj.can("bark"); # or can it?

[Gianni Ceccarelli]

On 2008-01-03 Ovid <[EMAIL PROTECTED]> wrote:
> Perl 5 couldn't really solve this and programmers just had to "know"
> that all methods were implicitly variadic.  I seem to recall that
> Larry had an idea about how to specify a signature (I could be
> misremembering and I can't find the response).

Hmmm. Could it have been with the C<:()> construct?

So that we might one day say

  $object.HOW.can('bark',:(Int))

I feel, though, that saying

  $object.HOW.can('bark',\(42))

would be more useful, since the dispatcher unifies signatures with
captures, and after all I want to know if I can invoke a method called
C with the number 42.

By the way, what happened to C<> ? I can't find it in the Synopses ( http://perlcabal.org/syn/ )

-- 
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

No violence, gentlemen -- no violence, I beg of you!  Consider the
furniture! -- Sherlock Holmes

Re: [svn:parrot] r24497 - in trunk: languages/lolcode/src/parser tools/dev

[chromatic]

On Thursday 03 January 2008 12:05:48 [EMAIL PROTECTED] wrote:

> Log:
> Add copyright statement to file which lacked it; t/codingstd/copyright.t
> should once again pass.
>
> Modified: trunk/languages/lolcode/src/parser/actions.pm
> ===
>=== --- trunk/languages/lolcode/src/parser/actions.pm  (original)
> +++ trunk/languages/lolcode/src/parser/actions.pm Thu Jan  3 12:05:48 2008
> @@ -1,3 +1,4 @@
> +# Copyright (C) 2001-2007, The Perl Foundation.
>  # $Id$

> -# Copyright (c) 2007, The Perl Foundation
> +# Copyright (C) 2001-2008, The Perl Foundation.
>  # $Id$

I'm not sure this is legal.  Certainly TPF holds a copyright on Parrot from 
2001 - 2008, but these files are new in 2008, so I'm not sure TPF can assert 
copyright on them for previous years.

-- c

[perl #49308] [BUG]: config/auto/alignptrs.pm fails if required alignment > 1

[James Keenan via RT]

(Neglected to CC to list first time through.)

Can you try this patch?


diff.alignptrs.pm
Description: Perl program

[perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs

[James Keenan via RT]

On Thu Jan 03 04:57:22 2008, [EMAIL PROTECTED] wrote:
> 
> The difference here is that you can only generate Debian packages on a 
> Debian-based system, so portability to non-Linux systems isn't a concern.
> 

D'oh.  My oversight.

[PATCH] Re: [perl #49308] config/auto/alignptrs.pm fails if required alignment > 1

[Andy Dougherty]

> Here's the output of Configure.pl --verbose on a SPARC where the required 
> alignment is 4.  The test correctly deduces that alignments of 64, 32, 16, 
> 8, and 4 all work, but apparently throws that information away when the 2 
> and 1 byte alignment tests fail.

And here's a simple patch to fix it.  It reverses the order of the tests
and saves the first successful one.

--- parrot-current/config/auto/alignptrs.pm Thu Jan  3 16:17:39 2008
+++ parrot-andy/config/auto/alignptrs.pmThu Jan  3 16:24:49 2008
@@ -55,9 +55,10 @@
 # Now really test by compiling some code
 $conf->cc_gen('config/auto/alignptrs/test_c.in');
 $conf->cc_build();
-for my $try_align ( 64, 32, 16, 8, 4, 2, 1 ) {
+for my $try_align ( 1, 2, 4, 8, 16, 32, 64 ) {
 my $results = $conf->cc_run_capture($try_align);
 $align = _evaluate_results($results, $try_align);
+last if defined($align);
 }
 $conf->cc_clean();
 

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #49308] [BUG]: config/auto/alignptrs.pm fails if required alignment > 1

[Andy Dougherty]

On Thu, 3 Jan 2008, James Keenan via RT wrote:

> (Neglected to CC to list first time through.)
> 
> Can you try this patch?

Oops.  Crossed in the mail.  I just sent a much simpler version in.  At a 
glance, yours should also work, so I guess it really doesn't matter.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [svn:parrot] r24497 - in trunk: languages/lolcode/src/parser tools/dev

[Patrick R. Michaud]

On Thu, Jan 03, 2008 at 12:39:54PM -0800, chromatic wrote:
> On Thursday 03 January 2008 12:05:48 [EMAIL PROTECTED] wrote:
> > -# Copyright (c) 2007, The Perl Foundation
> > +# Copyright (C) 2001-2008, The Perl Foundation.
> >  # $Id$
> 
> I'm not sure this is legal.  Certainly TPF holds a copyright on Parrot from 
> 2001 - 2008, but these files are new in 2008, so I'm not sure TPF can assert 
> copyright on them for previous years.

Correct.  See also the thread at 
http://www.nntp.perl.org/group/perl.perl6.internals/2007/08/msg39874.html

Essentially the rule of thumb is that we update the copyright years to
include any year where the file is somehow modified.  Thus a file newly
created today gets a copyright date of 2008, a file that is modified
that was previously 2007 or less would be updated to include 2008.

We _don't_ go back and update unmodified files to include a 2008
copyright -- those wait until a modification occurs.

I've updated the mk_language_shell.pl script to correctly reflect
the 2007-2008 copyright.

Pm

Fuel for the GC PDD

[chromatic]

"Scalable Locality-Conscious Multithreaded Memory Allocation"
http://people.cs.vt.edu/~scschnei/papers/ismm06.pdf

Re: Multiline comments in Perl6

[Paul Hodges]

--- Jonathan Lang <[EMAIL PROTECTED]> wrote:

> Paul Hodges wrote:
> > http://perl6.org/doc/design/syn/S02.html still says:
> >  "Intra-line comments will not be supported in standard Perl"
> 
> This is wrong, since S02 also defines intra-line comments, under
> "Whitespace and Comments".  It calls them 'embedded comments'.  You
> don't need a 'use' statement.

So I found something worth fixing? =o]

===
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: what can I do in perl 6 today?

[Juerd Waalboer]

jerry gay skribis 2007-12-28  6:46 (-0800):
> if we had a smoke machine (e.g. feather.perl6.nl) that frequently
> built the various implementations (pugs, kp6, perl6,) ran the perl 6
> test suite against each implementation, and posted color-coded
> tabulated html results, it would offer a way for folks to compare
> implementations directly. we don't have this right now. smolder
> (http://sourceforge.net/projects/smolder) is what we have in mind to
> use.

The machine is there, it just needs people to operate it!

If a cleaner compartiment is needed for smoking (sounds paradoxal), I
can create a separate virtual machine for that.
-- 
Met vriendelijke groet,  Kind regards,  Korajn salutojn,

  Juerd Waalboer:  Perl hacker  <[EMAIL PROTECTED]>  
  Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>

Re: [svn:parrot] r24497 - in trunk: languages/lolcode/src/parser tools/dev

[James E Keenan]

chromatic wrote:

On Thursday 03 January 2008 12:05:48 [EMAIL PROTECTED] wrote:


Log:
Add copyright statement to file which lacked it; t/codingstd/copyright.t
should once again pass.

Modified: trunk/languages/lolcode/src/parser/actions.pm
===
=== --- trunk/languages/lolcode/src/parser/actions.pm   (original)
+++ trunk/languages/lolcode/src/parser/actions.pm   Thu Jan  3 12:05:48 2008
@@ -1,3 +1,4 @@
+# Copyright (C) 2001-2007, The Perl Foundation.
 # $Id$



-# Copyright (c) 2007, The Perl Foundation
+# Copyright (C) 2001-2008, The Perl Foundation.
 # $Id$


I'm not sure this is legal.  Certainly TPF holds a copyright on Parrot from 
2001 - 2008, but these files are new in 2008, so I'm not sure TPF can assert 
copyright on them for previous years.




Hey, I was just trying to fix a test that was failing across the board 
on our smoke tests.  If the dating is incorrect, please go ahead and 
change.  IANAA.


kid51

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

[larry]

Author: larry
Date: Thu Jan  3 16:15:39 2008
New Revision: 14479

Modified:
   doc/trunk/design/syn/S09.pod

Log:
Clarification of autovivification semantics in terms of protoobjects


Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podThu Jan  3 16:15:39 2008
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 13 Sep 2004
-  Last Modified: 10 Jul 2007
+  Last Modified: 3 Jan 2008
   Number: 9
-  Version: 22
+  Version: 23
 
 =head1 Overview
 
@@ -1160,9 +1160,12 @@
 
 =head1 Autovivification
 
-Autovivification will only happen if the vivifiable path is used as a
-container, by binding, assigning, or capturing into an argument list.
-On the other hand, value extraction does not autovivify.
+Autovivification will only happen if the vivifiable path is bound to
+a read-write container.  Value extraction (that is, binding to a readonly
+or copy container) does not autovivify.  (Note that assignment
+implicitly binds a copy, so it does not autovivify.)  Any mention of
+an expression within a C delays the autovivification decision
+to binding time.  (Binding to a "ref" parameter also defers the decision.)
 
 This is as opposed to Perl 5, where autovivification could happen
 unintentionally, even when the code looks like a non-destructive test:
@@ -1176,17 +1179,62 @@
 my %hash;
 exists %hash; # %hash is still empty
 
-But these ones I autovivify:
+But these bindings I autovivify:
 
 my %hash;
 my $val := %hash;
 
 my @array;
-my $obj = [EMAIL PROTECTED]; # $obj is a Capture object - see S02
+my $cap = [EMAIL PROTECTED]; # $obj is a Capture object - see S02
+my :($obj) := $cap;   # @array[0][0] created here
+
+my @array;
+foo(@array[0][0]);
+sub foo ($obj is rw) {...}  # same thing, basically
 
 my %hash;
 %hash = "foo"; # duh
 
-This rule applies to C, C, and C container objects.
+This rule applies to C, C, and any other container type that
+chooses to return an autovivifiable protoobject (see S12) rather than simply
+returning C when a lookup fails.  Note in particular that, since
+autovivification is defined in terms of protoobjects rather than failure,
+it still works under "use fatal".
+
+The type of the protoobject returned by a non-successful lookup should 
+be identical to the type that would be returned for a successful lookup.
+
+Binding of an autovivifiable protoobject to a non-writeable container
+translates the protoobject into a similar protoobject without
+its autovivifying closure and puts that new protoobject into the
+container instead (with any pertinent historical diagnostic information
+carried over).  There is therefore no magical method you can call on
+the readonly parameter that can magically autovivify the protoobject
+after the binding.  The newly bound variable merely appears to be a
+simple uninitialized value.  (The original protoobject retains its
+closure in case it is rebound elsewhere to a read-write container.)
+
+Some implementation notes:  Nested autovivifications work by making
+nested protoobjects that depend on each other.  In the general case
+the containers must produce protoobjects any time they do not know
+how the container will be bound.  This includes when interpolated into
+any capture that has delayed binding:
+
+\( 1, 2, %hash )  # must defer
+\%hash# must defer
+
+In specific situations however, the compiler can know that a value
+can only be bound readonly.  For instance, C<< infix:<+> >> is
+prototyped such that this can never autovivify:
+
+%hash + 42
+
+In such a case, the container object need not go through the agony
+of calculating an autovivifying closure that will never be called.
+On the other hand:
+
+%hash += 42
+
+binds the left side to a mutable container, so it autovivifies.
 
 =for vim:set expandtab sw=4:

Re: Multiline comments in Perl6

[Larry Wall]

On Thu, Jan 03, 2008 at 08:55:24PM +0200, Gabor Szabo wrote:
: On Jan 3, 2008 6:36 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Wed, Jan 02, 2008 at 11:28:54AM -0800, Jonathan Lang wrote:
: > : Paul Hodges wrote:
: > : > http://perl6.org/doc/design/syn/S02.html still says:
: > : >  "Intra-line comments will not be supported in standard Perl"
: 
: > Note that the document on perl6.org is nearly three years out-of-date!
: > Anyone know who runs that site?  We need a better GC algorithm. :)
: >
: > The best place to read synopses right now is probably perlcabal.org/syn
: > because it has the test suite interspersed, so you can easily click
: > to see test examples if you don't understand a particular passage.
: 
: 
: What about http://dev.perl.org/perl6/synopsis/ ?
: Is that also out of date?
: http://www.pugscode.org/ links there...

That is up-to-date with respect to (very official) synopses that live
in svn.perl.org's repository, but not with respect to those draft
synopses that currently live in pugs's repository.  (The perlcabal
page tracks both sets.)

Larry

[perl #49308] [BUG]: config/auto/alignptrs.pm fails if required alignment > 1

[James Keenan via RT]

Applied a combination of Andy's patch and mine in r24516.

[perl #43134] [TODO] Find a generalised way to determine location of Fink

[James Keenan via RT]

On Sat Dec 29 09:14:40 2007, [EMAIL PROTECTED] wrote:
> 
> If there is no objection, I will apply this to trunk within a week. 

No one objected, so I applied this patch to trunk in r24517.

[perl #49356] [BUG]: t/stm/basic_mt.t hangs indefinitely

[via RT]

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


[li11-226:parrot] 502 $ prove -v t/stm/basic_mt.t
t/stm/basic_mt1..4
ok 1 - wait (simple)


... and it waits forever.  Caused make test to fail to complete on  
Linux:  first time I've ever seen that.

kid51

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

[Smylers]

[EMAIL PROTECTED] writes:

> Modified:
>doc/trunk/design/syn/S09.pod
> 
> Log:
> Clarification of autovivification semantics in terms of protoobjects
> 
> -my $obj = [EMAIL PROTECTED]; # $obj is a Capture object - see S02
> +my $cap = [EMAIL PROTECTED]; # $obj is a Capture object - see S02

Does the variable name in the comment need changing too?

Smylers

[perl #49356] [BUG]: t/stm/basic_mt.t hangs indefinitely

[James Keenan via RT]

The test file itself has not been substantively changed in several
months, so it's not the test itself that's causing the problem.

[perl #43269] [BUG] setline is tied to PIR source

[Bob Rogers]

   From: "Patrick R. Michaud via RT" <[EMAIL PROTECTED]>
   Date: Wed, 02 Jan 2008 22:29:35 -0800

   On Wed Jun 20 16:23:40 2007, pmichaud wrote:
   > On Thu, Jun 21, 2007 at 12:08:33AM +0100, Jonathan Worthington wrote:
   > >
   > > Currently HLL debug info stuff is spec'd, but not implemented. Well, OK, 
   > > the storage of it in bytecode is spec'd, the exact PIR syntax for it 
   > > isn't. So there are two tasks: implement the underlying storage model 
   > > for this and sort out some PIR syntax for it.

Where is this specified?  In a quick scan of docs/, I only found what
seemed to be old stuff.

   . . .

   Now that the pdd15 items are completed, and we're getting a lot more
   people programming in HLLs on Parrot (NQP, perl6, more coming), it would
   be good to have this soon if possible.  Or, if it's not likely to appear
   soon, then PCT should start looking into a workaround of some sort.

   Thanks!

   Pm

I am interested in this, too.  We will also need a PIR API for
inspecting active Parrot_Context's . . .

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

Re: [svn:parrot-pdd] r24108 - in trunk: . docs/pdds

[Bob Rogers]

   From: Allison Randal <[EMAIL PROTECTED]>
   Date: Thu, 27 Dec 2007 19:15:40 +0200

   Bob Rogers wrote:

   > Thought so.  I ask because Common Lisp has provision for anonymous
   > classes, and I was wondering how I might support that some day.  But my
   > interest is just academic curiosity at this point, because I'm (still)
   > nowhere near implementation.

   CLOS dispatches on anonymous classes? What does it dispatch on in the 
   absence of a name? A class object (or equivalent)?

Yes, a class object; CLOS dispatch is done in terms of class objects.
It's not in the ANSI spec (and trying to define methods on anonymous
classes in a portable way is tricky), but is widely implemented as part
of the metaobject protocol.  Mind you, I have not studied any
application that actually uses this feature, but I do recall hearing
about them.

   And thanks for the other clarifications.  (I was going to post a
longer response, but that's mostly what it amounted to.)

-- Bob

Re: Sequential bias in S04 (and Perl6 in general)

[Joe Gottman]

Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It 
seems to be infused with a bias towards non-parallel models of 
computation. Concurrently appears to be an add-on feature -- whereas 
we should have a mindset that explicit sequential constraints are the 
add-on feature.


Two statements that are missing from S04 (feel free to change the 
names) are C; and a form of C that tests/executes 
multiple C clauses in arbitrary order (without needing the 
sequential C statement).



  forall @a -> $x { ... }

runs the code block on each element of @a (no defined order). If @a is 
a lazy generator then generation of values is concurrent with running 
the code block on those generated values).


  forall @a -> $x : sequential { ... }

forces an additional sequential constraint on the execution, such that 
the Nth element of @a is not obtained until the code block has 
executed for the (N-1)th. C is an alias for this constrained 
variant. C implies this sequential constraint to avoid surprising 
legacy (perl5) programmers.


Similarly, C, C, C, C, ... should all 
accept this ":sequential" adverb to force them to iterate their lists 
sequentially -- and should otherwise iterate in arbitrary/concurrent 
order.



  given $x :all { ... }

would run the code blocks of all C statements (in the C 
block) which smart-match true against $x. The ":sequential" adverb 
would be used to constrain execution of the C blocks to run in 
the order they appear in the source code. (it would be good if the 
current C could be thought of as using a ":first" modifier, 
which runs the code block of the lexically first C clause that 
evaluates to true -- but which potentially tests multiple C 
clauses in parallel. Unfortunately the current language definition is 
much too sequential for this viewpoint)




I think a major reason for the bias toward sequential processing is 
that if code that should be processed sequentially is instead processed 
concurrently then the results will almost always be incorrect. 
Conversely, if code that should be processed concurrently is instead 
processed sequentially, the results will be correct though the program 
will take longer to run than necessary.  I don't think it's unreasonable 
to prefer always correct but slow to sometimes incorrect and fast, 
especially if it is difficult to automatically tell which cases might 
result in incorrect behavior.


  On the other hand, this being Perl, I do believe it should be easy to 
specify the concurrent case.  I think that a  keyword (and a 
 keyword corresponding to ) would be a good idea.  
These would not be quite parallel to  and  because there 
would be some subtle differences arising from the concurrent 
processing.  For instance,  probably should not be used with 
, because  should stop subsequent iterations and the 
subsequent iterations could already have occurred when it is called.  
Similarly,  should not be used with , because the 
next case might already have been checked when  is called. 


Joe Gottman

[perl #49364] [CAGE]: Eliminate $data{args} from configuration step class initializers

[via RT]

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


The Parrot configuration step classes (config/*/*.pm) each have an  
initializer routine, _init().  Most step classes assign an array ref  
to an 'args' attribute.  Example:

sub _init {
 my $self = shift;
 my %data;
 $data{description} = q{Detecting compiler attributes (- 
DHASATTRIBUTE_xxx)};
 $data{args}= [ qw( cc verbose define ) ];
 $data{result}  = q{};
 return \%data;
}

In the past, it was thought that at some future point the elements in  
this array would be used somehow by the step's runstep() method.  But  
only two classes ever used this functionality.  They used it only to  
hold a list of relevant command-line options.  And they have not used  
the feature since we refactored it out four months ago.  ($conf- 
 >options->get() does the trick instead.)

So I propose to eliminate the excess baggage.  Recently created  
configuration steps have done without the 'args' attribute, and I  
have eliminated all tests for the 'args' attribute in the tests in t/ 
configure/*.t.

What remains is:
(1) Eliminate code from Parrot::Configure and Parrot::Configure::Step  
that was used to process the 'args' attribute.
(2) Adjust documentation in those modules and in docs/configuration.pod.
(3) Eliminate the $data{args} assignment from each config step class.

I'll take this in stages so that nothing breaks.

Thank you very much.

kid51

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

[larry]

Author: larry
Date: Thu Jan  3 19:42:19 2008
New Revision: 14480

Modified:
   doc/trunk/design/syn/S09.pod

Log:
Typo from Smylers++
More clarification of assignment semantics in terms of underlying binding


Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podThu Jan  3 19:42:19 2008
@@ -1162,8 +1162,8 @@
 
 Autovivification will only happen if the vivifiable path is bound to
 a read-write container.  Value extraction (that is, binding to a readonly
-or copy container) does not autovivify.  (Note that assignment
-implicitly binds a copy, so it does not autovivify.)  Any mention of
+or copy container) does not autovivify.  (Note that assignment implicitly
+binds a copy, so it does not autovivify its right side.)  Any mention of
 an expression within a C delays the autovivification decision
 to binding time.  (Binding to a "ref" parameter also defers the decision.)
 
@@ -1185,7 +1185,7 @@
 my $val := %hash;
 
 my @array;
-my $cap = [EMAIL PROTECTED]; # $obj is a Capture object - see S02
+my $cap = [EMAIL PROTECTED]; # $cap is a Capture object - see S02
 my :($obj) := $cap;   # @array[0][0] created here
 
 my @array;
@@ -1237,4 +1237,8 @@
 
 binds the left side to a mutable container, so it autovivifies.
 
+Assignment doesn't look like binding, but consider that it's really
+calling some kind of underlying set method on the container, which
+must be mutable in order to change its contents.
+
 =for vim:set expandtab sw=4:

Re: [perl #43269] [BUG] setline is tied to PIR source

[Patrick R. Michaud]

On Thu, Jan 03, 2008 at 09:40:23PM -0500, Bob Rogers wrote:
>From: "Patrick R. Michaud via RT" <[EMAIL PROTECTED]>
>Date: Wed, 02 Jan 2008 22:29:35 -0800
> 
>On Wed Jun 20 16:23:40 2007, pmichaud wrote:
>> On Thu, Jun 21, 2007 at 12:08:33AM +0100, Jonathan Worthington wrote:
>> >
>> > Currently HLL debug info stuff is spec'd, but not implemented. Well, 
> OK, 
>> > the storage of it in bytecode is spec'd, the exact PIR syntax for it 
>> > isn't. So there are two tasks: implement the underlying storage model 
>> > for this and sort out some PIR syntax for it.
> 
> Where is this specified?  In a quick scan of docs/, I only found what
> seemed to be old stuff.

Correct, it's fairly old -- just a brief mention in
docs/pdds/draft/pdd06_pasm.pod, and a few RT tickets here
and there.

Pm

RE: [perl #43269] [BUG] setline is tied to PIR source

[Allam Reddy, Thomas]

I would like to get unsubscribed from this list. Please help me.

Thanks & Regards,
Thomas Reddy A
 
"The more I learn, the more I realize how much I don't know"
-Original Message-
From: Patrick R. Michaud [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 04, 2008 12:05 PM
To: Bob Rogers
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [perl #43269] [BUG] setline is tied to PIR source

On Thu, Jan 03, 2008 at 09:40:23PM -0500, Bob Rogers wrote:
>From: "Patrick R. Michaud via RT"
<[EMAIL PROTECTED]>
>Date: Wed, 02 Jan 2008 22:29:35 -0800
> 
>On Wed Jun 20 16:23:40 2007, pmichaud wrote:
>> On Thu, Jun 21, 2007 at 12:08:33AM +0100, Jonathan Worthington
wrote:
>> >
>> > Currently HLL debug info stuff is spec'd, but not implemented.
Well, OK, 
>> > the storage of it in bytecode is spec'd, the exact PIR syntax
for it 
>> > isn't. So there are two tasks: implement the underlying storage
model 
>> > for this and sort out some PIR syntax for it.
> 
> Where is this specified?  In a quick scan of docs/, I only found what
> seemed to be old stuff.

Correct, it's fairly old -- just a brief mention in
docs/pdds/draft/pdd06_pasm.pod, and a few RT tickets here
and there.

Pm

Keeping buzz going

[Andy Lester]

http://use.perl.org/~pmichaud/journal/35272
http://perlbuzz.com/2008/01/flurry-of-perl-6-activity-picks-up-new-contributor.html

Lots of cool stuff is going on, and I'm so so glad to see it.  I'm  
thinking of making a Perl 6-specific column in Perlbuzz, because I'd  
like to have a one-stop shop for Perl 6 / Parrot news for those that  
want to follow, and I don't want to keep posting progress stuff in the  
main Perlbuzz column.


If I created http://perlbuzz.com/perl6andparrotprojectupdates or  
something similar, do you think there'd be enough to fill the pipe?


xoa

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance