Re: Concurrency: hypothetical variables and atomic blocks

2006-06-02 Thread Jonathan Worthington

"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote:

On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:

Forgive this ignorant soul; but what is "STM"?


Software Transaction Memory

Well, Software Transactional Memory if I'm being picky.  :-)  Some info and 
an interesting paper here:-

http://www.cambridge.intel-research.net/~rennals/faststm.html

Jonathan 



About default options ':ratchet' and ':sigspace' on rules

2006-06-02 Thread Shu-chun Weng

Hello,

(used to post on google group but found it does not deliver)

I'm implementing "MiniPerl6" in pugs which is the first step of
writing perl 6 parser in perl 6.  In module Pugs::Grammar::MiniPerl6,
http://svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6,
I use another perl 6 grammar to describe it.  It works well several
days before when the parsing engine written in perl 5 did not
implemented :ratchet and :sigspace flags.

The grammar file can be found here:
http//svn.openfoundry.org/pugs/misc/pX/Common/Pugs-Grammar-MiniPerl6/lib/Pugs/Grammar/MiniPerl6.grammar

The "token" part is fine, but the "rule" part is extremely ugly.  I can
not add additional spaces to format it.

I'd like to suggest two changes to make it easier to write rules:

 1. Spaces at beginning and end of rule blocks should be ignored
since space before and after current rule are most likely be
defined in rules using current one.
 1a. I'm not sure if it's "clear" to define as this, but the spaces
 around the rule-level alternative could also be ignored.  For
 instance, look at the rule FunctionAppExpr defined in
 MiniPerl6 grammar file.

   rule FunctionAppExpr
{|||[?<'('>?<')'>]?}

 I could not even put a new line in it.  In the file, since there
 are production rules, I put the brases on strange positions
 to format it better.

 2. I am not sure the default rule of , I couldn't found it in
S05.  Currently the engine use :P5/\s+/ but I would like it to
be :P/\s*/ when it's before or after non-words and remains
the same (\s+) otherwise.

I do not subscribe this group but subscribe daily digest, so it's OK to
reply on the list.  Suggestions welcome!

Cheers,
Shu-Chun Weng


RE: Synchronized / Thread syntax in Perl 6

2006-06-02 Thread John Drago


> > James Mastros wrote:
> > > I don't like the name synchronized -- it implies that multiple
> > > things are happening at the same time, as in synchronized swiming,
> > > which is exactly the opposite of what should be implied.
> > > "Serialized" would be a nice name, except it implies serializing
> > > to a serial format, like disk. "Locked" is the best name I can
> > > think of, and it frankly isn't that good -- it's so vauge as to
> > > be able to mean almost anything.
> > > . . .
> >
> > Agreed - maybe "is serial" instead, which suggests "is parallel"
> > would be its implicit counterpart.
> 
> You mean "is parallel" as a synonym for "is async"? I actually like it
> better, but that's just me.


I think "is parallel" denotes something as usable by multiple threads 
simultaneously, "in parallel".
"is serial" would denote that only one thread can use the $thing at a time, 
exclusively.


> 
> > If we have a situation that looks like this:
> >
> > our method TakesForever ( int $num is serial ) is async {
> >   # Do something that takes a long time...then:
> >   $num++;
> >   # $num has not been changed by anything else that might
> >   # have access to $num.
> > }
> >
> > my $age = 27;
> > TakesForever( $age );
> > $age += 20; # Fails somehow, because &TakesForever is working on $num
> 
> Hmm
> Is "fails somehow" the default?


After reading your comment, I realize the whole direction I started thinking 
about this is all wrong.
More on that in a minute, after coffee.


> I was thinking the better default would be more like standard
> threading.
> If $age has been passed to an asynchronous closure, it should be marked
> as locked, and other threads trying to access it would have to get a
> lock first. Yes, lots of overhead but that way if the default is
> WAIT (which seems the smart default to me), the thread waits until
> TakesForever() releases the resource.
> 
> if we declare
> 
>  our method TakesForever ( int $num is serial ) is async but NOWAIT {
>...
>  }
> 
> or
> 
>  my $age = 27 but NOWAIT;
> 
> or
> 
>  TakesForever( $age but NOWAIT );
> 
> (or whatever) then I'd say it should just fail. I mean, isn't that kind
> of the idea, to have that sort of flexibility?
> 

Perhaps some more syntax-play is in order here.


  I should note that my only experience with threading under Perl5 is via 
threads.pm (and forks.pm).
  I have not written multi-threaded applications using anything else (Java, 
.Net, etc).
  I have, however written several critical (to our business) applications that 
depend on threads.pm and/or forks.pm


One thing about threading with Perl5 is that it is easy to write a simple 
threaded program that is entirely opaque - unless you
wrote the program yourself.

The program below gets a list of coderefs and executes each one, then returns 
the result.
#
(Using the threads.pm way...)
package QueueRunner;

use strict;
use threads;
use threads::shared;

sub process_job_queue
{
  my ($s, @jobs_in) = @_;
  my @results : shared = ();
  my @workers = ();

  push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
  $_->join foreach @workers;
  return @results;
}# end process_job_queue()

# Elsewhere...
package main;

my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3 );

#


And my attempt at the same, using Perl6: 
#

class QueueRunner {
  our sub process_job_queue( Code @jobs_in ) returns List of Any {
my Any @results is parallel;
my Thread @workers = ();

for @jobs_in {
  @workers.push( async { &_() } );
}
for @workers {
  @results.push( $_.join() );
}

return @results;
  }# end process_job_queue()
}# end QueueRunner

# Elsewhere...
my @answer = QueueRunner.process_job_queue( @jobs );

