Re: [perl #56900] [TODO] more ROADMAP informations

[Carl Mäsak]

Moritz (>):
> Or maybe even enumerate the roadmap entries, and then use these to list
> interdepencies (for example numbers for entries and letters for footnotes).

Were we to do this consistently enough, there's always the added bonus
of writing a simple filter into dot, getting a dependency graph.

 
 

It's always nice to have a "you are here" picture to look at, and Perl
makes this kind of transformation almost trivial.

If more people think this is a good idea, I'll try my hand at hacking
together such a filter.

// Carl

Parrot 0.6.4

[Bernhard Schmalhofer]

Hi,

on behalf of the Parrot team, I'm proud to announce the release of 
Parrot 0.6.4

"St. Vincent Amazon."

Parrot 0.6.4 is available via CPAN, or follow the download
instructions at http://parrotcode.org/source.html.  For those who would 
like to develop on

Parrot, or help develop Parrot itself, we recommend using Subversion on
the source code repository to get the latest and best Parrot code.

Parrot 0.6.4 News:
- Documentation
 + removed a lot of old information from the FAQ
 + improved function level documentation
- Configuration
 + removed the configuration item 'has_gnu_m4'
 + refactored ICU-detection
- Languages
 + ChitChat
   - improved the Smalltalk implementation
 + Pipp
   - renamed Plumhead to Pipp
   - support for a lot of builtin functions.
   - Pipp now uses PHP specific data types.
   - converted from PCT with TGE to PCT with NQP actions
   - improvements in the PCT variant by using optok parsing
   - start of object support
 + pir
   - simple assignments work
 + json
   - added a PCT-based implementation of JSON parsing
 + lolcode
   - improved handling of symbols
   - added support for block handling
   - added support for globals
 + Lua
   - more tests
 + Rakudo
   - updated Range implementation
   - added enums
   - added generic type declarations (::T)
   - added runtime mixing of roles with 'does' and 'but'
   - added generic type declarations
   - fixed handling of implicit lexicals ($_, $!, and $/)
   - fixed implicit method calls on $_
   - improved complex math builtins, added Complex
   - moved many builtins to class Any
   - declaration of lists of variables now work
   - improved test infrastructure
   - 910 additional passing spec tests since last release
   - more convergence with STD.pm grammar
   - added named 0-ary parsing and ops
- Compilers
 + PCT:
   - allowed subroutine and method names to be a PAST tree that 
produces the name

   - Improved lexical handling
- Tools
 + pbc_disassemble renamed from disassemble
- Implementation
 + allowed .macro_const in PIR
 + added the flag :lexid(...) for subroutines
 + made multiple dispatch work for sub types
 + fixed garbage collection bug related to the metadata attached to a 
PMC_EXT structure

 + added a warning when using deprecated opcodes
 + simplified the stacks implementation
 + fixed C++ build
 + improved closure and lexical support
 + improved IMCC register allocator
 + added cache for all runtime-constant strings, reducing memory usage
- Miscellaneous
 + improved OpenGL/GLU/GLUT bindings
 + added a standard profile for Perl::Critic coding standard testing
 + added support for smoke testing with Smolder
 + enabled use of Test::Harness 3.0 if available, but don't require it 
for 'make test'

 + added the executable 'parrot_config' to query Parrot configuration


Many thanks to all our contributors for making this possible, and our 
sponsors
for supporting this project.  Our next scheduled release is August 19th 
2008.


Enjoy!

CPAN-Permissions for Perl 5 Modules

[Bernhard Schmalhofer]

Hi,

for Parrot 0.6.4 following Perl 5 modules were not indexed:

Parrot::Configure::Options::Test::Prepare
Parrot::Pmc2c::PMC::PrintTree
Parrot::Test::Util::Runloop
Parrot::SearchOps

It looks like co-maintainership needs to be given the release managers.

Regards,
 Bernhard

Complex planes

[Moritz Lenz]

Today bacek++ implement complex logarithms in rakudo, and one of the
tests failed because it assumed the result to be on a different complex
plane. (log(-1i) returned 0- 1.5708i, while 0 + 3/2*1i was expected).

Should we standardize on one complex plane (for example -pi <= $c.angle
< pi like Complex.angle does)? Or simply fix the test to be agnostic to
complex planes?

Cheers,
Moritz

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

.parrot_current_rev

[Reini Urban]

The file .parrot_current_rev is missing in the Release, and also the
revision is nowhere
mentioned in any Release Note, not the ChangeLog and not in news.
This is annoying, because you don't know if a particular bugfix is
included or not.

Worse, the logic the set the current revision for svn updates is
wrong. (NotMuch brought this up yesterday on #parrot)
.parrot_current_rev is not updated on a svn up, it is just the cache
for $Parrot::Revision::current,
but the cache is not ensured to be cleared when doing a Configure.pl.
Only a make realclean will
get you a correct revision in bugreports.

Configure should enforce a fresh cache update if there's a .svn subdir
available, otherwise
you'll get false bugreports.
-- 
Reini Urban

[perl #56948] [BUG] .parrot_current_rev broken

[via RT]

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


Forward to RT so a ticket is opened.


-- Forwarded message --
From: Reini Urban <[EMAIL PROTECTED]>
Date: Tue, Jul 15, 2008 at 9:52 AM
Subject: .parrot_current_rev
To: [EMAIL PROTECTED]


The file .parrot_current_rev is missing in the Release, and also the
revision is nowhere
mentioned in any Release Note, not the ChangeLog and not in news.
This is annoying, because you don't know if a particular bugfix is
included or not.

Worse, the logic the set the current revision for svn updates is
wrong. (NotMuch brought this up yesterday on #parrot)
.parrot_current_rev is not updated on a svn up, it is just the cache
for $Parrot::Revision::current,
but the cache is not ensured to be cleared when doing a Configure.pl.
Only a make realclean will
get you a correct revision in bugreports.

Configure should enforce a fresh cache update if there's a .svn subdir
available, otherwise
you'll get false bugreports.
--
Reini Urban



-- 
Will "Coke" Coleda

Re: .parrot_current_rev

[jerry gay]

On Tue, Jul 15, 2008 at 6:52 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> The file .parrot_current_rev is missing in the Release, and also the
> revision is nowhere
> mentioned in any Release Note, not the ChangeLog and not in news.
> This is annoying, because you don't know if a particular bugfix is
> included or not.
>
> Worse, the logic the set the current revision for svn updates is
> wrong. (NotMuch brought this up yesterday on #parrot)
> .parrot_current_rev is not updated on a svn up, it is just the cache
> for $Parrot::Revision::current,
> but the cache is not ensured to be cleared when doing a Configure.pl.
> Only a make realclean will
> get you a correct revision in bugreports.
>
> Configure should enforce a fresh cache update if there's a .svn subdir
> available, otherwise
> you'll get false bugreports.
> --
.parrot_current_rev should be (re)generated every time Configure.pl is
successfully run.
if this is not the current behavior, it's broken.
~jerry

[perl #56948]

[Will Coleda]

Forwarding Jerry's followup to the ticket.


-- Forwarded message --
From: jerry gay <[EMAIL PROTECTED]>
Date: Tue, Jul 15, 2008 at 10:14 AM
Subject: Re: .parrot_current_rev
To: Reini Urban <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


On Tue, Jul 15, 2008 at 6:52 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> The file .parrot_current_rev is missing in the Release, and also the
> revision is nowhere
> mentioned in any Release Note, not the ChangeLog and not in news.
> This is annoying, because you don't know if a particular bugfix is
> included or not.
>
> Worse, the logic the set the current revision for svn updates is
> wrong. (NotMuch brought this up yesterday on #parrot)
> .parrot_current_rev is not updated on a svn up, it is just the cache
> for $Parrot::Revision::current,
> but the cache is not ensured to be cleared when doing a Configure.pl.
> Only a make realclean will
> get you a correct revision in bugreports.
>
> Configure should enforce a fresh cache update if there's a .svn subdir
> available, otherwise
> you'll get false bugreports.
> --
.parrot_current_rev should be (re)generated every time Configure.pl is
successfully run.
if this is not the current behavior, it's broken.
~jerry



-- 
Will "Coke" Coleda

Re: [perl #56948] [BUG] .parrot_current_rev broken

[NotFound]

On Tue, Jul 15, 2008 at 3:58 PM, via RT Will Coleda
<[EMAIL PROTECTED]> wrote:
> -- Forwarded message --
> From: Reini Urban <[EMAIL PROTECTED]>
> Date: Tue, Jul 15, 2008 at 9:52 AM
> Subject: .parrot_current_rev
> To: [EMAIL PROTECTED]

> Worse, the logic the set the current revision for svn updates is
> wrong. (NotMuch brought this up yesterday on #parrot)
> .parrot_current_rev is not updated on a svn up, it is just the cache

The problem was first reported on #parrot by tjh on sunday. We tell it
to just do a make realclean in his automated smoke report system, but
this solves only automated builds case.

And other point: 'parrot_config revision' gives the value obtained
from .parrot_current_rev

-- 
Salu2

[perl #46825] [TODO] [Pir] Fix ResizableBooleanArray C test

[Christoph Otto via RT]

On Wed Oct 24 14:23:23 2007, pcoch wrote:
> In t/pmc/resizeablebooleanarray.t there is the todo item:
> 
> TODO: {
> local $TODO = "this is broken";
> 
> pasm_output_is( <<'CODE', <<'OUTPUT', "clone" );
> 
> Which is to say, fix cloning in ResizableBooleanArrays or fix the test (or
> both?)

It looks like both the test and the code were broken.  The clone test
passes now and the code seems to do right thing as of r29469.
I'm calling it resolved.

[perl #56944] [BUG] integer arithmtics should result in integers

[via RT]

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


Rakudo r29470:
$ ../../parrot perl6.pbc -e 'say (1+1).WHAT'
Num
$ ../../parrot perl6.pbc -e 'say (1*1).WHAT'
Num
$ ../../parrot perl6.pbc -e 'say (1**1).WHAT'
Num

All of these should print Int instead.
(This is a known bug, but as far as I can see it hasn't been in RT)

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

[perl #56558] [PATCH] pdb rename to parrot_pdb

[Reini Urban via RT]

This got warnocked for 0.6.4

rename the debugger, not the disassembler.
-- 
Reini Urban

Re: [perl #55954] [PATCH]: Add 'make smolder_test' target

[Michael Peters]

Michael Peters wrote:
> Here's some more patches to improve things. It adds the following:
> 
>   + require TAP::Harness::Archive 0.10 so we can add extra_properties to our 
> TAP
> archives.
>   + Collect Architecture, Compiler, DEVEL, Optimize, Perl Version, Platform, 
> SVN
> Revision and Version data into our TAP archives as extra_properties.
>   + Add tags to the upload so it's easy to search by architecture, compiler,
> version #, platform and perl version.
>   + After the "make smolder_test" target completes successfully, print a URL
> that the user can visit to see the report

Just checking back in on these patches. It's been a while since I sent them and
I haven't heard any feedback one way or another.

-- 
michael peters

The thing I hate about an argument is that it always interrupts a discussion. -
GK Chesterton

Re: [perl #56948] [BUG] .parrot_current_rev broken

[Tim Heckman]

It may also be relevant that on the Windows box where I
run the smoke tests, my ".svn" directories are actually
"_svn".


http://svn.collab.net/repos/svn/trunk/notes/asp-dot-net-hack.txt

---
tjh



> On Tue, Jul 15, 2008 at 3:58 PM, via RT Will Coleda
> <[EMAIL PROTECTED]> wrote:
>> -- Forwarded message --
>> From: Reini Urban <[EMAIL PROTECTED]>
>> Date: Tue, Jul 15, 2008 at 9:52 AM
>> Subject: .parrot_current_rev
>> To: [EMAIL PROTECTED]
>
>> Worse, the logic the set the current revision for svn updates is wrong.
(NotMuch brought this up yesterday on #parrot)
>> .parrot_current_rev is not updated on a svn up, it is just the cache
>
> The problem was first reported on #parrot by tjh on sunday. We tell it
to just do a make realclean in his automated smoke report system, but
this solves only automated builds case.
>
> And other point: 'parrot_config revision' gives the value obtained from
.parrot_current_rev
>
> --
> Salu2
>

[perl #56562] [PATCH] root.in: add cygwin importlib

[Reini Urban via RT]

Reminder:
This got warnocked for 0.6.4
-- 
Reini Urban

Re: [perl #56558] [PATCH] pdb rename to parrot_pdb

[NotFound]

On Tue, Jul 15, 2008 at 3:58 PM, Reini Urban via RT
<[EMAIL PROTECTED]> wrote:
> This got warnocked for 0.6.4
>
> rename the debugger, not the disassembler.

I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks redundant.

I'll vote for parrot_debug

-- 
Salu2

Re: Parrot 0.6.4

[François Perrad]

Bernhard Schmalhofer a écrit :

Hi,

on behalf of the Parrot team, I'm proud to announce the release of 
Parrot 0.6.4

"St. Vincent Amazon."



As usual, the Windows setup is available on 
http://parrotwin32.sourceforge.net/


François.


Parrot 0.6.4 is available via CPAN, or follow the download
instructions at http://parrotcode.org/source.html.  For those who would 
like to develop on

Parrot, or help develop Parrot itself, we recommend using Subversion on
the source code repository to get the latest and best Parrot code.

Parrot 0.6.4 News:
- Documentation
 + removed a lot of old information from the FAQ
 + improved function level documentation
- Configuration
 + removed the configuration item 'has_gnu_m4'
 + refactored ICU-detection
- Languages
 + ChitChat
   - improved the Smalltalk implementation
 + Pipp
   - renamed Plumhead to Pipp
   - support for a lot of builtin functions.
   - Pipp now uses PHP specific data types.
   - converted from PCT with TGE to PCT with NQP actions
   - improvements in the PCT variant by using optok parsing
   - start of object support
 + pir
   - simple assignments work
 + json
   - added a PCT-based implementation of JSON parsing
 + lolcode
   - improved handling of symbols
   - added support for block handling
   - added support for globals
 + Lua
   - more tests
 + Rakudo
   - updated Range implementation
   - added enums
   - added generic type declarations (::T)
   - added runtime mixing of roles with 'does' and 'but'
   - added generic type declarations
   - fixed handling of implicit lexicals ($_, $!, and $/)
   - fixed implicit method calls on $_
   - improved complex math builtins, added Complex
   - moved many builtins to class Any
   - declaration of lists of variables now work
   - improved test infrastructure
   - 910 additional passing spec tests since last release
   - more convergence with STD.pm grammar
   - added named 0-ary parsing and ops
- Compilers
 + PCT:
   - allowed subroutine and method names to be a PAST tree that produces 
the name

   - Improved lexical handling
- Tools
 + pbc_disassemble renamed from disassemble
- Implementation
 + allowed .macro_const in PIR
 + added the flag :lexid(...) for subroutines
 + made multiple dispatch work for sub types
 + fixed garbage collection bug related to the metadata attached to a 
PMC_EXT structure

 + added a warning when using deprecated opcodes
 + simplified the stacks implementation
 + fixed C++ build
 + improved closure and lexical support
 + improved IMCC register allocator
 + added cache for all runtime-constant strings, reducing memory usage
- Miscellaneous
 + improved OpenGL/GLU/GLUT bindings
 + added a standard profile for Perl::Critic coding standard testing
 + added support for smoke testing with Smolder
 + enabled use of Test::Harness 3.0 if available, but don't require it 
for 'make test'

 + added the executable 'parrot_config' to query Parrot configuration


Many thanks to all our contributors for making this possible, and our 
sponsors
for supporting this project.  Our next scheduled release is August 19th 
2008.


Enjoy!

Re: [perl #51944] [DOCS] Cygwin Readme

[Reini Urban]

Will Coleda via RT schrieb:

On Tue May 13 05:21:32 2008, rurban wrote:

2008/5/13 Andrew Whitworth via RT :

is this ticket (#51944) resolved? I don't see any outstanding todo

items

 here that need to be considered further, and the submitted patch

has

 already been applied. Can we close this, or is this a placeholder

for us

 to further improve cygwin documentation?

The list os build preq's is required.

Well, the tip for smoke to do cpan Test::TAP::HTMLMatrix
could be added. But this should be added in the general README for all
platforms.

Then platform specific is only that pg.t fails due to missing loadlib
exceptions
and that cygwin perl-5.10.0 fails to send the smoke report. perl-5.8.8
works ok.

I'll send that as extra README_cygwin.pod patch.


ENOPATCH. =-)

Can someone with cygwin access go through the README once more so we can
get this ticket closed? Thanks.


Ok, since there's now almost an official parrot package, the updates are 
easy.

Patch attached.

The parrot-0.6.4-1 packages are in the works.
--
Reini Urban
http://phpwiki.org/  http://murbreak.at/
Index: README_cygwin.pod
===
--- README_cygwin.pod	(revision 29483)
+++ README_cygwin.pod	(working copy)
@@ -6,37 +6,66 @@
 
 =head1 SYNOPSIS
 
-Parrot builds out of the box under Cygwin.  Some tweaks are needed for
-different names of dynamic loading of some dll's.
+Parrot builds out of the box under Cygwin. 
+Some tweaks are needed for different names for the ffi to some dll's.
+See L
 
+There are official cygwin parrot packages in preparation. 
+See L
+
+  parrot, libparrot0, libparrot-devel, parrot-perl6, parrot-languages
+
 =head1 Packages
 
-You'll need the following Cygwin packages to build Parrot.
+You'll need the following Cygwin packages to run and build Parrot.
 
-=over 4
+Runtime requirements:
 
-=item gcc
+  libreadline6 ncurses libintl8 libicu38 libgmp3 libgdbm4
 
-=item make
+Optional requirements:
 
-=item perl
+  libglut3 xorg-x11-base xorg-x11-bin-dlls libpq5 openssl
 
-=item subversion
+Build requirements:
 
+  gcc make perl parrot readline libncurses-devel libgmp-devel
+  libgdbm-devel pcre-devel libglut-devel
+
+Optional build requirements:
+
+  libicu-devel openssl-devel 
+
+CPAN packages: 
+
+  L if you want to run the language smoke tests
+  with C.
+
+  L for some APL language tests.
+
+=over 4
+
+=item Cygwin subversion and perl
+
 If you use SVN to get a copy of Parrot, you should use the Cygwin SVN
 and not the TortoiseSVN client to avoid build errors.  Similarly you will
 need Cygwin Perl rather than ActiveState or Strawberry Perl.
 
-=item ICU
+=item icu
 
-This is no official Cygwin package yet.  However, icu4c-3_8 builds out of the
-box on Cygwin.
-
-  http://download.icu-project.org/files/icu4c/3.8/icu4c-3_8-src.tgz
-
 Note that ICU is now optional, you can build Parrot without it,
 by not installing it or asking Parrot to ignore it (C<--without-icu>).
 
+=item SDL
+
+SDL references F, which is only in cygports
+L
+
+=item aio
+
+libaio-devel "Linux-native asynchronous I/O access" is not available
+for cygwin, and as the name says will never be :)
+
 =back
 
 =head1 BUILD
@@ -53,14 +82,12 @@
 
 =item Makefile tuning
 
-rename libparrot.dll to cygparrot.dll, create an interim libparrot.dll.a
+rename libparrot.dll to cygparrot-0-6.dll and create an interim libparrot.dll.a
 
-fix the blib/lib PATH issue
+=item loadlib DLL versioning
 
-=item DLL versioning
+Use cyg*-1.1.dll instead of lib*.so.1.1 names for loadlib, the FFI.
 
-cyg*-1.1.dll instead of lib*.so.1.1
-
 Thanks to the L and the impossibility of file
 hardlinks, windows dll names are versioned, so the loadlib function or the
 various pir's needs more logic.
@@ -89,6 +116,6 @@
 
 =head1 HISTORY
 
-Last updated: 1 June 2008
+Last updated: 15 July 2008
 
 =cut

Re: [perl #56558] [PATCH] pdb rename to parrot_pdb

[Reini Urban]

NotFound schrieb:

On Tue, Jul 15, 2008 at 3:58 PM, Reini Urban via RT
<[EMAIL PROTECTED]> wrote:

This got warnocked for 0.6.4

rename the debugger, not the disassembler.


I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks redundant.

I'll vote for parrot_debug


Note that I listed at 
http://rt.perl.org/rt3/Public/Bug/Display.html?id=56558

the existing conflicts:

pdb, the python debugger and the IBM parallel debugger.

--
Reini Urban
http://phpwiki.org/  http://murbreak.at/

Re: [perl #56948] [BUG] .parrot_current_rev broken

[NotFound]

I fixed the problem in r29488, but I don't have any windows
environment available to test.

-- 
Salu2

[perl #56958] HLL map of ResizablePMCArray

[via RT]

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


Tcl used to rely on this particular HLL mapping working, but it seems
to have vanished at some point. (Forces a workaround in
languages/tcl/runtime/builtin/list.pir)

When creating a new PMC to be used with :slurpy, we should be
respecting HLL mapping here.

Here's a simple failing test case that I think should work, but
currently fails the second test.

# (Test could stand to be converted to use parrot's Test::More)
.sub 'q' :anon :load
  $P1 = subclass 'ResizablePMCArray', 'Foo'
.end

.HLL_map 'ResizablePMCArray', 'Foo'

.sub main :main
  say '1..2'
  elm('a','b','c')
.end

.sub elm
  .param pmc args :slurpy

  $I1 = elements args
  if $I1 == 3 goto ok_1
  print 'not '
ok_1:
  say 'ok 1'

  $S0 = typeof args
  if $S0 == 'Foo' goto ok_2
  print 'not '
ok_2:
  say 'ok 2'
.end

# Local Variables:
#   mode: pir
#   fill-column: 100
# End:
# vim: expandtab shiftwidth=4 ft=pir:



-- 
Will "Coke" Coleda

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

[bernhard]

Author: bernhard
Date: Tue Jul 15 12:47:34 2008
New Revision: 29494

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

Log:
[docs] Add escape sequence \" in double quoted strings.


Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Tue Jul 15 12:47:34 2008
@@ -183,7 +183,7 @@
   \x{h..h}1..8 hex digits
   \u  4 hex digits
   \U  8 hex digits
-  \a, \b, \t, \n, \v, \f, \r, \e, \\
+  \a, \b, \t, \n, \v, \f, \r, \e, \\, \"
 
 =over 4
 

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

[allison]

Author: allison
Date: Tue Jul 15 12:54:30 2008
New Revision: 29495

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

Log:
[pdd] Clarification on literal strings from #parrotsketch meeting.


Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Tue Jul 15 12:54:30 2008
@@ -127,8 +127,9 @@
 =item "double-quoted string constants"
 
 Are delimited by double-quotes (C<">). A C<"> inside a string must be escaped
-by C<\>.  Only 7-bit ASCII is accepted in string constants; to use characters
-outside that range, specify an encoding in the way below.
+by C<\>. The default encoding for a double-quoted string constant is 7-bit
+ASCII, other character sets and encodings must be marked explicitly using a
+charset or encoding flag.
 
 =item <<"heredoc",  <<'heredoc'
 

Re: [perl #56558] [PATCH] pdb rename to parrot_pdb

[NotFound]

>> I don't like the name parrot_pdb. 'parrot Parrot DeBugger' ? Looks
>> redundant.

After some discussion in #parrotsketch, the name parrot_debugger wins.

-- 
Salu2

Re: [perl #56558] [PATCH] pdb rename to parrot_pdb

[NotFound]

> After some discussion in #parrotsketch, the name parrot_debugger wins.

Done in r29496, waiting for comments and fixes before closing the ticket.

-- 
Salu2

encoding vs charset

[Leopold Toetsch]

Hi,

I just saw that and such (too late) at #parrotsketch:

  21:52 < NotFound> So unicode:"\xab" and utf8:unicode:"\xab" is also the same 
result?

In my opinion and (AFAIK still in the implementation) is it that the encoding 
bit of PIR is how the possibly escaped bytes are specifying the codepoint in 
the _scource code_. That codepoint will then belong to some charset. Alas the 
above example is illegal.

The source encoding of that mentioned file t/op/stringu.t is utf8:

:set fenc?
  fileencoding=utf-8

pasm_output_is( <<'CODE', < so   unicode:"«"   and unicode:"\xab"  would produce exactly 
the same result.
21:51 < pmichaud> even down to being the same .pbc output.
21:51 < allison> pmichaud: exactly

The former is a valid char in an UTF8/iso-8859-1 encoded source file and only 
there, while the latter is a single invalid UTF8 char part. How would you 
interpret unicode:"\xab\x65" then?

I think that there is still some confusion between the encoding of source code 
with the desired meaning in the charset and the internal encoding of parrot, 
which might be UCS2 or anything.

my 2 ¢
leo

Re: encoding vs charset

[Patrick R. Michaud]

On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote:
> 21:51 < pmichaud> so   unicode:"«"   and unicode:"\xab"  would produce 
> exactly 
> the same result.
> 21:51 < pmichaud> even down to being the same .pbc output.
> 21:51 < allison> pmichaud: exactly
> 
> The former is a valid char in an UTF8/iso-8859-1 encoded source file and only 
> there, while the latter is a single invalid UTF8 char part. How would you 
> interpret unicode:"\xab\x65" then?

I'd want \xab and \x65 to represent two codepoints, not encoding bytes
for a single codepoint.

Pm

Re: encoding vs charset

[Mark J. Reed]

> unicode:"\ab" is illegal

No way.  "Unicode" "\ab" should represent U+00AB.  I don't care what
the byte-level representation is.  In UTF-8, that's 0xc2 0xab; in
UTF-16BE it's 0x00 00ab; in UTF-32LE it's 0xab 0x00 0x00 0x00.

> I think that there is still some confusion between the encoding of source code
> with the desired meaning in the charset and the internal encoding of parrot,
> which might be UCS2 or anything.

IMESHO, the encoding of the source code should have no bearing on the
interpretation of string literal escape sequences within that source
code.  "\ab" should mean U+00AB no matter whether the surrounding
source code is UTF-8, ISO-8859-1, Big-5, whatever; if the source
language wants to work differently, it's up to its parser to convert.

-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: encoding vs charset

[Leopold Toetsch]

Am Dienstag, 15. Juli 2008 23:35 schrieb Patrick R. Michaud:
> On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote:
> > 21:51 < pmichaud> so   unicode:"«"   and unicode:"\xab"  would produce
> > exactly the same result.
> > 21:51 < pmichaud> even down to being the same .pbc output.
> > 21:51 < allison> pmichaud: exactly
> >
> > The former is a valid char in an UTF8/iso-8859-1 encoded source file and
> > only there, while the latter is a single invalid UTF8 char part. How
> > would you interpret unicode:"\xab\x65" then?
>
> I'd want \xab and \x65 to represent two codepoints, not encoding bytes
> for a single codepoint.

And that shall be the distinguished from:

U+AB65: ꭥ  

by what?

> Pm

leo

Re: encoding vs charset

[NotFound]

On Tue, Jul 15, 2008 at 11:45 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote:

> IMESHO, the encoding of the source code should have no bearing on the
> interpretation of string literal escape sequences within that source
> code.  "\ab" should mean U+00AB no matter whether the surrounding
> source code is UTF-8, ISO-8859-1, Big-5, whatever; if the source
> language wants to work differently, it's up to its parser to convert.

The HLL source must not be relevant here, if we a reach a clear spec
will be plain easy for hll writers to generate the pir that gives the
result they want and to use the rules for his sources that his
languages imposes or allows.

I think that the "Escaped are always codepoints" is the clean and
consistent approach.

-- 
Salu2

Re: encoding vs charset

[Mark J. Reed]

Uhm, by the fact that they didn't type "\ab65" ?




On 7/15/08, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 15. Juli 2008 23:35 schrieb Patrick R. Michaud:
>> On Tue, Jul 15, 2008 at 11:17:23PM +0200, Leopold Toetsch wrote:
>> > 21:51 < pmichaud> so   unicode:"«"   and unicode:"\xab"  would produce
>> > exactly the same result.
>> > 21:51 < pmichaud> even down to being the same .pbc output.
>> > 21:51 < allison> pmichaud: exactly
>> >
>> > The former is a valid char in an UTF8/iso-8859-1 encoded source file and
>> > only there, while the latter is a single invalid UTF8 char part. How
>> > would you interpret unicode:"\xab\x65" then?
>>
>> I'd want \xab and \x65 to represent two codepoints, not encoding bytes
>> for a single codepoint.
>
> And that shall be the distinguished from:
>
> U+AB65: ꭥ
>
> by what?
>
>> Pm
>
> leo
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <[EMAIL PROTECTED]>

Re: encoding vs charset

[NotFound]

To open another can of worms, I think that we can live without
character set specification. We can stablish that the character set is
always unicode, and to deal only with encodings. Ascii is an encoding
that maps directly to codepoints and only allows 0-127 values.
iso-8859-1 is the same with 0-255 range. Any other 8 bit encoding just
need a translation table. The only point to solve is we need some
special way to work with fixed-8 with no intended character
representation.

-- 
Salu2

Re: encoding vs charset

[Moritz Lenz]

NotFound wrote:
> To open another can of worms, I think that we can live without
> character set specification. We can stablish that the character set is
> always unicode, and to deal only with encodings. 

We had that discussion already, and the answer was "no" for several reasons:
* Strings might contain binary data, it doesn't make sense to view them
as Unicode
* Unicode isn't necessarily universal, or might stop to be so in future.
If a character is not representable in Unicode, and you chose to use
Unicode for everything, you're screwed
* related to the previous point, some other character encodings might
not have a lossless round-trip conversion.

> Ascii is an encoding
> that maps directly to codepoints and only allows 0-127 values.
> iso-8859-1 is the same with 0-255 range. Any other 8 bit encoding just
> need a translation table. The only point to solve is we need some
> special way to work with fixed-8 with no intended character
> representation.

Introducing the "no character set" character set is just a special case
of arbitrary character sets. I see no point in using the special case
over the generic one.

Here's the discussion we had on this subject:
http://irclog.perlgeek.de/parrot/2008-06-23#i_362697

Cheers,
Moritz

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

Re: encoding vs charset

[NotFound]

> * Unicode isn't necessarily universal, or might stop to be so in future.
> If a character is not representable in Unicode, and you chose to use
> Unicode for everything, you're screwed

There are provision for private usage codepoints.

> * related to the previous point, some other character encodings might
> not have a lossless round-trip conversion.

Did we need that? The intention is that strings are stored in the
format wanted and not recoded without a good reason.

>> need a translation table. The only point to solve is we need some
>> special way to work with fixed-8 with no intended character
>> representation.
> Introducing the "no character set" character set is just a special case
> of arbitrary character sets. I see no point in using the special case
> over the generic one.

Because is special, and we need to deal with his speciality in any
case. Just concatenating it with any other is plain wrong. Just
treating it as iso-8859-1 is not taken in as plain binary at all.

But the main point is that the encoding issues is complicated enough
even inside unicode, and adding another layer of complexity will make
it worse.

-- 
Salu2

Re: encoding vs charset

[Moritz Lenz]

NotFound wrote:
>> * Unicode isn't necessarily universal, or might stop to be so in future.
>> If a character is not representable in Unicode, and you chose to use
>> Unicode for everything, you're screwed
> 
> There are provision for private usage codepoints.

If we use them in parrot, we can't use them in HLLs, right? do we really
want that?

>> * related to the previous point, some other character encodings might
>> not have a lossless round-trip conversion.
> 
> Did we need that? The intention is that strings are stored in the
> format wanted and not recoded without a good reason.

But if you can't work with non-Unicode text strings, you have to convert
them, and in the process you possibly lose information. That's why we
want to enable text strings with non-Unicode semantics.

>>> need a translation table. The only point to solve is we need some
>>> special way to work with fixed-8 with no intended character
>>> representation.
>> Introducing the "no character set" character set is just a special case
>> of arbitrary character sets. I see no point in using the special case
>> over the generic one.
> 
> Because is special, and we need to deal with his speciality in any
> case. Just concatenating it with any other is plain wrong. Just
> treating it as iso-8859-1 is not taken in as plain binary at all.

Just as it is plain wrong to concatenate strings in an two
non-compatible character sets (unless you store the strings as trees,
and have each substring carry both its encoding and charset information.
But then you still can't compare them, for example).

> But the main point is that the encoding issues is complicated enough
> even inside unicode, and adding another layer of complexity will make
> it worse.

I think that distinguishing incompatible character sets is no harder
than distinguishing text and binary strings. It's not another layer,
it's just a layer used in a more general way.

Moritz

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

Re: meta_postfix:<*>

[Dave Whipp]

Jon Lang wrote:

So you're suggesting that

  A op* n

should map to

  [op] A xx n


I don't think that that mapping works for Thomas' proposal of a 
repetition count on post-increment operator. I.e.


  $a ++* 3

is not the same as

  [++] $a xx 3

(which I think is a syntax error)

and also not the same as

  $a++ * 3

Also, he's suggesting getting rid of the "xx" operator, and replacing it 
with ",*" -- I'm sure I could get used to that

[perl #56948] [BUG] .parrot_current_rev broken

[James Keenan via RT]

> 
> -- Forwarded message --
> From: Reini Urban <[EMAIL PROTECTED]>
> Date: Tue, Jul 15, 2008 at 9:52 AM
> Subject: .parrot_current_rev
> To: [EMAIL PROTECTED]
> 
> 
> The file .parrot_current_rev is missing in the Release, and also the
> revision is nowhere
> mentioned in any Release Note, not the ChangeLog and not in news.
> This is annoying, because you don't know if a particular bugfix is
> included or not.
> 
> Worse, the logic the set the current revision for svn updates is
> wrong. 

No, the logic was correct.  As particle said on #parrot yesterday,
".parrot_current_rev should always reflect the last time you ran 'perl
Configure.pl' successfully."


> .parrot_current_rev is not updated on a svn up, 

Correct:  feature, not bug.  If you want the revision after you've run
'svn up', call 'svn info' or some other subversion command.

> it is just the cache
> for $Parrot::Revision::current,

Correct.

> but the cache is not ensured to be cleared when doing a Configure.pl.
> Only a make realclean will
> get you a correct revision in bugreports.
> 

Some historical perspective is warranted here.  Up until April of this
year Parrot::Revision attempted to be all things to all people.  It
attempted to provide both the SVN revision at which you last configured.
 It also attempted to the SVN revision resulting from any 'svn up' run
after you last ran Configure.pl.  And it attempted to provide all this
functionality not just for Subversion clients, but for SVK and git as well.

The code was convoluted and a maintenance nightmare.  The only way it
could have been reasonably maintained would have been to recruit someone
who was expert in all three of those VCSes.  (And we weren't even aware
of Win32-related problems such as those described by Tim Heckman
elsewhere in this thread.)

After considerable discussion, we simplified the code in Parrot::Revision:

r26888 | jkeenan | 2008-04-09 21:21:42 -0400 (Wed, 09 Apr 2008) | 5 lines

"Eliminate svk- and git-related code from Parrot::Revision.  Repository
revision number will no longer be available in 'parrot --version'.
Adjustments in other files as needed; eliminate two t/postconfigure/ and
two t/tools/revision tests."

As part of this revision, we created .parrot_current_rev to serve, as
described above, for the SVN revision number at your last run of
Configure.pl.  It is generated by Configure.pl and, like all files
generated by Configure.pl, it was intended to be cleaned via 'make
realclean' rather than 'make clean'.

Since there has been a lot of confusion about this, we/I could probably
have done a better job of documenting all this.  But I do want to stress
that the design of lib/Parrot/Revision.pm was the result of considerable
thought, discussion and negotiation on this list.  I haven't had a
chance to fully assess the changes that have been made in the last two
days, but I would be reluctant to see us return to the maintenance
difficulties we formerly had.

Thank you very much.
kid51

Re: meta_postfix:<*>

[Jon Lang]

Dave Whipp wrote:

> Jon Lang wrote:
>
>> So you're suggesting that
>>
>>  A op* n
>>
>> should map to
>>
>>  [op] A xx n
>>
>
> I don't think that that mapping works for Thomas' proposal of a repetition
> count on post-increment operator. I.e.
>
>  $a ++* 3
>
> is not the same as
>
>  [++] $a xx 3
>
> (which I think is a syntax error)


It is.


> Also, he's suggesting getting rid of the "xx" operator, and replacing it
> with ",*" -- I'm sure I could get used to that
>

Currently, it's being assumed that the repetition meta-operator will be
appended to the operator, followed by the repetition count:

  $value op* $count

This makes it difficult to apply the replication meta-operator to a prefix
operator.  However, a second option could be provided, where the
meta-operator gets prepended:

  $count *op $value

So:

  5 *, $n === $n ,* 5 === $n, $n, $n, $n, $n
  $n ++* 5 === $n++)++)++)++)++
  5 *++ $n === ++(++(++(++(++$n

And obviously the metaoperator is nonsensical when applied to a binary
operator with different types of values on its left and right sides.

As with other meta-operators, it should be possible to explicitly define a
symbol that would otherwise be interpreted as a meta'd operator, because of
efficiency; because the operator in question has capabilities above and
beyond what the meta-operator would indicate; or because the operator in
question doesn't bear any resemblance to the replicated use of a shorter
operator.  In particular, ** would be overloaded in this manner: to make
reasonable sense, the count of a repetition meta-operator must be an
unsigned integer of some sort, whereas exponents can be any type of number.
Heck, they don't even have to be real.

-- 
Jonathan "Dataweaver" Lang

[perl #56928] [TODO]: Remove config step auto::pack

[James Keenan via RT]

Applied in r29499.  Marking ticket resolved.

[perl #56928] [TODO]: Remove config step auto::pack

[James Keenan via RT]

Applied in r29499.  Marking ticket resolved.

[perl #56008] BUG: t/postconfigure/06-data_slurp_temp.t

[James Keenan via RT]

Since I have not heard back from the OP, have not been able to reproduce
the test failure and have not seen it failing on smoke test reports, I
am going to close this ticket.

Re: CPAN-Permissions for Perl 5 Modules

[James E Keenan]

Bernhard Schmalhofer wrote:

Hi,

for Parrot 0.6.4 following Perl 5 modules were not indexed:

Parrot::Configure::Options::Test::Prepare
Parrot::Pmc2c::PMC::PrintTree


Barney:  I know that I wrote the two modules above (or, at least, 
refactored them into their current form).  What, if anything, should I 
have done when I wrote/committed them.


kid51 (who doesn't understand these indexing issues)

Re: CPAN-Permissions for Perl 5 Modules

[chromatic]

On Tuesday 15 July 2008 17:23:20 James E Keenan wrote:

> Bernhard Schmalhofer wrote:

> > for Parrot 0.6.4 following Perl 5 modules were not indexed:
> >
> > Parrot::Configure::Options::Test::Prepare
> > Parrot::Pmc2c::PMC::PrintTree
>
> Barney:  I know that I wrote the two modules above (or, at least,
> refactored them into their current form).  What, if anything, should I
> have done when I wrote/committed them.

It's only a CPAN indexing issue.  Whenever a release manager uploads a new 
bundle, he or she needs to change permissions for all new indexed modules to 
allow the PARROTRE group to upload new versions.  Unless/until you're a 
release manager yourself, you can safely ignore this.

(The implication is that Bernhard should go into PAUSE right now and check 
that he's not listed as the primary first-come, first-served maintainer for 
any Parrot modules.)

-- c

Re: CPAN-Permissions for Perl 5 Modules

[jerry gay]

i seem to recall that we agreed instead to noindex the Parrot::
modules... Nobody is expected to use them outside parrot anyway.

On 7/15/08, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 15 July 2008 17:23:20 James E Keenan wrote:
>
>> Bernhard Schmalhofer wrote:
>
>> > for Parrot 0.6.4 following Perl 5 modules were not indexed:
>> >
>> > Parrot::Configure::Options::Test::Prepare
>> > Parrot::Pmc2c::PMC::PrintTree
>>
>> Barney:  I know that I wrote the two modules above (or, at least,
>> refactored them into their current form).  What, if anything, should I
>> have done when I wrote/committed them.
>
> It's only a CPAN indexing issue.  Whenever a release manager uploads a new
> bundle, he or she needs to change permissions for all new indexed modules to
> allow the PARROTRE group to upload new versions.  Unless/until you're a
> release manager yourself, you can safely ignore this.
>
> (The implication is that Bernhard should go into PAUSE right now and check
> that he's not listed as the primary first-come, first-served maintainer for
> any Parrot modules.)
>
> -- c
>

-- 
Sent from Gmail for mobile | mobile.google.com

Re: [perl #56948] [BUG] .parrot_current_rev broken

[Tim Heckman]

Seems to be broken as of r29503.

nmake realclean  (.parrot_current_rev is deleted)
svn update
perl Configure.pl

.parrot_current_rev contains "0"


Also, if I run Configure.pl again, the timestamp on the file does not  
change.



--
tjh


On Jul 15, 2008, at 1:26 PM, NotFound wrote:


I fixed the problem in r29488, but I don't have any windows
environment available to test.

--
Salu2

Re: meta_postfix:<*>

[Jon Lang]

Kealey, Martin, wrote:
> Nice idea; introduces one particular ambiguity though: would
>
>  $m ** $n
>
> then be
>
>  pow($m, $n)
>
> or
>
>  pow($n, $m)
>
> ?

Neither.  As with the reducing meta-operator, you would need to have
the ability to define an operator that takes precedence over a meta'd
operator, for those cases where a particular combination of symbols
has a meaning that is either more broad or incompatible with what the
replication meta would supply.  Conveniently, '**' is one such
operator.  To whit:

In '$count *op $value' and '$value op* $count', $count must be an
unsigned integer of some sort: it's nonsense to replicate an operation
half of a time, or negative two times, or i times.  However, '$base **
$power' places no such restrictions on either $base or $power; thus,
it needs to be separately defined.  The fact that its behavior
coincides with a replicator appended to a multiplication operator when
the power is an unsigned integer is merely a convenient coincidence as
far as the compiler is concerned.

That said, there _is_ still some potential ambiguity if you have
operators that begin or end with '*'.  For instance: let's say that
you want to apply replication to exponentials: does '$m *** $n' mean
'$m repetitions of $n ** $n', or does it mean '$m ** $m, repeated $n
times'?  The longest-token rule resolves this dilemma in favor of the
latter.

-- 
Jonathan "Dataweaver" Lang

Re: [perl #56948] [BUG] .parrot_current_rev broken

[Tim Heckman]

For r29488, what I observe (on Windows) is that

 * Configure.pl generates .parrot_current_rev with the correct  
revision number  (but this is broken in r29503 -- see my earlier  
message)


 * Configure.pl does update .parrot_current_rev when the file  
already exists, provided the revision number in the file differs from  
the current actual revision number.


--
tjh



On Jul 15, 2008, at 1:26 PM, NotFound wrote:


I fixed the problem in r29488, but I don't have any windows
environment available to test.

--
Salu2

Re: [perl #56948] [BUG] .parrot_current_rev broken

[Tim Heckman]

Starting in r29489, .parrot_current_rev contains "0" instead of the  
revision number.




--
tjh


On Jul 15, 2008, at 11:23 PM, Tim Heckman wrote:


Seems to be broken as of r29503.

nmake realclean  (.parrot_current_rev is deleted)
svn update
perl Configure.pl

.parrot_current_rev contains "0"


Also, if I run Configure.pl again, the timestamp on the file does  
not change.



--
tjh


On Jul 15, 2008, at 1:26 PM, NotFound wrote:


I fixed the problem in r29488, but I don't have any windows
environment available to test.

--
Salu2

installing pugs on windows xp.. I need to get it working.

[Aruna Goke]

Can somebody give me a working link on how to installs pugs or parrot on
win xp?

I have downloaded from http://jnthn.net/perl6/ both
http://jnthn.net/perl6/pugs-win32.zip
http://jnthn.net/perl6/parrot-win32.zip

after extracting the pugs-win32..
I tried to double-click on pugs.exe but I got the error below.. though
there was first error of no strict.pm which i just copied from my perl
lib directory to resolve that and after that i got the error below

Somebody please give me a guide on how to install it on winxp and fedora
9 ( that give me HsSyck error).

Thanks


goksie

C:\pugs>pugs.exe
   __
 /\   __ \
 \ \  \/\ \ __  __  __  __ (P)erl 6
  \ \   __//\ \/\ \/\  __ \/\  ___\(U)ser's
   \ \  \/ \ \ \_\ \ \ \/\ \ \___  \   (G)olfing
\ \__\  \ \/\ \ \/\_\  (S)ystem
 \/__/   \/___/  \/___/\ \//
   /\/   Version: 6.2.13
   \/___/Copyright 2005-2007, The Pugs Contributors

 Web: http://pugscode.org/   Email: [EMAIL PROTECTED]

Welcome to Pugs -- Perl6 User's Golfing System
Type :h for help.

Can't locate strict.pm in @INC (@INC contains: .) at (eval 1) line 1.
BEGIN failed--compilation aborted at (eval 1) line 1.

Re: [perl #56948] [BUG] .parrot_current_rev broken

[NotFound]

On Wed, Jul 16, 2008 at 1:32 AM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:

>> Worse, the logic the set the current revision for svn updates is
>> wrong.
> No, the logic was correct.  As particle said on #parrot yesterday,
> ".parrot_current_rev should always reflect the last time you ran 'perl
> Configure.pl' successfully."

But it not doed that. It only updated the file if it does not existed,
and it were only deleted on make realclean.

> Since there has been a lot of confusion about this, we/I could probably
> have done a better job of documenting all this.  But I do want to stress
> that the design of lib/Parrot/Revision.pm was the result of considerable
> thought, discussion and negotiation on this list.  I haven't had a
> chance to fully assess the changes that have been made in the last two
> days, but I would be reluctant to see us return to the maintenance
> difficulties we formerly had.

The only changes I do are ensuring that the value is updated at the
start of Configure.pl and a change in the way svn info is parsed.

-- 
Salu2

Re: [perl #51944] [DOCS] Cygwin Readme

[Reini Urban]

2008/7/15 Reini Urban <[EMAIL PROTECTED]>:
> Will Coleda via RT schrieb:
>>
>> On Tue May 13 05:21:32 2008, rurban wrote:
>>>
>>> 2008/5/13 Andrew Whitworth via RT >> [EMAIL PROTECTED]>:

 is this ticket (#51944) resolved? I don't see any outstanding todo
>>>
>>> items

  here that need to be considered further, and the submitted patch
>>>
>>> has

  already been applied. Can we close this, or is this a placeholder
>>>
>>> for us

  to further improve cygwin documentation?
>>>
>>> The list os build preq's is required.
>>>
>>> Well, the tip for smoke to do cpan Test::TAP::HTMLMatrix
>>> could be added. But this should be added in the general README for all
>>> platforms.
>>>
>>> Then platform specific is only that pg.t fails due to missing loadlib
>>> exceptions
>>> and that cygwin perl-5.10.0 fails to send the smoke report. perl-5.8.8
>>> works ok.
>>>
>>> I'll send that as extra README_cygwin.pod patch.
>>
>> ENOPATCH. =-)
>>
>> Can someone with cygwin access go through the README once more so we can
>> get this ticket closed? Thanks.
>
> Ok, since there's now almost an official parrot package, the updates are
> easy.
> Patch attached.
>
> The parrot-0.6.4-1 packages are in the works.

I found a better link for the SDL link.
Yesterday the http://cygwinports.dotsrc.org/ site was down, but now it
is up again.

Please use the attached revised patch instead.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: README_cygwin.pod
===
--- README_cygwin.pod	(revision 29483)
+++ README_cygwin.pod	(working copy)
@@ -6,37 +6,66 @@
 
 =head1 SYNOPSIS
 
-Parrot builds out of the box under Cygwin.  Some tweaks are needed for
-different names of dynamic loading of some dll's.
+Parrot builds out of the box under Cygwin. 
+Some tweaks are needed for different names for the ffi to some dll's.
+See L
 
+There are official cygwin parrot packages in preparation. 
+See L
+
+  parrot, libparrot0, libparrot-devel, parrot-perl6, parrot-languages
+
 =head1 Packages
 
-You'll need the following Cygwin packages to build Parrot.
+You'll need the following Cygwin packages to run and build Parrot.
 
-=over 4
+Runtime requirements:
 
-=item gcc
+  libreadline6 ncurses libintl8 libicu38 libgmp3 libgdbm4
 
-=item make
+Optional requirements:
 
-=item perl
+  libglut3 xorg-x11-base xorg-x11-bin-dlls libpq5 openssl
 
-=item subversion
+Build requirements:
 
+  gcc make perl parrot readline libncurses-devel libgmp-devel
+  libgdbm-devel pcre-devel libglut-devel
+
+Optional build requirements:
+
+  libicu-devel openssl-devel 
+
+CPAN packages:
+
+  L if you want to run the language smoke tests
+  with C.
+
+  L for some APL language tests.
+
+=over 4
+
+=item Cygwin subversion and perl
+
 If you use SVN to get a copy of Parrot, you should use the Cygwin SVN
 and not the TortoiseSVN client to avoid build errors.  Similarly you will
 need Cygwin Perl rather than ActiveState or Strawberry Perl.
 
-=item ICU
+=item icu
 
-This is no official Cygwin package yet.  However, icu4c-3_8 builds out of the
-box on Cygwin.
-
-  http://download.icu-project.org/files/icu4c/3.8/icu4c-3_8-src.tgz
-
 Note that ICU is now optional, you can build Parrot without it,
 by not installing it or asking Parrot to ignore it (C<--without-icu>).
 
+=item SDL
+
+SDL references F, which is only in cygports
+L
+
+=item aio
+
+libaio-devel "Linux-native asynchronous I/O access" is not available
+for cygwin, and as the name says will never be :)
+
 =back
 
 =head1 BUILD
@@ -53,14 +82,12 @@
 
 =item Makefile tuning
 
-rename libparrot.dll to cygparrot.dll, create an interim libparrot.dll.a
+rename libparrot.dll to cygparrot-0-6.dll and create an interim libparrot.dll.a
 
-fix the blib/lib PATH issue
+=item loadlib DLL versioning
 
-=item DLL versioning
+Use cyg*-1.1.dll instead of lib*.so.1.1 names for loadlib, the FFI.
 
-cyg*-1.1.dll instead of lib*.so.1.1
-
 Thanks to the L and the impossibility of file
 hardlinks, windows dll names are versioned, so the loadlib function or the
 various pir's needs more logic.
@@ -89,6 +116,6 @@
 
 =head1 HISTORY
 
-Last updated: 1 June 2008
+Last updated: 15 July 2008
 
 =cut