#


I made absolutely no progress here.  It seems to me that it's no more obvious 
what's going on here than in the Perl5 version.  Any
comments?

Regards,
John Drago




$1,000 Grant (was: prize) for Perl 6 Wiki written in Perl 6

2006-06-02 Thread Conrad Schneiker
The note below is in reply to these preceding posters:

> From: Ovid [mailto:[EMAIL PROTECTED]
[...]
> From: Ask Bjørn Hansen [mailto:[EMAIL PROTECTED]
[...]
> From: Fagyal Csongor [mailto:[EMAIL PROTECTED]
[...]
> From: [EMAIL PROTECTED]
[...]

Thanks for the thought-provoking comments and suggestions.

My conclusion from reading them is that in the mutual interests of
{laziness, impatience, and hubris}, a grant seems like a better way to
proceed. 

I'll have to give some more thought to the specifications and review
the earlier suggestions--although I'd prefer to delegate that to
@Larry (or some subset thereof), although perhaps @perl6-users could
do well enough.

Here are my current thoughts for getting the best net ROI on this
proposed "extreme leverage wikicosm" grant:

1) This is a Perl 6 pilot project with the aim of producing a working
wiki prototype that others can then subsequently hack on,
incorporating relevant new Perl 6 features as they come on line.
(Later, this wiki can be repeatedly refactored and eventually improved
beyond recognition.)

2) This wiki should make "substantial" use of Perl 6. (However, using
some p5 modules initially is OK--after all, Perl 6 is about the
enormous power of ingeniously practical "hybrid vigor".)

3) To aim is to get the first "adequately" working version of this
wiki as soon as "reasonably" possible. (IOW, provide a *minimalist*
but practically usable feature set that doesn't require
not-yet-implemented Perl 6 features.)

4) This wiki software is being primarily developed to initiate the
{primary, principal} "Perl 6 Wikicosm", not to compete with other wiki
implementations. (That comes much later.) This system will eventually
provide a Perl 6 community test bed for many intriguing "extended
wiki" projects. (Some simple-minded examples that might multiply
participation in Perl 6 documentation and testing: putting a "wiki
face" on Perl docs in the svn tree, and providing a "wiki interface"
to update them. Likewise for code examples and build tests. These
might eventually need moderator and limited-scope commit-bit
mechanisms.)

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)




Re: Fwd: Minimum modules for Production?

2006-06-02 Thread Josh Wilmes

At 12:00 on 06/01/2006 BST, David Cantrell <[EMAIL PROTECTED]> wrote:

> Basic I/O is talking to filehandles and nyetwork sockets.  Anything
> above the UDP / TCP level should not, IMO, be included.

I'd respectfully disagree.  Just like text isn't just ascii any more, 
content isn't just on local filesystems.  HTTP has become pretty much 
"basic".

--Josh




Re: Fwd: Minimum modules for Production?

2006-06-02 Thread Michael Mathews

On 01/06/06, Josh Wilmes <[EMAIL PROTECTED]> wrote:

At 12:00 on 06/01/2006 BST, David Cantrell <[EMAIL PROTECTED]> wrote:
> Basic I/O is talking to filehandles and nyetwork sockets.  Anything
> above the UDP / TCP level should not, IMO, be included.
I'd respectfully disagree.  Just like text isn't just ascii any more,
content isn't just on local filesystems.  HTTP has become pretty much
"basic".


I'd respectfully agree with Josh. I know they are different things on
a low level, but, for example, my text-editor of choice hides the fact
that I am editing files on a remote server, or on my local machine --
files is files. I open, I edit, I save. I would also point to PHP's
fread() (and friends) functions, which take "filenames" in the form of
"C:\\blah" or "http://foo.com/blah"; and behaves the same. This way of
thinking, imho, is a Good Thing, and I wouldn't mind seeing it
emulated in Perl6 modules.

--michael


[perl #39255] Revision 12862 fails tests on OS X

2006-06-02 Thread via RT
# New Ticket Created by  Tim Bunce 
# Please include the string:  [perl #39255]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=39255 >


---
osname= darwin
osvers= 8.0
arch=   darwin-thread-multi-2level
cc= cc 
---
Flags:
category=core
severity=critical
ack=no
---

Failed Test Stat Wstat Total Fail  List of Failed
---
t/pmc/mmd.t2   512382  37-38
t/pmc/sub.t1   256491  47


t/pmc/mmdok 33/38
# Failed test (t/pmc/mmd.t at line 1228)
#  got: 'Called wrong multi
# '
# expected: 'Called multi for class
# '
t/pmc/mmdNOK 37
t/pmc/mmdNOK 38# Failed test (t/pmc/mmd.t at 
line 1254)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>) was not found. 
Check the type and number of the arguments
# in file '/Users/timbo/perl/parrot/t/pmc/mmd_38.pir' line 15
# '
# expected: 'String:what
# Int:23
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/mmd_38.pir"' failed 
with exit code 18
# Looks like you failed 2 tests of 38.


t/pmc/subok 37/49
# Failed test (t/pmc/sub.t at line 1178)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>) was not found. 
Check the type and number of the arguments
# in file '/Users/timbo/perl/parrot/t/pmc/sub_47.pir' line 7
# '
# expected: 'ok
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/sub_47.pir"' failed 
with exit code 18


---
Summary of my parrot 0.4.4 (r12862) configuration:
  configdate='Thu Jun  1 16:08:34 2006'
  Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=i386-darwin,
jitosname=DARWIN, jitcpuarch=i386
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-fno-common -no-cpp-precomp -DDEBUGGING  -pipe 
-I/usr/local/include -I/opt/local/include -pipe -fno-common -Wno-long-double ',
  Linker and Libraries:
ld='c++', ldflags=' -L/usr/local/lib -L/opt/local/lib -flat_namespace ',
cc_ldflags='',
libs='-lm'
  Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress',
load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234, 
nv=double, numvalsize=8, doublesize=8

---
Environment:
DYLD_LIBRARY_PATHHOMELANGLANGUAGELD_LIBRARY_PATHLOGDIR  
  PATHPERL5LIBPERLCRITICPERLTIDYSHELL


Re: Minimum modules for Production?

2006-06-02 Thread A. Pagaltzis
* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 12:10]:
> I would also point to PHP's fread() (and friends) functions,
> which take "filenames" in the form of "C:\\blah" or
> "http://foo.com/blah"; and behaves the same.

Yes, which means that any un- (or badly) sanitised user input has
the potential to make a program fetch data from a remote server,
which is particularly dumb when you consider that `require`
offers the same misfeature. Makes exploits so much easier.

No, HTTP is not like opening local files and should not be
treated as such. The failure modes also differ entirely.

The right place to abstract this, if you want to, is at the
networking layer, which could treat local files as a special form
of remote ones, which can be done simply by accepting `file://`
URIs in addition to `http://` and `ftp://`. This way around works
much better for a range of reasons. (I’m too lazy to go into them
right now but will if you ask.)

That doesn’t belong in the language core, though.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;


Re: [perl #39255] Revision 12862 fails tests on OS X

2006-06-02 Thread Will Coleda

Known failures.

Per Leo, failing tests were committed for these features to  
"encourage" development.


We've tried to let head be usable for this long, we should probably  
have some kind of procedure for dealing with this this sort of  
development to avoid this sort of confusion.


Thanks for the report!

On Jun 1, 2006, at 11:56 AM, Tim Bunce (via RT) wrote:


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


---
osname= darwin
osvers= 8.0
arch=   darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=critical
ack=no
---

Failed Test Stat Wstat Total Fail  List of Failed
-- 
-

t/pmc/mmd.t2   512382  37-38
t/pmc/sub.t1   256491  47


t/pmc/mmdok 33/38
# Failed test (t/pmc/mmd.t at line 1228)
#  got: 'Called wrong multi
# '
# expected: 'Called multi for class
# '
t/pmc/mmdNOK 37
t/pmc/mmdNOK 38# Failed test (t/pmc/ 
mmd.t at line 1254)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
was not found. Check the type and number of the arguments

# in file '/Users/timbo/perl/parrot/t/pmc/mmd_38.pir' line 15
# '
# expected: 'String:what
# Int:23
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
mmd_38.pir"' failed with exit code 18

# Looks like you failed 2 tests of 38.


t/pmc/subok 37/49
# Failed test (t/pmc/sub.t at line 1178)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
was not found. Check the type and number of the arguments

# in file '/Users/timbo/perl/parrot/t/pmc/sub_47.pir' line 7
# '
# expected: 'ok
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
sub_47.pir"' failed with exit code 18



---
Summary of my parrot 0.4.4 (r12862) configuration:
  configdate='Thu Jun  1 16:08:34 2006'
  Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=i386-darwin,
jitosname=DARWIN, jitcpuarch=i386
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-fno-common -no-cpp-precomp -DDEBUGGING  - 
pipe -I/usr/local/include -I/opt/local/include -pipe -fno-common - 
Wno-long-double ',

  Linker and Libraries:
ld='c++', ldflags=' -L/usr/local/lib -L/opt/local/lib - 
flat_namespace ',

cc_ldflags='',
libs='-lm'
  Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined  
suppress',

load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8

---
Environment:
DYLD_LIBRARY_PATHHOMELANGLANGUAGE 
LD_LIBRARY_PATHLOGDIRPATHPERL5LIBPERLCRITIC 
PERLTIDYSHELL




--
Will "Coke" Coleda
[EMAIL PROTECTED]




Re: [perl #39254] Unicode sub names don't work with :multi

2006-06-02 Thread Leopold Toetsch
Am Mittwoch, 31. Mai 2006 19:40 schrieb Will Coleda:
>  #39254] Unicode sub names don't work with :multi

As of r12867 this is fixed.
All tests successful again, which means, we need more tests.

leo


Re: Minimum modules for Production?

2006-06-02 Thread Michael Mathews

On 02/06/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 12:10]:
> I would also point to PHP's fread() (and friends) functions,
> which take "filenames" in the form of "C:\\blah" or
> "http://foo.com/blah"; and behaves the same.

Yes, which means that any un- (or badly) sanitised user input has
the potential to make a program fetch data from a remote server,
which is particularly dumb when you consider that `require`
offers the same misfeature. Makes exploits so much easier.

No, HTTP is not like opening local files and should not be
treated as such. The failure modes also differ entirely.

The right place to abstract this, if you want to, is at the
networking layer, which could treat local files as a special form
of remote ones, which can be done simply by accepting `file://`
URIs in addition to `http://` and `ftp://`. This way around works
much better for a range of reasons. (I'm too lazy to go into them
right now but will if you ask.)

That doesn't belong in the language core, though.


That last point is very good argument, but oddly isn't to do with
anything I said (or that I've read in this thread for that matter). I
believe I said "in Perl6 modules" not "in the language core" as you
imply, and I read Josh's post to be about a so-called "core"
*distribution* with network *modules* included, but again, not about
the language core.

The example I gave from PHP was just one example of how "they" do it.
We can abstract it in whatever layer we want, but I think the point
was that accessing files in an increasingly networked world requires
network-smart modules, so some of those should be on the short list
for early porting, at least that was what I was trying to say.

As for writing bad code that is therefore easy to exploit, I wasn't
suggesting that either. I personally advise taint be turned on for ALL
web code, but that's another thread I believe, and this one has
already started to unravel. :-)

--michael


RE: Synchronized / Thread syntax in Perl 6

2006-06-02 Thread Paul Hodges


--- John Drago <[EMAIL PROTECTED]> wrote:
> > You mean "is parallel" as a synonym for "is async"?
> 
> I think "is parallel" denotes something as usable by multiple threads
> simultaneously, "in parallel".
> "is serial" would denote that only one thread can use the $thing at a
> time, exclusively.

Are you saying both are asynchronous, but one specifies that a resource
should be locked rather than duplicated?

> . . .  
> > If $age has been passed to an asynchronous closure, it should be
> > marked as locked, and other threads trying to access it would have
> > to get a lock first. Yes, lots of overhead but that way if the
> > default is WAIT (which seems the smart default to me), the thread
> > waits until TakesForever() releases the resource.

In that light, responding to my own comment, you could infer that you
should lock anything passed by reference, and not worry about it if
passed by value unless you said "$age is locked" or "is serial" or
whatever, yes?

> > if we declare
> > 
> >  our method TakesForever ( int $num is serial ) is async but NOWAIT
> {
> >...
> >  }
> > 
> > or
> > 
> >  my $age = 27 but NOWAIT;
> > 
> > or
> > 
> >  TakesForever( $age but NOWAIT );
> > 
> > (or whatever) then I'd say it should just fail. I mean, isn't that
> kind
> > of the idea, to have that sort of flexibility?
> > 
> 
> Perhaps some more syntax-play is in order here.

lol -- yeah. :)
 
> One thing about threading with Perl5 is that it is easy to write a
> simple threaded program that is entirely opaque - unless you
> wrote the program yourself.
> 
> The program below gets a list of coderefs and executes each one, then
> returns the result.
> #
> (Using the threads.pm way...)
> package QueueRunner;
> 
> use strict;
> use threads;
> use threads::shared;
> 
> sub process_job_queue
> {
>   my ($s, @jobs_in) = @_;
>   my @results : shared = ();
>   my @workers = ();
> 
>   push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
>   $_->join foreach @workers;
>   return @results;
> }# end process_job_queue()
> 
> # Elsewhere...
> package main;
> 
> my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3
> );
> 
> #
> And my attempt at the same, using Perl6: 
> #
> 
> class QueueRunner {
>   our sub process_job_queue( Code @jobs_in ) returns List of Any {
> my Any @results is parallel;
> my Thread @workers = ();
> 
> for @jobs_in {
>   @workers.push( async { &_() } );
> }
> for @workers {
>   @results.push( $_.join() );
> }
> 
> return @results;
>   }# end process_job_queue()
> }# end QueueRunner
> 
> # Elsewhere...
> my @answer = QueueRunner.process_job_queue( @jobs );
> 
> #
> 
> I made absolutely no progress here.  It seems to me that it's no more
> obvious what's going on here than in the Perl5 version.  Any
> comments?
> 
> Regards,
> John Drago

Hm. If we're using *implicit* threads (which I thought was the point),
how about

 class QueueRunner {

   our sub process_queue(Code @jobs_in) {
 my @ans is serial;
 @ans.push map { async { &_() } } @jobs_in;

 @ans;
   }

 }# end QueueRunner

 # Elsewhere...
 my @answer = QueueRunner.process_job_queue( @jobs );

The point is that the call to async() is supposed to handle the thread
management for you, isn't it?

Though if that works, you could squish this example even more, to

 class QueueRunner {

   our sub process_queue(Code @jobs_in) {
   map { async { &_() } } @jobs_in;
   }

 }# end QueueRunner

 # Elsewhere...
 my @answer = QueueRunner.process_job_queue( @jobs );

and the issues of serialization are hidden in the map() call. For all
that

 my @answer = map { async { &_() } } @jobs;

though that gets away from the point.

Someone smack me if I'm drifting too far here?

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: About default options ':ratchet' and ':sigspace' on rules

2006-06-02 Thread Patrick R. Michaud
On Fri, Jun 02, 2006 at 02:17:25PM +0800, Shu-chun Weng wrote:
>  1. Spaces at beginning and end of rule blocks should be ignored
> since space before and after current rule are most likely be
> defined in rules using current one.
>  1a. I'm not sure if it's "clear" to define as this, but the spaces
>  around the rule-level alternative could also be ignored.  

At one point I had been exploring along similar lines, but at the
moment I'd say we don't want to do this.  See below for an example...

>  For instance, look at the rule FunctionAppExpr defined in
>  MiniPerl6 grammar file.
> 
>rule FunctionAppExpr
> {|||[?<'('>?<')'>]?}

FWIW, I'd go ahead and write this as a token statement instead of
a rule:

token FunctionAppExpr {
| 
| 
| 
|  [  \(   \) ]?
}

In fact, now that I've written the above I'm more inclined to say 
it's not a good idea to ignore some whitespace in rule definitions
but not others.  Consider:

rule FunctionAppExpr {
| 
| 
| 
| [ \(  \) ]?
}

Can we quickly determine where the  are being generated? 
What if the [...] portion had an alternation in it?

(And, if we ignore leading/trailing whitespace in rule blocks, do 
we also ignore leading/trailing whitespace in subpatterns?)

In a couple of grammars I've developed already (especially the
one used for pgc.pir), having whitespace at the beginning of rules
and around alternations become  is useful and important.
In these cases, ignoring such whitespace would mean adding explicit
 in the rule to get things to work.  At that point it feels like
waterbed theory -- by "improving" things for the FunctionAppExpr
rule above we're pushing the complexity somewhere else.

In general I'd say that in a production such as FunctionAppExpr
where there are just a few places that need , then it's
better to use 'token' and explicitly indicate the allowed
whitespace.

(Side observation: in  ...|[?<'('>?<')'>]?}
above, there's no whitespace between  and the closing paren.
Why not?)

>  2. I am not sure the default rule of , I couldn't found it in
> S05.  Currently the engine use :P5/\s+/ but I would like it to
> be :P/\s*/ when it's before or after non-words and remains
> the same (\s+) otherwise.

PGE does the "\s* when before or after non-words and \s+ otherwise"
explicitly in its  rule, which is written in PIR.  (Being able
to write subrules procedurally is I nice.)  

In P5 it'd probably be something like 

(?:(?

Re: [perl #39255] Revision 12862 fails tests on OS X

2006-06-02 Thread Will Coleda

Per leo, "As of r12867 this is fixed."

On Jun 2, 2006, at 8:24 AM, Will Coleda wrote:


Known failures.

Per Leo, failing tests were committed for these features to  
"encourage" development.


We've tried to let head be usable for this long, we should probably  
have some kind of procedure for dealing with this this sort of  
development to avoid this sort of confusion.


Thanks for the report!

On Jun 1, 2006, at 11:56 AM, Tim Bunce (via RT) wrote:


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


---
osname= darwin
osvers= 8.0
arch=   darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=critical
ack=no
---

Failed Test Stat Wstat Total Fail  List of Failed
- 
--

t/pmc/mmd.t2   512382  37-38
t/pmc/sub.t1   256491  47


t/pmc/mmdok 33/38
# Failed test (t/pmc/mmd.t at line 1228)
#  got: 'Called wrong multi
# '
# expected: 'Called multi for class
# '
t/pmc/mmdNOK 37
t/pmc/mmdNOK 38# Failed test (t/ 
pmc/mmd.t at line 1254)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
was not found. Check the type and number of the arguments

# in file '/Users/timbo/perl/parrot/t/pmc/mmd_38.pir' line 15
# '
# expected: 'String:what
# Int:23
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
mmd_38.pir"' failed with exit code 18

# Looks like you failed 2 tests of 38.


t/pmc/subok 37/49
# Failed test (t/pmc/sub.t at line 1178)
#  got: 'error:imcc:The opcode 'invokecc_' (invokecc<1>)  
was not found. Check the type and number of the arguments

# in file '/Users/timbo/perl/parrot/t/pmc/sub_47.pir' line 7
# '
# expected: 'ok
# '
# './parrot  --gc-debug "/Users/timbo/perl/parrot/t/pmc/ 
sub_47.pir"' failed with exit code 18



---
Summary of my parrot 0.4.4 (r12862) configuration:
  configdate='Thu Jun  1 16:08:34 2006'
  Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=i386-darwin,
jitosname=DARWIN, jitcpuarch=i386
execcapable=1
perl=perl
  Compiler:
cc='cc', ccflags='-fno-common -no-cpp-precomp -DDEBUGGING  - 
pipe -I/usr/local/include -I/opt/local/include -pipe -fno-common - 
Wno-long-double ',

  Linker and Libraries:
ld='c++', ldflags=' -L/usr/local/lib -L/opt/local/lib - 
flat_namespace ',

cc_ldflags='',
libs='-lm'
  Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined  
suppress',

load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8

---
Environment:
DYLD_LIBRARY_PATHHOMELANGLANGUAGE 
LD_LIBRARY_PATHLOGDIRPATHPERL5LIBPERLCRITIC 
PERLTIDYSHELL




--
Will "Coke" Coleda
[EMAIL PROTECTED]





--
Will "Coke" Coleda
[EMAIL PROTECTED]




Re: Minimum modules for Production?

2006-06-02 Thread Graham Barr


On Jun 1, 2006, at 11:37 AM, Josh Wilmes wrote:



At 12:00 on 06/01/2006 BST, David Cantrell <[EMAIL PROTECTED]>  
wrote:



Basic I/O is talking to filehandles and nyetwork sockets.  Anything
above the UDP / TCP level should not, IMO, be included.


I agree.


I'd respectfully disagree.  Just like text isn't just ascii any more,
content isn't just on local filesystems.  HTTP has become pretty much
"basic".


If you use it. When my work involved a lot of internet related stuff  
I would have agreed. But with the work I do now my use of HTTP with  
perl is at 0%.


Everyone has a bias in their own thoughts of what the minimum is.  
"basic" should only be the common subset of them.


Graham.



Re: Minimum modules for Production?

2006-06-02 Thread A. Pagaltzis
* Michael Mathews <[EMAIL PROTECTED]> [2006-06-02 15:25]:
> I believe I said "in Perl6 modules" not "in the language core"
> as you imply

My apologies; I misremembered the argument, and the PHP example
you gave only happened to reinforce my misconception.

I agree then; having clients for a few network protocols in the
core distro seems very important to me as well. (Since we’re on
that, I would also say that having some kind of very lightweight
XML writer, at minimum, is a necessity nowadays.)

> As for writing bad code that is therefore easy to exploit, I
> wasn't suggesting that either. I personally advise taint be
> turned on for ALL web code, but that's another thread I
> believe, and this one has already started to unravel. :-)

Well yes, failure to validate input is obviously the programmer’s
fault. However, the more implicit magic an API provides, the more
dangerous it is, and the more care is necessary when validating
data to be given to it. This is why IO::All gives me the willies,
f.ex., even as I understand and agree with Ingy’s motivations at
large. I haven’t used two-argument `open` in Perl either since
the three-argument form became available. Go look at what Dan
Bernstein says about APIs…

Regards,
-- 
Aristotle Pagaltzis // 


RE: Synchronized / Thread syntax in Perl 6

2006-06-02 Thread John Drago
> > > You mean "is parallel" as a synonym for "is async"?
> >
> > I think "is parallel" denotes something as usable by multiple threads
> > simultaneously, "in parallel".
> > "is serial" would denote that only one thread can use the $thing at a
> > time, exclusively.
> 
> Are you saying both are asynchronous, but one specifies that a resource
> should be locked rather than duplicated?
> 
> > . . .
> > > If $age has been passed to an asynchronous closure, it should be
> > > marked as locked, and other threads trying to access it would have
> > > to get a lock first. Yes, lots of overhead but that way if the
> > > default is WAIT (which seems the smart default to me), the thread
> > > waits until TakesForever() releases the resource.
> 
> In that light, responding to my own comment, you could infer that you
> should lock anything passed by reference, and not worry about it if
> passed by value unless you said "$age is locked" or "is serial" or
> whatever, yes?


Correct - since only references can affect their originator (or whatever you 
call it).
Modifying something passed by value would be exempt.

> 
> > > if we declare
> > >
> > >  our method TakesForever ( int $num is serial ) is async but NOWAIT
> > {
> > >...
> > >  }
> > >
> > > or
> > >
> > >  my $age = 27 but NOWAIT;
> > >
> > > or
> > >
> > >  TakesForever( $age but NOWAIT );
> > >
> > > (or whatever) then I'd say it should just fail. I mean, isn't that
> > kind
> > > of the idea, to have that sort of flexibility?
> > >
> >
> > Perhaps some more syntax-play is in order here.
> 
> lol -- yeah. :)
> 
> > One thing about threading with Perl5 is that it is easy to write a
> > simple threaded program that is entirely opaque - unless you
> > wrote the program yourself.
> >
> > The program below gets a list of coderefs and executes each one, then
> > returns the result.
> > #
> > (Using the threads.pm way...)
> > package QueueRunner;
> >
> > use strict;
> > use threads;
> > use threads::shared;
> >
> > sub process_job_queue
> > {
> >   my ($s, @jobs_in) = @_;
> >   my @results : shared = ();
> >   my @workers = ();
> >
> >   push @workers, async { push( @results, $_->() ) } foreach @jobs_in;
> >   $_->join foreach @workers;
> >   return @results;
> > }# end process_job_queue()
> >
> > # Elsewhere...
> > package main;
> >
> > my @answer = QueueRunner->process_job_queue( \&job1, \&job2, \&job3
> > );
> >
> > #
> > And my attempt at the same, using Perl6:
> > #
> >
> > class QueueRunner {
> >   our sub process_job_queue( Code @jobs_in ) returns List of Any {
> > my Any @results is parallel;
> > my Thread @workers = ();
> >
> > for @jobs_in {
> >   @workers.push( async { &_() } );
> > }
> > for @workers {
> >   @results.push( $_.join() );
> > }
> >
> > return @results;
> >   }# end process_job_queue()
> > }# end QueueRunner
> >
> > # Elsewhere...
> > my @answer = QueueRunner.process_job_queue( @jobs );
> >
> > #
> >
> > I made absolutely no progress here.  It seems to me that it's no more
> > obvious what's going on here than in the Perl5 version.  Any
> > comments?
> >
> > Regards,
> > John Drago
> 
> Hm. If we're using *implicit* threads (which I thought was the point),
> how about
> 
>  class QueueRunner {
> 
>our sub process_queue(Code @jobs_in) {
>  my @ans is serial;
>  @ans.push map { async { &_() } } @jobs_in;
> 
>  @ans;
>}
> 
>  }# end QueueRunner
> 
>  # Elsewhere...
>  my @answer = QueueRunner.process_job_queue( @jobs );
> 
> The point is that the call to async() is supposed to handle the thread
> management for you, isn't it?
> 
> Though if that works, you could squish this example even more, to
> 
>  class QueueRunner {
> 
>our sub process_queue(Code @jobs_in) {
>map { async { &_() } } @jobs_in;
>}
> 
>  }# end QueueRunner
> 
>  # Elsewhere...
>  my @answer = QueueRunner.process_job_queue( @jobs );
> 
> and the issues of serialization are hidden in the map() call. For all
> that
> 
>  my @answer = map { async { &_() } } @jobs;
> 
> though that gets away from the point.
> 
> Someone smack me if I'm drifting too far here?
> 


Actually I think you did it just right.  I think that horse is dead now.

So, what about "serial" classes and methods?:

# Does marking this class "is serial" mean it's forced to be a singleton?
class Foo is serial {
  has $.counted = 0;
  our method  Qux {
say($.counted++ ~ " Foo.Qux");
  }
}

# Only one thread may call Bar.Baz() at a time:
class Bar {
  has $.counted = 0;
  our method Baz is serial {
say($.counted++ ~ " Bar.Baz");
  }
}

# ... later ...

my Foo $foo = Foo.new();
my Bar $bar = Bar.new();

# $foo and $bar are implicitly shared with other threads:
for 1..5 {
  async {
is atomic;
$foo.Qux();
$bar.Baz();
  };
}

...wha

Re: Concurrency: hypothetical variables and atomic blocks

2006-06-02 Thread Darren Duncan

At 1:50 PM -0700 6/1/06, Larry Wall wrote:

As for side-effecty ops, many of them can just be a promise to perform
the op later when the transaction is committed, I suspect.


Yes, but it would be important to specify that by the time control is 
returned to whatever invoked the op, that any side effects will have 
been successful as well, or a failure/exception is still thrown. 
What happens in Perl itself and what happens as external side effects 
are tied together from the invoker's point of view as one unit that 
should entirely succeed or entirely fail.  Even if the side-effects 
are put off as late as possible in the transaction, we still need to 
know whether they succeeded or not.


On a related note, if there is some external system used in a 
transaction that can't guarantee a successful rollback on failure, 
then any error returned by the Perl op to its invoker should 
differentiate between whether a failure included a successful 
rollback in the external system, or whether said system is now 
possibly or actually in an inconsistent state, so the invoker knows 
whether or not it should be safe to proceed.  Similarly, if the 
external system can't guarantee successful completion before it 
returns control, the invoker should know that vs when completion is 
guaranteed.


In other words, an invoker of an op should know whether the op is 
ACID compliant in all parts of its operation or not.


-- Darren Duncan


Parroters in Frappr

2006-06-02 Thread Alberto Simões

Hi all,

  Coke suggested to create a map with people working on Parrot.
  Create the map in Frappr.
  The URL is:
http://www.frappr.com/parrotcoders

  Feel free to add yourself

Cheers
Alberto
--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

Avoid strange women and temporary variables.


grammar: difference between rule, token and regex

2006-06-02 Thread Rene Hangstrup Møller

Hi

I am toying around with Parrot and the compiler tools. The documenation 
of Perl 6 grammars that I have been able to find only describe rule. But 
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex 
elements.


Can someone please clarify the difference between these three types, and 
when you should use one or the other?


Kind Regards
Rene H. Møller




Re: grammar: difference between rule, token and regex

2006-06-02 Thread jerry gay

On 6/2/06, Rene Hangstrup Møller <[EMAIL PROTECTED]> wrote:

Hi

I am toying around with Parrot and the compiler tools. The documenation
of Perl 6 grammars that I have been able to find only describe rule. But
the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
elements.

Can someone please clarify the difference between these three types, and
when you should use one or the other?


i'm forwarding this to p6l, as it's a language question and probably
best asked there. that said, the regex/token/rule change is a recent
one, and is documented in S05
(http://dev.perl.org/perl6/doc/design/syn/S05.html)

in particular, see the "Regexes really are regexes now" section, which
describes the differences. also, there are some recent threads on p6l
with regard to this topic, which you may find enlightening. you can
find these via google groups, or some other nntp archive.
~jerry


[perl #39272] failures in languages/tcl/t/cmd_lsort.t

2006-06-02 Thread via RT
# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #39272]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=39272 >


Some of these tests are failing. I can't isolate a small test case,  
but here's the last line of the PIR trace, and the bt from gdb:

   5401 cmp_str I0, P0, P1   I0=0 P0=Object(TclConst)=PMC 
(0xe64198) P1=Object(TclConst)=PMC(0xe64168)


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0023
string_compare (interpreter=0xd003c0, s1=0x3, s2=0x18) at src/ 
string.c:1206
1206return CHARSET_COMPARE(interpreter, s1, s2);
(gdb) bt
#0  string_compare (interpreter=0xd003c0, s1=0x3, s2=0x18) at src/ 
string.c:1206
#1  0x0005f9a8 in mmd_dispatch_i_pp (interpreter=0xd003c0,  
left=0xe64198, right=0xe64168, func_nr=13634064) at src/mmd.c:439
#2  0x0003bdc4 in Parrot_cmp_str_i_p_p (cur_opcode=0xee7524,  
interpreter=0x0) at src/ops/cmp.ops:638
#3  0x0013f208 in runops_slow_core (interpreter=0xd003c0,  
pc=0xee7524) at src/runops_cores.c:149
#4  0x00030ba0 in runops_int (interpreter=0xd003c0, offset=15626944)  
at src/interpreter.c:775
#5  0x0002c948 in runops (interpreter=0xd003c0, offs=3) at src/ 
inter_run.c:81
#6  0x0002cb4c in runops_args (interpreter=0xd003c0, sub=0xd11e30,  
obj=0x2819140, meth=0xd00a10, sig=0x1911f8 "vP", ap=0xb884 "") at  
src/inter_run.c:182
#7  0x0002cc78 in Parrot_runops_fromc_args (interpreter=0xd003c0,  
sub=0x3, sig=0x1911f8 "vP") at src/inter_run.c:276
#8  0x4d98 in main (argc=3, argv=0x0) at compilers/imcc/main.c:681

--
Will "Coke" Coleda
[EMAIL PROTECTED]




RE: Synchronized / Thread syntax in Perl 6

2006-06-02 Thread Paul Hodges
--- John Drago <[EMAIL PROTECTED]> wrote:
. . .
> >  class QueueRunner {
> >our sub process_queue(Code @jobs_in) {
> >  my @ans is serial;
> >  @ans.push map { async { &_() } } @jobs_in;
> >  @ans;
> >}
> >  }
> >  my @answer = QueueRunner.process_job_queue( @jobs );
> 
> Actually I think you did it just right.
> I think that horse is dead now.

LOL!! I'm flattered. =o)

> So, what about "serial" classes and methods?:
> 
> # Does marking this class "is serial" mean it's forced to be a
> singleton?

Hmm I wouldn't think so. You should still be able to spawn object
instances, but I'd say it scopes the lock to the whole class, so that
everything in that container is locked any time anything in the class
in accessed. It's a cheap way to make all shared resources queue up
nicely, if you just want a quick and dirty script instead of something
well streamlined. Kind of like locking at the DB or table level instead
of just the row, but there are times when that's what you need.

. . . 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: grammar: difference between rule, token and regex

2006-06-02 Thread Patrick R. Michaud
On Fri, Jun 02, 2006 at 01:56:55PM -0700, jerry gay wrote:
> On 6/2/06, Rene Hangstrup Møller <[EMAIL PROTECTED]> wrote:
> >I am toying around with Parrot and the compiler tools. The documenation
> >of Perl 6 grammars that I have been able to find only describe rule. But
> >the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex
> >elements.
> >
> >Can someone please clarify the difference between these three types, and
> >when you should use one or the other?
>
> i'm forwarding this to p6l, as it's a language question and probably
> best asked there. that said, the regex/token/rule change is a recent
> one, and is documented in S05
> (http://dev.perl.org/perl6/doc/design/syn/S05.html)

Jerry is correct that S05 is the place to look for information
on this.  But to summarize an answer to your question:

   - a C is a "normal" regular expression

   - a C is a regex with the :ratchet modifier set.  The
 :ratchet modifier disables backtracking by default, so that
 a plain quantifier such as '*' or '+' will greedily match whatever
 it can but won't backtrack if the remainder of the match fails.

   - a C is a regex with both the :ratchet and :sigspace
 modifiers set.  The :sigspace modifier indicates that whitespace
 in the rule should be replaced by a intertoken separator rule
 such as  (a whitespace matching rule).

So,

rule { a* c b+ }

is the same as

token {  a*  c  b+  }

is the same as

regex { : a*: : c : b+:  }


To answer your other question, about when to use each, here are
some rules of thumb (sorry for the pun):

  - If the quantifiers in the rule need to do backtracking, use 'regex'

  - If backtracking isn't needed, use 'token'

  - If the components of the regex can have intertoken separators
between them, use rule (and perhaps define a custom  rule
that matches the language's idea of "intertoken separator").

Here's a quick contrived example to illustrate the difference:

token identifier {  \w* }

token integer { \d+ }

token value {  |  }

token operator { \+ | - | \* | / }

rule expression {  [   ]* }

rule assignment {  \:=  }

The "token" declarations all define regexes that do not match
any whitespace.  Thus,  "abc" is a valid identifier but "   abc "
is not.

The rule declarations, however, allow for whitespace to occur
between each of the elements.  Thus, each of the following
are valid assignments in the above language, as the use of
"rule" tells us where whitespace is allowed in the match:

 b:=3+a*4
 b := 3 + a * 4
 b   :=3   +a*   4

I can come up with more examples if desired, but that's the basics
behind each.

Hope this helps,

Pm


Re: grammar: difference between rule, token and regex

2006-06-02 Thread Rene Hangstrup Møller

Patrick R. Michaud wrote:

Jerry is correct that S05 is the place to look for information
on this.  But to summarize an answer to your question:
  
Thank you very much for the swift and thorough answer. It answered all 
my questions. Your reply was very pedagogical and deserves to go into 
the manual.


Have a nice weekend
/Rene Hangstrup Møller



Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue

2006-06-02 Thread Scott Wang
We are trying to use Devel::Cover module and "cover"
in our regression tests run to generate product code
coverage data. However, we met two big problems:

(1) Lots of our perl test scripts failed in code
coverage run and seems related to B::Deparse and we
got million lines of messages like below in our logs:


Deep recursion on subroutine "B::Deparse::find_scope"
at
../glibc-2.3.4/x86_64/perl/../lib/5.8.8/x86_64-linux-thread-multi/B/Deparse.pm
line 1321.
B::Deparse:….../glibc-2.3.4/x86_64/perl/….../lib/5.8.8/x86_64-linux-thread-multi/B/Deparse.pm:1309
called B::Deparse::find_scope
---

Those failed tests would pass if we did not use
Devel::Cover.

Any clue for these B::Deparse messages will be very
helpful for us.

(2) Because we used Devel::Cover to fully instrument
all our perl scripts and modules of our product in
full regression run, the generated coverage data set
(in cover_db) was very huge. So, when we ran "cover"
to merge coverage data and generate final code
coverage report, "cover" ran out of memory and the
"cover" process was killed in the middle.

Any experience and suggestion on how to deal with
running "cover" to merge huge data set to avoid crash
for running out of memory? I think there must be some
other folks use Devel::Cover in the scale like us, so
we appreciate your information and comments.

Thanks in advance!

Scott

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: Question - (1) Devel:;Cover and B::Deparse issue (2) "cover" and its momory consuming issue

2006-06-02 Thread James E Keenan

Scott Wang wrote:

We are trying to use Devel::Cover module and "cover"
in our regression tests run to generate product code
coverage data. However, we met two big problems:

(1) Lots of our perl test scripts failed in code
coverage run and seems related to B::Deparse and we
got million lines of messages like below in our logs:


Deep recursion on subroutine "B::Deparse::find_scope"
at
../glibc-2.3.4/x86_64/perl/../lib/5.8.8/x86_64-linux-thread-multi/B/Deparse.pm
line 1321.
B::Deparse:….../glibc-2.3.4/x86_64/perl/….../lib/5.8.8/x86_64-linux-thread-multi/B/Deparse.pm:1309
called B::Deparse::find_scope
---

Those failed tests would pass if we did not use
Devel::Cover.




This is on the verge of becoming Frequently Asked.

http://tinyurl.com/o2f4y

http://tinyurl.com/n9ujt

Based on the discussion in the threads in those two links, I suspect 
that Devel::Cover is discovering code that compiles but is slightly not 
right.  You'd have to post samples of the code that's failing for us to 
examine it further.


jimk