Re: [perl #56948] [BUG] .parrot_current_rev broken
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
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 bugs-parrot- [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/loadlib DLL versioning +There are official cygwin parrot packages in preparation. +See Lhttp://cygwin.com/ml/cygwin-apps/2008-07/msg00016.html + + 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: + + LTest::TAP::HTMLMatrix if you want to run the language smoke tests + with Cmake languages-smoke. + + LTest::Base 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 FcygSDL-1-2-0.dll, which is only in cygports +Lhttp://cygwinports.dotsrc.org/ + +=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 LWindows DLL Hell / http:// 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: CPAN-Permissions for Perl 5 Modules
chromatic schrieb: https://pause.perl.org/pause/authenqueryI 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. Does this mean that all release managers should be in the PARROTRE group? If so, somebody should check that this is indeed the case. Judging from https://pause.perl.org/pause/authenquery, I'm no member in PARROTRE. (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.) That's what I did right after the upload. But I can change permissions only for new modules, not for modules that weren't indexed. Regards, Bernhard
Re: CPAN-Permissions for Perl 5 Modules
Bernhard Schmalhofer schrieb: Does this mean that all release managers should be in the PARROTRE group? If so, somebody should check that this is indeed the case. Judging from https://pause.perl.org/pause/authenquery, I'm no member in PARROTRE. ** Sorry, I misread https://pause.perl.org/pause/authenquery. It says: * Select Mailinglist/Action *mlrepr Representatives of mailing lists have their special menu here. Only Representatives of mailing lists, not the members, have a special menu there. However it would be nice to see mailing list membership somewhere. Regards, Bernhard
Re: [perl #56558] [PATCH] pdb rename to parrot_pdb
Fixed parrot_debugger test in r29508 -- Salu2
Re: [perl #56948] [BUG] .parrot_current_rev broken
On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman [EMAIL PROTECTED] wrote: Starting in r29489, .parrot_current_rev contains 0 instead of the revision number. I was using a simplified way to call svn info avoiding locale dependencies, and forgot to replace with a more generic way. Fixed in r29509 Don't know if this will work on windows in case of locale dependant svn output, though. -- Salu2
[perl #56948] [BUG] .parrot_current_rev broken
I think this new subroutine could use some refactoring:
30 sub update {
31 my $prev = _get_revision();
32 my $revision = _analyze_sandbox();
33 if (defined ($prev) ($revision ne $prev)) {
34 $revision = 'unknown' unless defined $revision;
35 eval {
36 open my $FH, , $cache;
37 print $FH $revision\n;
38 close $FH;
39 $current = $revision;
40 };
41 }
42 }
Line 39 does not need to be inside the eval{}. If we pull it out, then
we can, and should refactor the eval{} into an internal subroutine, as
it would then exactly match this code farther down:
58 eval {
59 open my $FH, , $cache;
60 print $FH $revision\n;
61 close $FH;
62 };
The control flow here is somewhat awkward and creates additional
branches which will need coverage in testing (cf t/configure/017 and 018):
33 if (defined ($prev) ($revision ne $prev)) {
34 $revision = 'unknown' unless defined $revision;
If no one gets to this today I will try to work on this this evening.
kid51
Re: [perl #56948] [BUG] .parrot_current_rev broken
Confirmed fixed on windows in r29509. -- tjh On Jul 16, 2008, at 5:02 AM, NotFound wrote: On Wed, Jul 16, 2008 at 6:08 AM, Tim Heckman [EMAIL PROTECTED] wrote: Starting in r29489, .parrot_current_rev contains 0 instead of the revision number. I was using a simplified way to call svn info avoiding locale dependencies, and forgot to replace with a more generic way. Fixed in r29509 Don't know if this will work on windows in case of locale dependant svn output, though. -- Salu2
installing pugs on windows xp.. I need to get it working.
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:\pugspugs.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.
[perl #56718] [BUG] Array PMC freeze/thaw/visit broken
On Wed Jul 09 00:04:45 2008, [EMAIL PROTECTED] wrote:
r29183 adds a test to t/pmc/array.t that exposes some brokenness in
the Array
PMC's freeze/thaw code path. I added the test because it looked like
Array's
freeze/thaw/visit code had no test coverage. It turns out that
list_visit
also never gets called (at least according to make cover). I don't
have the
tuits to fix this for now, hence the ticket and the failing test.
To repo, just prove t/pmc/array.t. If everything passes, you win!
(from #ps today)
As a note to whomever fixes this, the sparseness of the Array PMC is its
only remaining useful feature. Fixing freeze/thaw/visit is valuable
because it will make implementing sparseness in
{Fixed|Resizable}{PMC|Integer|Boolean|Float|String}Array easier. Once
those PMCs are sparse, the Array PMC can go away.
[perl #53394] [BUG] Divide-by-zero error in test on Windows
This error hasn't been duplicated in nearly three months, and nobody else has commented on it. I'm marking this one resolved for now. --Andrew Whitworth
[perl #56970] [PATCH] simple match() implementation
# New Ticket Created by Chris Fields # Please include the string: [perl #56970] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56970 Attached is a (very simple) patch for a match() implementation (method version of m//). This version doesn't take modifiers yet; not sure if we should wait until PGE LTM fixes are in. chris match.diff Description: Binary data
[perl #56976] [TODO] implement state variables
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #56976]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56976
State variables need to be implemented, the tests are already there in
S04-declarations/state.t
As a side node (and related to RT #56748), rakudo as of r29490 gives a
bogus error message when encountering a state declaration:
$ ../../parrot perl6.pbc -e 'sub foo { state $x }; 1'
Null PMC access in type()
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #40631] [TODO] add tests for native PMC types
On Mon Feb 13 13:05:01 2006, [EMAIL PROTECTED] wrote: all PMCs (src/pmc/*.pmc) should be tested. the basic types, as defined in PDD17 (docs/pdds/clip/pdd17_basic_types.pod) should be given higher priority, so tests should be developed first to cover these. not surprisingly, basic types have a number of tests already, but there are holes in test coverage that should be plugged. after basic types are well-tested, remaining PMC types distributed in the parrot core should be targeted. this is a job that requires the ability to read c source, and read and write pir and/or pasm test code. however, deep knowledge of these languages is not required. takers most welcome. ~jerry Adding more native PMC tests is a good idea, but this ticket isn't closeable as described. There should be a concrete criteria (or at least a reasonably simple subjective one) for determining when a PMC is sufficiently well-tested. Something based on code coverage (via make cover) would be a good start.
[perl #56968] [PATCH] remove Parrot_warn_s
# New Ticket Created by Andrew Whitworth
# Please include the string: [perl #56968]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56968
I found this today while looking for error-reporting functions. The
function src/warnings.c:Parrot_warn_s is almost completely unused
except in 1 test in t/src/warnings.t. The attached patch removes this
function and the associated test because it's dead code with no
apparent purpose.
On a side note, if people don't want to delete this function for
whatever reason, the function prototype should be changed from
NULLOK_INTERP to PARROT_INTERP, since the first line of the function
tests for the existance of interp and returns an error if it's null.
Better to find a null interp error at compile time then at runtime.
--Andrew Whitworth
Index: src/warnings.c
===
--- src/warnings.c (revision 29495)
+++ src/warnings.c (working copy)
@@ -117,39 +117,6 @@
/*
-=item CINTVAL Parrot_warn_s
-
-The Parrot CSTRING warning/error reporter.
-
-Returns 2 on error, 1 on success.
-
-Cmessage, .. can be a CParrot_vsprintf_s() format with arguments.
-
-=cut
-
-*/
-
-PARROT_API
-INTVAL
-Parrot_warn_s(NULLOK_INTERP, INTVAL warnclass,
- ARGIN(STRING *message), ...)
-{
-if (!interp || !PARROT_WARNINGS_test(interp, warnclass))
-return 2;
-else {
-STRING *targ;
-va_list args;
-
-va_start(args, message);
-targ = Parrot_vsprintf_s(interp, message, args);
-va_end(args);
-
-return print_warning(interp, targ);
-}
-}
-
-/*
-
=back
=head1 SEE ALSO
Index: include/parrot/string_funcs.h
===
--- include/parrot/string_funcs.h (revision 29495)
+++ include/parrot/string_funcs.h (working copy)
@@ -86,6 +86,14 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
+PARROT_CANNOT_RETURN_NULL
+PMC* Parrot_string_split(PARROT_INTERP,
+ARGIN_NULLOK(STRING *delim),
+ARGIN_NULLOK(STRING *str))
+__attribute__nonnull__(1);
+
+PARROT_API
+PARROT_WARN_UNUSED_RESULT
PARROT_CAN_RETURN_NULL
STRING* Parrot_string_trans_charset(PARROT_INTERP,
ARGMOD_NULLOK(STRING *src),
@@ -425,14 +433,6 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CANNOT_RETURN_NULL
-PMC* Parrot_string_split(PARROT_INTERP,
-ARGIN_NULLOK(STRING *delim),
-ARGIN_NULLOK(STRING *str))
-__attribute__nonnull__(1);
-
-PARROT_API
-PARROT_WARN_UNUSED_RESULT
INTVAL string_str_index(PARROT_INTERP,
ARGIN(const STRING *s),
ARGIN(const STRING *s2),
Index: include/parrot/warnings.h
===
--- include/parrot/warnings.h (revision 29495)
+++ include/parrot/warnings.h (working copy)
@@ -65,14 +65,6 @@
__attribute__nonnull__(3);
PARROT_API
-INTVAL Parrot_warn_s(
-NULLOK_INTERP,
-INTVAL warnclass,
-ARGIN(STRING *message),
-...)
-__attribute__nonnull__(3);
-
-PARROT_API
void print_pbc_location(PARROT_INTERP)
__attribute__nonnull__(1);
Index: t/src/warnings.t
===
--- t/src/warnings.t (revision 29495)
+++ t/src/warnings.t (working copy)
@@ -115,84 +115,6 @@
2
OUTPUT
-c_output_is( 'CODE', 'OUTPUT', Parrot_warn_s );
-
-#include parrot/parrot.h
-#include parrot/embed.h
-
-int
-main(int argc, char* argv[])
-{
-Interp *interp;
-int error_val;
-STRING *S;
-
-interp = Parrot_new(NULL);
-if (!interp) {
-return 1;
-}
-PARROT_WARNINGS_on(interp, PARROT_WARNINGS_ALL_FLAG);
-
-S = Parrot_sprintf_c(interp, eek);
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_ALL_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-/* warnings are on, this should return an error */
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_NONE_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_UNDEF_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_IO_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_PLATFORM_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-error_val = Parrot_warn_s(interp, PARROT_WARNINGS_DYNEXT_FLAG, S);
-PIO_eprintf(interp, %d\n, error_val);
-
-#ifndef __cplusplus
-error_val = Parrot_warn_s(interp, 0, eek); /* should return error */
-#else
-/* Fake the result to avoid rewrite the test */
-error_val = 2;
-#endif
-PIO_eprintf(interp, %d\n, error_val);
-
-#ifndef __cplusplus
-error_val = Parrot_warn_s(NULL, 0, eek); /* should return error */
-#else
-/* Fake the result to avoid rewrite the test */
-error_val = 2;
-#endif
-PIO_eprintf(interp, %d\n, error_val);
-
-Parrot_exit(interp, 0);
-
[perl #39669] [TODO] No PIR Compiler Available for Embedded Parrot
Comments on irc confirms the problems are solved. Closing ticket.
Re: [perl #56948] [BUG] .parrot_current_rev broken
I fixed the problem in r29488, but I don't have any windows environment available to test. I just ran a test on XP-Home (using Strawberry Perl) after updating to r29495. Configure.pl creates the file (whether or not it was present), but the value appears to be a constant 0. (Make test and perl6 have no effect.) Is that the desired behavior? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #56948] [BUG] .parrot_current_rev broken
On Wed, Jul 16, 2008 at 12:45 AM, [EMAIL PROTECTED] wrote: I just ran a test on XP-Home (using Strawberry Perl) after updating to r29495. Configure.pl creates the file (whether or not it was present), but the value appears to be a constant 0. (Make test and perl6 have no effect.) Please retest with r29509 The desired behavior is creating the file if not present or his number is outdated, not touching it if the number is already correct. -- Salu2
Re: [perl #56948] [BUG] .parrot_current_rev broken
On Wed, Jul 16, 2008 at 1:12 PM, James Keenan via RT [EMAIL PROTECTED] wrote: I think this new subroutine could use some refactoring: Yes, my goal was to fix the problem as fast as possible, and I'm not very fluent with perl. If no one gets to this today I will try to work on this this evening. Go for it. -- Salu2
Re: encoding vs charset
On Wed, Jul 16, 2008 at 1:13 AM, Moritz Lenz [EMAIL PROTECTED] wrote: 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? I don't understand that point. An HLL can use any codepoint wanted, no matter if there ir a glyph for it in any available font. The way of writing it in the source is not important to parrot, you just need to emit valid pir, create a valid pbc, or whatever. * 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. But the point is precisely that we don't need to take any text as non-Unicode. 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, Yes, and because of that the approach of considering unicode the only character set is simpler. That way the concatenation as text any pair of text strings has no other problem that deciding the destination encoding. 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. And what will be that way? In the current implemenation we have ascii, iso-8859-1 and unicode charsets (not counting binary). Add another charset, and we need a conversion to/from all this. Add another, and sum and multiply. With the unicode and encodings approach, adding any 8-bit or less charset taken as unicode encoding is just adding a table of his 256 corresponding codepoints. -- Salu2
[svn:parrot-pdd] r29522 - in trunk: . compilers/pirc/src docs/book docs/pdds editor languages/PIR/src/pasm lib/Parrot/Ops2pm src/ops src/pmc t/pmc
Author: bernhard Date: Wed Jul 16 08:34:11 2008 New Revision: 29522 Modified: trunk/docs/pdds/pdd22_io.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/PBC_COMPAT trunk/compilers/pirc/src/pirutil.c trunk/docs/book/ch08_reference.pod trunk/editor/pir-mode.el trunk/languages/PIR/src/pasm/pasm_instr.pg trunk/languages/PIR/src/pasm/pasm_io.pg trunk/lib/Parrot/Ops2pm/Utils.pm trunk/src/ops/io.ops trunk/src/ops/ops.num trunk/src/pmc/parrotio.pmc trunk/t/pmc/io.t Log: Merge the changes from branch 'remove_getfd' back into trunk. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podWed Jul 16 08:34:11 2008 @@ -583,13 +583,6 @@ =item * -Cgetfd retrieves the UNIX integer file descriptor of a stream object. -The opcode has been replaced by a 'get_fd' method on the ParrotIO -object. See RT #48310. - - -=item * - Cpioctl provides low-level access to the attributes of a stream object. It takes a stream object, an integer flag to select a command, and a single integer argument for the command. It returns an integer @@ -887,7 +880,7 @@ Currently some of the networking opcodes (Cconnect, Crecv, Csend, Cpoll, Cbind, and Clisten) return an integer indicating the status of the call, -1 or a system error code if unsuccessful. Other I/O -opcodes (such as Cgetfd and Caccept) have various different +opcodes (such as Caccept) have various different strategies for error notification, and others have no way of marking errors at all. We want to unify all I/O opcodes so they use a consistent strategy for error notification.
Re: [perl #51944] [DOCS] Cygwin Readme
On Wed, Jul 16, 2008 at 2:31 AM, Reini Urban via RT [EMAIL PROTECTED] wrote: 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 bugs-parrot- [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/ This looks good; I'd ask you double check which deps are required vs. optional: I'm pretty sure we don't -require- any of those packages. Ditto for their correspond build deps. (e.g. libgdbm-devel) parrot is recursively listed as a build requirement For the optional items, perl's Moose should be on the list (for smartlink), and Test::Perl::Critic/Perl::Critic for the critic tests. (Honestly we should have this documented somewhere else and just refer to it from here.) --- Here are some notes about the build/tests.. ** I get this warning on configure: Determining CPU architecture and OS...done. Determining JIT capability... 10 [main] test 1944 _cygtls::handle_exceptions : Error while dumping state (probably corrupted stack) 10 [main] test 4596 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) ..yes. Generating CPU specific stuff.done. Verifying that the compiler supports function pointer castsyes. ** Get a similar error running t/src/extend.t ** Bug in t/doc/pod.t - few warnings of the type: Error: /cygdrive/d/sandbox/parrot/pbc_to_exe is unreadable: No such file or dire ctory ... But all tests pass. Regards. -- Will Coke Coleda
Re: $foo[0][0] versus $foo[0;0]
On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote: : Hi, : : I'm reviewing the tests in S09, and the file : t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0] : indexing format interchangeably with [0;0]. : : These two formats mean two different things, correct? The [0][0] form isn't : mentioned much in the spec, nor is [0;0] or if they interact somehow. I think they should come out to meaning the same thing, though the [0][0] form may be less efficient if it has to temporarily construct a slice of the next dimension of the array. On the other hand, a naïve implementation of the multidimensional subscripter might just do the same thing internally for the semicolon, so it could be a wash. Larry
Re: Complex planes
On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: : 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? Standardizing on one complex plane is the normal solution, though this being Perl 6, there's probably a better solution using infinite Junctions if we can assume them to be both sufficiently lazy and sufficiently intelligent... :) Larry
Re: meta_postfix:*
On Sun, Jul 13, 2008 at 12:46:30PM +0200, TSa (Thomas Sandlaß) wrote: : HaloO, : : I know that the hot phase of the operator discussions are over. : But here's a little orthogonalizing idea from my side. The observation : is that * can be regarded as repeated addition: 5 * 3 == 5 + 5 + 5 : and ** as repeated multiplication. Now imagine having a meta_postfix:* : that gives +* as multiplication (perhaps abbreviated as *) and ** as : (integer) exponentiation. We can then continue with replication as ~* : for strings and ,* for lists thus freeing x and xx as some generic : multiplication operators. I think this is not going to fly from the standpoint of keeping common operators visually distinct. Also, how will you parse 1..* and such? (Another consideration is that every time you add another metaoperator you're potentially exploding the number of operators that the longest token matcher needs to deal with, though STD currently cheats on this.) : The meta * also is useful e.g. as (1,2) Z* 3 === (1,1,1),(2,2,2). Also : when we apply it to unary postfix as well: $x++* 3 === $x++.++.++ which : is useful when $x is of some class with overloaded ++ where the single : steps are important. The meta postfix * could also be stacked and tetration : falls out naturally as ***. Speaking on behalf of the mere mortal, My Eyes Glaze Over. Speaking as a parser writer, you're confusing the parser with a metaoperator that changes expectation of term vs infix. Sepaking as a programmer, $x++.++.++ won't do what you seem to think it does. : With + as the default case for meta_postfix:* we win the advantage that : we have +* and * as multiplication operators with the latter being a special : form of the former. But for Vectors +* would automatically yield the scalar : multiplication infix:+*:(Vector,Num) when infix:+:(Vector,Vector) is : defined as expected. You can, of course, do anything you like with your own copy, but the standard reserves most of Unicode as the playground of mathematicians, so please leave our poor little * alone. :) Larry
[perl #56998] [TODO] rename cygwin dll to cygparrot$MAJOR_$MINOR_$PATCH.dll
# New Ticket Created by Reini Urban # Please include the string: [perl #56998] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56998 --- osname= cygwin osvers= 1.5.25(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=core severity=medium ack=no --- rename the cygwin dll from libparrot.dll to cygparrot$MAJOR_$MINOR_$PATCH.dll We would have some options for the delimiter from previous experience, . _ or -. . might break some simple scripts - is used in the Xorg package dll's. _ is used in perl5 So I went for _ cyg is the preferred prefix over lib, supported by libtool and makes it visually seperate from a mingw build. Adding _$PATCH also will help in testing multiple versions. cygwin needs the lib in the PATH. Note the seperate ticket http://rt.perl.org/rt3/Ticket/Display.html?id=56562 for the patch to add the importlibrary libparrot.dll.a for cygwin, so that a straight -lparrot is supported. --- Summary of my parrot 0.6.3 (r28667) configuration: configdate='Sun Jul 6 00:26:20 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl5.10.0.exe Compiler: cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT', Linker and Libraries: ld='gcc', ldflags=' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib', cc_ldflags='', libs='-ldl -lcrypt -lgmp -lreadline -lpcre -lglut32 -lglu32 -lopengl32 -lcrypto -lintl' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' 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: CYGWIN =server HOME =/home/rurban LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/usr/src/perl/parrot/parrot-0.6.3-1/build/blib/lib:~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Programme/ATI Technologies/ATI.ACE/Core-Static:/usr/local/bin:/usr/lib/gstreamer-0.8:/usr/lib/lapack SHELL (unset)
Re: [perl #56948] [BUG] .parrot_current_rev broken
The desired behavior is creating the file if not present or his number is outdated, not touching it if the number is already correct. At 29516, that seems to be what it's doing -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
odd (lexical?) issue with Rakudo/Parrot
I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end If I try the following: .sub 'match' :method .param pmc x .local pmc match match = x.ACCEPTS(self); .return (match) .end I run into 'Null PMC access in set_pmc_keyed()' with ACCEPTS (below), which is failing to get the LexPad: .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = self(topic) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end If I simply change match to mimic ACCEPTS, everything works fine. This makes me think something is going on with lexicals, but I'm not quite sure. Am I missing something? chris
[perl #56988] [META] uncloseable tickets in RT
# New Ticket Created by Christoph Otto # Please include the string: [perl #56988] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56988 There are too many tickets in Parrot's queue that aren't concrete about what's needed to close them. I'm adding another one. I'll be going through RT looking for tickets that can't be resolved in their current state. I'll make them children of this ticket to ease tracking. Feel free to jump in anytime. Thanks, Christoph
New packages: parrot-0.6.3-1 with parrot-perl6 and parrot-languages
Hi, The 0.6.3 parrot packages with libparrot0 and libparrot-devel, plus parrot-perl6 and parrot-languages are now available with the Cygwin distribution. Parrot is a virtual machine designed to efficiently compile and execute bytecode for interpreted languages. Parrot is a target for the upcoming Perl 6 and a lot of other languages. .include searchpath: /usr/runtime/parrot/include (bogus) /usr/runtime/parrot (bogus) /usr(bogus) /usr/lib/parrot/include /usr/lib/parrot/ . with the extensions: .exe .lnk .exe.lnk .past .past.exe .past.lnk .past.exe.lnk .pir .pir.exe .pir.lnk .pir.exe.lnk The .exe and .lnk versions are of course cygwin-magic only. Runtime requirements: libparrot0 libreadline6 ncurses libintl8 libicu38 libgmp3 libgdbm4 Optional requirements: libglut3 pcre xorg-x11-base xorg-x11-bin-dlls libpq5 openssl Build requirements: gcc make perl readline libncurses-devel libgmp-devel libgdbm-devel pcre-devel Optional build requirements: libglut-devel libicu-devel openssl-devel Required CPAN packages: Test::TAP::HTMLMatrix if you want to run the language smoke tests with make languages-smoke. Test::Base for some APL language tests. Canonical homepage: http://www.parrotcode.org/ The Parrot wiki is at http://www.perlfoundation.org/parrot/ Canonical download: http://www.parrotcode.org/release/devel Updates appear timely every month until v1.0 at the end of this year due to stable funding. 0.6.4 will be uploaded really soon - tomorrow hopefully, 0.6.5 will be released on 19 Aug 2008. Packaging Details: The php implementation, now called pipp, is here still called plumhead. This will be pipp from the next release 0.6.4 on. parrot-languages is going the single package route, contrary to the fedora split. They have for every single language a seperate package. Otherwise the package layout is similar to fedora, debian, gentoo and freebsd. perl6 is called /usr/bin/perl6.exe, the other languages have a parrot- prefix. There are no perl6 libraries at all included. pdb is called parrot_pdb, and will be named parrot_debugger in the future as voted yesterday - you see the packaging is still a bit in flux :) - disassemble is already called pbc_disassemble. The SDL library references cygSDL-1-2-0.dll per ffi, which is only in cygports: http://cygwinports.dotsrc.org/ /usr/bin/libparrot.dll will be /usr/bin/cygparrot0_6_4.dll for the next version. There are no man(1) pages yet. This is in work. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select Editors or Text and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: [EMAIL PROTECTED] If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: odd (lexical?) issue with Rakudo/Parrot
On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end .ACCEPTS should be calling .match, not vice-versa. Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm
[perl #34452] [TODO] Add return signature to Parrot_call_sub that returns multiple values
Is this still an issue? A quick check of src/embed.c shows that there is no function Parrot_call_sub. Has it been moved to some other location, or is it gone entirely? If it's completely gone, then this ticket is moot and should be closed. --Andrew Whitworth
[perl #34452] [TODO] Add return signature to Parrot_call_sub that returns multiple values
On Wed Jul 16 10:23:50 2008, Whiteknight wrote: Is this still an issue? A quick check of src/embed.c shows that there is no function Parrot_call_sub. Has it been moved to some other location, or is it gone entirely? If it's completely gone, then this ticket is moot and should be closed. --Andrew Whitworth The original ticket said 'extend.c', not 'embed.c', which is where that function still is today. Regards. -- Will Coke Coleda
Re: Complex planes
Larry Wall wrote: On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: : 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? Standardizing on one complex plane is the normal solution, though this being Perl 6, there's probably a better solution using infinite Junctions if we can assume them to be both sufficiently lazy and sufficiently intelligent... :) By the principle of least surprise, I'd recommend against this. Most programmers, when they see 'sqrt(1)', will expect a return value of 1, and won't want to jump through the hurdles involved in picking '1' out of 'any(1, -1)'. That said, I'm not necessarily opposed to these functions including something like an ':any' or ':all' adverb that causes them to return a junction of all possible answers; but this should be something that you have to explicitly ask for. And even then, I'm concerned that it might very quickly get out of hand. Consider: pow(1, 1/pi() ) :any - 1 (I think I got that right...) Since pi is an irrational number, there are infinitely many distinct results to raising 1 to the power of 1/pi. (All but one of them are complex numbers, and all of them have a magnitude of 1, differing only in their angles.) Thus, pow(1, 1/pi() ) :any would have to return a junction of an indefinitely long lazy list. Now subtract 1 from that junction. Do you have to flatten the list in order to do so, subtracting one from each item in the list? Or is there a reasonable way to modify the list generator to incorporate the subtraction? Or how about: sqrt(1):any + sqrt(1):any -- In any case, there's the matter of what to do when you only want one answer, and not a junction of them. IMHO, we should standardize the angles on '-pi ^.. pi'. My reasoning is as follows: if the imaginary component is positive, the angle should be positive; if the imaginary component is negative, the angle should be negative. If the imaginary component is zero and the real component is not negative, the angle should be zero. And the square root of -1 should be i, not -i; so if the imaginary component is zero and the real component is negative, the angle should be positive, not negative. -- Jonathan Dataweaver Lang
Re: [perl #34452] [TODO] Add return signature to Parrot_call_sub that returns multiple values
On Wed, Jul 16, 2008 at 2:51 PM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Jul 16 10:23:50 2008, Whiteknight wrote: Is this still an issue? A quick check of src/embed.c shows that there is no function Parrot_call_sub. Has it been moved to some other location, or is it gone entirely? If it's completely gone, then this ticket is moot and should be closed. --Andrew Whitworth The original ticket said 'extend.c', not 'embed.c', which is where that function still is today. (me reading good)-- Sorry. --Andrew Whitworth
Re: Complex planes
Jon Lang wrote: Larry Wall wrote: On Tue, Jul 15, 2008 at 03:30:24PM +0200, Moritz Lenz wrote: : 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? Standardizing on one complex plane is the normal solution, though this being Perl 6, there's probably a better solution using infinite Junctions if we can assume them to be both sufficiently lazy and sufficiently intelligent... :) By the principle of least surprise, I'd recommend against this. Most programmers, when they see 'sqrt(1)', will expect a return value of 1, And that's what they get unless they write it as sqrt(1 + 0i). and won't want to jump through the hurdles involved in picking '1' out of 'any(1, -1)'. 1 and -1 aren't just separated by a complex plain, they are really distinct numbers That said, I'm not necessarily opposed to these functions including something like an ':any' or ':all' adverb that causes them to return a junction of all possible answers; but this should be something that you have to explicitly ask for. And even then, I'm concerned that it might very quickly get out of hand. Consider: pow(1, 1/pi() ) :any - 1 (I think I got that right...) Not quite. Afaict the only functions that might return a junction are Complex.angle and Complex.log. But having $compl.angle pi always yield True would be quite weird ;-) Since pi is an irrational number, there are infinitely many distinct results to raising 1 to the power of 1/pi. No. exp($x) is a single, well-defined value. (All but one of them are complex numbers, and all of them have a magnitude of 1, differing only in their angles.) Thus, pow(1, 1/pi() ) :any would have to return a junction of an indefinitely long lazy list. Now subtract 1 from that junction. Do you have to flatten the list in order to do so, subtracting one from each item in the list? Obviously we'd have to avoid that if there's any infinite list/junction involved somewhere ;-) But you do have a point that we can't really use infinite junctions unless we can ensure that we can do all sorts of arithmetics with it without loosing lazyness. And I don't think we can prove that (but I might give it it shot if I have some spare time) Or is there a reasonable way to modify the list generator to incorporate the subtraction? Or how about: sqrt(1):any + sqrt(1):any -- In any case, there's the matter of what to do when you only want one answer, and not a junction of them. IMHO, we should standardize the angles on '-pi ^.. pi'. My reasoning is as follows: if the imaginary component is positive, the angle should be positive; if the imaginary component is negative, the angle should be negative. If the imaginary component is zero and the real component is not negative, the angle should be zero. And the square root of -1 should be i, not -i; so if the imaginary component is zero and the real component is negative, the angle should be positive, not negative. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
[perl #56996] [TODO] remove non FHS-compliant searchpaths
# New Ticket Created by Reini Urban # Please include the string: [perl #56996] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56996 --- osname= cygwin osvers= 1.5.25(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=core severity=medium ack=no --- Remove /usr/runtime/parrot/include /usr/runtime/parrot /usr paths from the .include searchpath. I found this out via strace on cygwin. --- Summary of my parrot 0.6.3 (r28667) configuration: configdate='Sun Jul 6 00:26:20 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl5.10.0.exe Compiler: cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT', Linker and Libraries: ld='gcc', ldflags=' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib', cc_ldflags='', libs='-ldl -lcrypt -lgmp -lreadline -lpcre -lglut32 -lglu32 -lopengl32 -lcrypto -lintl' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' 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: CYGWIN =server HOME =/home/rurban LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/usr/src/perl/parrot/parrot-0.6.3-1/build/blib/lib:~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Programme/ATI Technologies/ATI.ACE/Core-Static:/usr/local/bin:/usr/lib/gstreamer-0.8:/usr/lib/lapack SHELL (unset)
[svn:perl6-synopsis] r14563 - doc/trunk/design/syn
Author: larry
Date: Wed Jul 16 12:56:34 2008
New Revision: 14563
Modified:
doc/trunk/design/syn/S04.pod
Log:
[S04] another whack at defining consistent closure semantics
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul 16 12:56:34 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 19 Aug 2004
- Last Modified: 12 July 2008
+ Last Modified: 16 July 2008
Number: 4
- Version: 66
+ Version: 67
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -1253,27 +1253,64 @@
is free to turn unreferenced closures into mere blocks of code.
It is also free to turn referenced closures into mere anonymous
subroutines if the block does not refer to any external lexicals that
-should themselves be cloned. In particular, named subroutines in any
-scope do not consider themselves closures unless you take a reference
-to them. So
+should themselves be cloned. (When we say clone, we mean the way
+the system takes a snapshot of the routine's lexical scope and binds
+it to the current instance of the routine so that if you ever use
+the current reference to the routine, it gets the current snapshot
+of its world in terms of the lexical symbols that are visible to it.)
+
+All remaining blocks are conceptually cloned into closures as soon
+as the lexical scope containing them is entered. (This may be done
+lazily as long as consistent semantics are preserved, so a block
+that is never executed and never has a reference taken can avoid
+cloning altogether. Execution or reference taking forces cloning
+in this case--references are not allowed to be lazily cloned, since
+no guarantee can be made that the scope needed for cloning will
+remain in existence over the life of the reference.)
+
+In particular, named subroutines are a special problem when embedded in
+a changing lexical scope (when they make reference to it). The binding
+of such a definition to a name within a symbol table counts as taking
+a reference, so at compile time there is an initial C::= binding
+to the symbol table entry in question. For global bindings to
+symbol tables visible at compile time, this binds to the compile-time
+view of the lexical scopes. (At run-time, the initial run-time view
+of these scopes is copied from the compiler's view of them, so that
+initializations carry over, for instance.) At run time, whenever such
+a subroutine needs to be cloned, an additional C:= binding is done
+at clone time to the same symbol table entry that the original C::=
+was bound to. (The binding is not restored on exit from the current
+lexical scope; this C:= binding records the Ilast cloning, not
+the currently in-use cloning, so any use of the global reference must
+take into consideration that it is functioning only as a cache of the
+most recent cloning, not as a surrogate for the current lexical scope.)
+
+Lexical names do not share this problem, since the symbol goes out
+of scope synchronously with its usage. Unlike global subs, they
+do not need a compile-time C::= binding, but like global subs,
+they perform a C:= binding to the lexical symbol at clone time
+(again, conceptually at the entry to the outer lexical scope, but
+possible deferred.)
sub foo {
+ # conceptual cloning happens to both blocks below
my $x = 1;
-my sub bar { print $x } # not cloned yet
-my baz = { bar(); print $x }; # cloned immediately
-my $code = bar;# now bar is cloned
+my sub bar { print $x } # already conceptualy cloned, but can
be lazily deferred
+my baz := { bar(); print $x }; # block is cloned immediately, forcing
cloning of bar
+my $code = bar;# this would also force bar to be
cloned
return baz;
}
-When we say clone, we mean the way the system takes a snapshot of the
-routine's lexical scope and binds it to the current instance of the routine
-so that if you ever use the current reference to the routine, it gets
-the current snapshot of its world, lexically speaking. (When we say that
-named subroutines do not consider themselves closures, this is a bit of a
-fib, since we must, in fact, take a reference to the subroutine in order to
-store it into the symbol table! But this operation happens at compile time
-so the lexical scopes in view are just the initial prototype lexical scopes
-visible to the compiler.)
+In particular, blocks of inline control flow need not be cloned until
+called. [Note: this is currently a potential problem for user-defined
+constructs, since you have to take references to blocks to pass them
+to whatever is managing the control flow. Perhaps the laziness can
+be deferred through Captures to binding time, so a slurpy of block
+refs doesn't clone them
Re: Complex planes
Moritz Lenz wrote: Jon Lang wrote: By the principle of least surprise, I'd recommend against this. Most programmers, when they see 'sqrt(1)', will expect a return value of 1, And that's what they get unless they write it as sqrt(1 + 0i). I suppose that you _could_ use the programmer's choice of whether or not to use complex numbers in the argument list as the indicator of whether to return one answer or a junction of them. Of course, this could lead to subtle bugs where the programmer assigns a complex value to $x and later takes the sqrt($x), but forgets that he assigned a complex number earlier. This may or may not be sufficient grounds for requiring an explicit declaration that you want junctions. and won't want to jump through the hurdles involved in picking '1' out of 'any(1, -1)'. 1 and -1 aren't just separated by a complex plane, they are really distinct numbers True enough. I fail to see how that invalidates my point, though: if you're going to mess with multiple complex planes, why wouldn't you also address the issue of distinct numbers as well? The latter issue is intimately connected to the former, as I demonstrate below. And even then, I'm concerned that it might very quickly get out of hand. Consider: pow(1, 1/pi() ) :any - 1 (I think I got that right...) Not quite. Afaict the only functions that might return a junction are Complex.angle and Complex.log. Why is that? Complex numbers can exist on multiple complex planes even if you don't explicitly look at the angle. One example of this phenomenon in action takes the form of a 'proof' that 1 == -1: 1 == sqrt(1) == sqrt(-1 * -1) == sqrt(-1) * sqrt(-1) == i * i == -1 # Assumes complex numbers throughout. The equality between the first and second steps means that the 1 inside the sqrt can only have an angle that is a multiple of 4pi. Because of this, the -1's that appear in the third step cannot exist on the same complex plane with each other: e.g., if the first one has an angle of pi, the second has to have an angle of -pi, 3pi, 7pi, 11pi, ... As a result of this, the signs of the sqrts in the fourth step must be opposed: if the first sqrt(-1) returns i, the second sqrt(-1) must return -i, and vice versa. That means that there's a negative term missing in the fifth step, which would cancel out the negative term that appears in the final step. At the very least, we need to add infix:** and all related functions (e.g., sqrt) to the list of functions that might return a junction. And when and if Perl 6 adds constraint programming to its repertoire, it will have to be smart enough to properly constrain complex planes as well as complex values. -- Bringing this back down a bit closer to Earth: if you supply a complex number using rectilinear coordinates, a case could be made that you've provided insufficient information, and that the complex number ought to be stored as a junction of all of the different complex plane representations for that otherwise-distinct value. If you supply a complex number using polar coordinates, you have been able to supply the choice of complex plane as well as a distinct value; so only one representation should be stored. That is: (1 + 0 * i).angle == any (0, 2 * pi, 4 * pi, ...); exp(0 * i).angle == 0; exp(2 * pi * i).angle == 2 * pi; So: (1 + 0 * i) == any (exp(0), exp(2 * pi * i), exp(4 * pi * i), ...); Extending this further: exp($C) effectively reinterprets a complex number's rectilinear coordinates as polar coordinates, and log($C) does the inverse. So as long as $C contains a single value, exp($C) should always return a complex number that exists on a single complex plane, established by $C's imaginary component; conversely, log($C) ought to return a complex value that is represented on every possible complex plane, since neither the angle nor the magnitude of $C provides enough information to determine which plane to use. Of course, there may be (and probably are) technical difficulties that make this unworkable. Since pi is an irrational number, there are infinitely many distinct results to raising 1 to the power of 1/pi. No. exp($x) is a single, well-defined value. True, as long as $x is a single, well-defined value. But I wasn't talking about exp($x); I was talking about pow($x, $y), $x ** $y, sqrt($x), and so on. Just as: sqrt(1 + 0 * i) == sqrt(any(exp(0), exp(2 * pi * i), exp(4 * pi * i), ...)) == any(exp(0), exp(pi * i), exp(2 * pi * i), ...) it is also the case that: (1 + 0 * i) ** pi == any(exp(0), exp(2 * pi * i), exp(4 * pi * i), ...) ** pi == any(exp(0), exp(2 * pi * pi * i), exp(4 * pi * pi * i), ...) And all of those answers are distinct values. But you do have a point that we can't really use infinite junctions unless we can ensure that we can do all sorts of arithmetics with it without losing laziness. And I don't think we can prove that (but I might give it it shot if I have some spare time) Just noting that we're
[perl #57006] [PATCH] add cygwin opengl config quirks
# New Ticket Created by Reini Urban # Please include the string: [perl #57006] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57006 --- osname= cygwin osvers= 1.5.25(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=core severity=medium ack=no --- Attached patch adds a new cygwin option to Parrot::Configure::Step::Methods::_add_to_libs() to support a cygwin override over the interesting assumption that mingw eq cygwin library wise. And it fixes the opengl compilation on non-existing mingw libs, which is the unfortunate general on cygwin. --- Summary of my parrot 0.6.4 (r0) configuration: configdate='Wed Jul 16 18:18:25 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl.exe Compiler: cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT', Linker and Libraries: ld='gcc', ldflags=' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib', cc_ldflags='', libs='-ldl -lcrypt -lgmp -lreadline -lpcre -lglut -lGLU -lGL -lcrypto -lintl' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' 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: CYGWIN =server HOME =/home/rurban LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/usr/src/perl/parrot/parrot-0.6.3-1/build/blib/lib:~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Programme/ATI Technologies/ATI.ACE/Core-Static:/usr/local/bin:/usr/lib/gstreamer-0.8:/usr/lib/lapack SHELL (unset) difforig config/auto/opengl.pm lib/Parrot/Configure/Step/Methods.pm diff -u config/auto/opengl.pm.orig config/auto/opengl.pm --- config/auto/opengl.pm.orig 2008-06-02 17:35:05.0 + +++ config/auto/opengl.pm 2008-07-16 18:52:29.90625 + @@ -110,10 +110,13 @@ : No details yet -=head3 cygwin +=head3 cygwin/X - : No details yet +Ffreeglut, Flibglut-devel +The mingw packages for native opengl support will also work, +but then you will need the mingw headers and libs +-lglut32 -lglu32 -lopengl32 =cut @@ -166,6 +169,7 @@ win32_gcc = '-lglut32 -lglu32 -lopengl32', win32_nongcc= 'opengl32.lib glu32.lib glut32.lib', darwin = '-framework OpenGL -framework GLUT', + cygwin = '-lglut -lGLU -lGL', default = '-lglut -lGLU -lGL', } ); diff -u lib/Parrot/Configure/Step/Methods.pm.orig lib/Parrot/Configure/Step/Methods.pm --- lib/Parrot/Configure/Step/Methods.pm.orig 2008-06-24 19:59:15.0 + +++ lib/Parrot/Configure/Step/Methods.pm 2008-07-16 19:01:24.078125000 + @@ -119,6 +119,7 @@ cc = $cc, win32_gcc = '-lalpha32 -lalpha32 -lopenalpha32', win32_nongcc= 'alpha.lib', +cygwin = '-lalpha32 -lXalpha32', # optional darwin = 'alphadarwin.lib', default = '-lalpha', } ); @@ -138,6 +139,8 @@ =item * MSWin32 with any C-compiler other than Fgcc. +=item * Cygwin to override Mingw. + =item * Darwin. =back @@ -173,7 +176,7 @@ =item * Cwin32_gcc -Libraries to be added where OS is mswin32 and C-compiler is Fgcc. +Libraries to be added where OS is mswin32 or cygwin and C-compiler is Fgcc. Single whitespace-delimited string. =item * Cwin32_nongcc @@ -181,6 +184,12 @@ Libraries to
[perl #57014] ./perl6 -e '1' gives error and segfaults
# New Ticket Created by Carl Mäsak # Please include the string: [perl #57014] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57014 Both $ ./perl6 -e '1' and $ ../../parrot perl6.pbc -e '1' give the error output Lexical '$expr' not found current instr.: 'parrot;Perl6;Grammar;Actions;statement' pc 137242 (src/gen_actions.pir:14471) called from Sub 'parrot;Perl6::Grammar;statement' pc 25174 (src/gen_grammar.pir:3568) called from Sub 'parrot;Perl6::Grammar;statementlist' pc 21882 (src/gen_grammar.pir:2414) called from Sub 'parrot;Perl6::Grammar;statement_block' pc 19849 (src/gen_grammar.pir:1650) called from Sub 'parrot;Perl6::Grammar;TOP' pc 16121 (src/gen_grammar.pir:224) called from Sub 'parrot;PCT::HLLCompiler;parse' pc 585 (src/PCT/HLLCompiler.pir:371) called from Sub 'parrot;PCT::HLLCompiler;compile' pc 438 (src/PCT/HLLCompiler.pir:303) called from Sub 'parrot;PCT::HLLCompiler;eval' pc 776 (src/PCT/HLLCompiler.pir:473) called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305 (src/PCT/HLLCompiler.pir:708) called from Sub 'parrot;Perl6::Compiler;main' pc 14310 (perl6.pir:172)
[perl #57018] Empty -e argument sends rakudo into REPL mode
# New Ticket Created by Carl Mäsak # Please include the string: [perl #57018] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57018 Both $ ./perl6 -e '' and $ ../../parrot perl6.pbc -e '' send rakudo into REPL mode, whereas $ perl -e '' doesn't.
Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths
On Wed, 2008-07-16 at 10:04 -0700, Reini Urban wrote: Remove /usr/runtime/parrot/include /usr/runtime/parrot /usr paths from the .include searchpath. +1 for not adding these to the searchpath by default. (We shouldn't do something messed up like adding them in one place, and then removing them in another.) -'f
Re: Complex planes
Jon Lang wrote:
Moritz Lenz wrote:
Jon Lang wrote:
By the principle of least surprise, I'd recommend against this. Most
programmers, when they see 'sqrt(1)', will expect a return value of 1,
And that's what they get unless they write it as sqrt(1 + 0i).
I suppose that you _could_ use the programmer's choice of whether or
not to use complex numbers in the argument list as the indicator of
whether to return one answer or a junction of them. Of course, this
could lead to subtle bugs where the programmer assigns a complex value
to $x and later takes the sqrt($x), but forgets that he assigned a
complex number earlier. This may or may not be sufficient grounds for
requiring an explicit declaration that you want junctions.
If the programmer errs on what he thinks is in a variable, it'll always
be a bug.
and won't want to jump through the hurdles involved in picking '1' out
of 'any(1, -1)'.
1 and -1 aren't just separated by a complex plane, they are really
distinct numbers
True enough. I fail to see how that invalidates my point, though: if
you're going to mess with multiple complex planes, why wouldn't you
also address the issue of distinct numbers as well?
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who tries
to debug that code, and doesn't know about junctions. It just won't DTRT.
The latter issue
is intimately connected to the former, as I demonstrate below.
And even then, I'm concerned that it might very quickly get out of
hand. Consider:
pow(1, 1/pi() ) :any - 1
(I think I got that right...)
Not quite. Afaict the only functions that might return a junction are
Complex.angle and Complex.log.
Why is that?
As I pointed out above it's insane to return a junction of logically
distinct values. It might even be insane to do it for Complex.log:
my $a = (Num::e * 1i).log.angle;
What do you expect $a to be?
Let's see, 1i can be written as exp(1i*(1/2 + 2 *$k) * pi), for Int $k.
So log(Nom::e * 1i) would
1 + any(..., -1.5 * pi, 0.5 * pi, 2.5 * pi, 4.5*pi)*1i
if you imagine this, all these values have re = 1, and lie on a straight
line. So their angle are discrete (but not dense) values between -pi and
+pi. There' no way you can represent that in finite space without a fair
bit of algebra, something we don't want to burden on our implementors.
And somehow I also don't think that meets the principle of least
surprise criterion.
I think that I don't have to comment on the rest of the mail to make
clear that Larry's proposal, although being quite interesting, is a very
bad idea to actually implement (and very hard to implement as well)
(unless somebody comes to its rescue with a really clever idea on how to
resolve all these weirdnesses).
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #57018] Empty -e argument sends rakudo into REPL mode
Carl Mäsak (via RT) wrote: Both $ ./perl6 -e '' and $ ../../parrot perl6.pbc -e '' Also -e 0 send rakudo into REPL mode, whereas $ perl -e '' doesn't. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Complex planes
Let's worry about getting principal values, branch cuts and handling signed zeros correct before dealing with the interaction of junctions and multi-valued complex functions. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Complex planes
Moritz Lenz wrote:
If the programmer errs on what he thinks is in a variable, it'll always
be a bug.
Yes; but some bugs are easier to make, and harder to catch, than others.
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who tries
to debug that code, and doesn't know about junctions. It just won't DTRT.
This is closely related to my original point. In particular, if
you're unwilling to have sqrt return junctions of distinct values, you
don't really want to mess with junctions of a single complex value on
different planes, either.
And even then, I'm concerned that it might very quickly get out of
hand. Consider:
pow(1, 1/pi() ) :any - 1
(I think I got that right...)
Not quite. Afaict the only functions that might return a junction are
Complex.angle and Complex.log.
Why is that?
As I pointed out above it's insane to return a junction of logically
distinct values.
It's only insane if the programmer isn't expecting it - which goes
back to my first point of making sure that the programmer explicitly
asked for it before giving it to him.
It might even be insane to do it for Complex.log:
Agreed: if you are uncomfortable with sqrt(1) returning a junction of
distinct values, then Complex.log should likewise not return a
junction of distinct values.
I think that I don't have to comment on the rest of the mail to make
clear that Larry's proposal, although being quite interesting, is a very
bad idea to actually implement (and very hard to implement as well)
(unless somebody comes to its rescue with a really clever idea on how to
resolve all these weirdnesses).
Well... yes and no. Remember, I started off by recommending against
Larry's proposal. I haven't changed my mind, although I think that
it's worth exploring whether or not an alternate treatment of complex
numbers is doable.
--
Jonathan Dataweaver Lang
Re: [svn:perl6-synopsis] r14563 - doc/trunk/design/syn
Minor typo:
On 2008 Jul 16, at 15:56, [EMAIL PROTECTED] wrote:
+(again, conceptually at the entry to the outer lexical scope, but
+possible deferred.)
sub foo {
possibly
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
[svn:perl6-synopsis] r14564 - doc/trunk/design/syn
Author: larry
Date: Wed Jul 16 15:53:34 2008
New Revision: 14564
Modified:
doc/trunk/design/syn/S04.pod
Log:
typo from Brandon++
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Jul 16 15:53:34 2008
@@ -1290,7 +1290,7 @@
do not need a compile-time C::= binding, but like global subs,
they perform a C:= binding to the lexical symbol at clone time
(again, conceptually at the entry to the outer lexical scope, but
-possible deferred.)
+possibly deferred.)
sub foo {
# conceptual cloning happens to both blocks below
Re: Complex planes
It seems like my smiley went completely whoosh... Larry
[perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
# New Ticket Created by James Keenan
# Please include the string: [perl #57026]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57026
r29522 | bernhard | 2008-07-16 11:34:11 -0400 (Wed, 16 Jul 2008) | 2
lines
Merge the changes from branch 'remove_getfd' back into trunk.
This commit has begun causing failures in the build tools tests.
Running 'perl Configure.pl --test' today, I got the failures in the
first attachment:
t/tools/ops2pmutils/08-sort_ops1/?
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/08-sort_ops.t line 78.
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/08-sort_ops.t line 125.
t/tools/ops2pmutils/08-sort_ops33/?
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/08-sort_ops.t line 179.
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/08-sort_ops.t line 313.
# Looks like you failed 4 tests of 86.
t/tools/ops2pmutils/08-sort_ops Dubious, test returned 4 (wstat
1024, 0x400)
Failed 4/86 subtests
t/tools/ops2pmutils/09-prepare_real_ops1/?
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/09-prepare_real_ops.t line 71.
# Failed test 'prepare_real_ops() returned successfully'
# at t/tools/ops2pmutils/09-prepare_real_ops.t line 73.
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/09-prepare_real_ops.t line 146.
# Looks like you failed 3 tests of 38.
t/tools/ops2pmutils/09-prepare_real_ops Dubious, test returned 3 (wstat
768, 0x300)
Failed 3/38 subtests
t/tools/ops2pmutils/10-print_module1/?
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/10-print_module.t line 76.
# Failed test 'prepare_real_ops() returned successfully'
# at t/tools/ops2pmutils/10-print_module.t line 78.
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/10-print_module.t line 132.
# Failed test 'prepare_real_ops() returned successfully'
# at t/tools/ops2pmutils/10-print_module.t line 134.
# Looks like you failed 4 tests of 42.
t/tools/ops2pmutils/10-print_module Dubious, test returned 4 (wstat
1024, 0x400)
Failed 4/42 subtests
t/tools/ops2pmutils/11-print_h.1/?
# Failed test 'sort_ops returned successfully'
# at t/tools/ops2pmutils/11-print_h.t line 74.
# Failed test 'prepare_real_ops() returned successfully'
# at t/tools/ops2pmutils/11-print_h.t line 76.
# Looks like you failed 2 tests of 23.
t/tools/ops2pmutils/11-print_h. Dubious, test returned 2 (wstat
512, 0x200)
Failed 2/23 subtests
t/pharness/01-default_testsok
t/pharness/02-get_test_prog_args...ok
t/pharness/03-handle_long_options..ok
t/pharness/04-Usageok
Test Summary Report
---
t/tools/ops2pmutils/08-sort_ops(Wstat: 1024 Tests: 86 Failed: 4)
Failed tests: 16, 32, 49, 83
Non-zero exit status: 4
t/tools/ops2pmutils/09-prepare_real_ops(Wstat: 768 Tests: 38 Failed: 3)
Failed tests: 16-17, 36
Non-zero exit status: 3
t/tools/ops2pmutils/10-print_module(Wstat: 1024 Tests: 42 Failed: 4)
Failed tests: 16-17, 34-35
Non-zero exit status: 4
t/tools/ops2pmutils/11-print_h (Wstat: 512 Tests: 23 Failed: 2)
Failed tests: 16-17
Non-zero exit status: 2
Files=38, Tests=1009, 24 wallclock secs ( 0.16 usr 0.05 sys + 12.72 cusr 0.77
csys = 13.70 CPU)
Result: FAIL
Failed 4/38 test programs. 13/1009 subtests failed.
Changes made in the 'remove_getfd' branch to lib/Parrot/Ops2c/
Utils.pm are the likely source of these failures. When I reverted to
the last prior revision of that module, all the build tools tests
passed.
[li11-226:parrot] 504 $ svn cat -r {2008-07-13} lib/Parrot/Ops2pm/Utils.pm lib/Parrot/Ops2pm/Utils.pm
[li11-226:parrot] 505 $ make buildtools_tests
/usr/local/bin/perl t/harness t/tools/pmc2cutils/*.t t/tools/ops2pmutils/*.t t/tools/ops2cutils/*.t t/tools/revision/*.t t/pharness/*.t
t/tools/pmc2cutils/00-qualify..ok
t/tools/pmc2cutils/01-pmc2cutils...ok
t/tools/pmc2cutils/02-find_fileok
t/tools/pmc2cutils/03-dump_vtable..ok
t/tools/pmc2cutils/04-dump_pmc.ok
t/tools/pmc2cutils/05-gen_cok
t/tools/pmc2cutils/07-open_fileok
t/tools/pmc2cutils/08-pmc-pm...ok
t/tools/ops2pmutils/00-qualify.ok
t/tools/ops2pmutils/01-ops2pmutils.ok
t/tools/ops2pmutils/02-usage...ok
t/tools/ops2pmutils/03-new.ok
t/tools/ops2pmutils/04-prepare_ops.ok
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed, Jul 16, 2008 at 7:31 PM, via RT James Keenan [EMAIL PROTECTED] wrote: # New Ticket Created by James Keenan # Please include the string: [perl #57026] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57026 r29522 | bernhard | 2008-07-16 11:34:11 -0400 (Wed, 16 Jul 2008) | 2 lines Merge the changes from branch 'remove_getfd' back into trunk. This commit has begun causing failures in the build tools tests. Running 'perl Configure.pl --test' today, I got the failures in the first attachment: t/tools/ops2pmutils/08-sort_ops1/? # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/08-sort_ops.t line 78. # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/08-sort_ops.t line 125. t/tools/ops2pmutils/08-sort_ops33/? # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/08-sort_ops.t line 179. # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/08-sort_ops.t line 313. # Looks like you failed 4 tests of 86. t/tools/ops2pmutils/08-sort_ops Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/86 subtests t/tools/ops2pmutils/09-prepare_real_ops1/? # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/09-prepare_real_ops.t line 71. # Failed test 'prepare_real_ops() returned successfully' # at t/tools/ops2pmutils/09-prepare_real_ops.t line 73. # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/09-prepare_real_ops.t line 146. # Looks like you failed 3 tests of 38. t/tools/ops2pmutils/09-prepare_real_ops Dubious, test returned 3 (wstat 768, 0x300) Failed 3/38 subtests t/tools/ops2pmutils/10-print_module1/? # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/10-print_module.t line 76. # Failed test 'prepare_real_ops() returned successfully' # at t/tools/ops2pmutils/10-print_module.t line 78. # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/10-print_module.t line 132. # Failed test 'prepare_real_ops() returned successfully' # at t/tools/ops2pmutils/10-print_module.t line 134. # Looks like you failed 4 tests of 42. t/tools/ops2pmutils/10-print_module Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/42 subtests t/tools/ops2pmutils/11-print_h.1/? # Failed test 'sort_ops returned successfully' # at t/tools/ops2pmutils/11-print_h.t line 74. # Failed test 'prepare_real_ops() returned successfully' # at t/tools/ops2pmutils/11-print_h.t line 76. # Looks like you failed 2 tests of 23. t/tools/ops2pmutils/11-print_h. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/23 subtests t/pharness/01-default_testsok t/pharness/02-get_test_prog_args...ok t/pharness/03-handle_long_options..ok t/pharness/04-Usageok Test Summary Report --- t/tools/ops2pmutils/08-sort_ops(Wstat: 1024 Tests: 86 Failed: 4) Failed tests: 16, 32, 49, 83 Non-zero exit status: 4 t/tools/ops2pmutils/09-prepare_real_ops(Wstat: 768 Tests: 38 Failed: 3) Failed tests: 16-17, 36 Non-zero exit status: 3 t/tools/ops2pmutils/10-print_module(Wstat: 1024 Tests: 42 Failed: 4) Failed tests: 16-17, 34-35 Non-zero exit status: 4 t/tools/ops2pmutils/11-print_h (Wstat: 512 Tests: 23 Failed: 2) Failed tests: 16-17 Non-zero exit status: 2 Files=38, Tests=1009, 24 wallclock secs ( 0.16 usr 0.05 sys + 12.72 cusr 0.77 csys = 13.70 CPU) Result: FAIL Failed 4/38 test programs. 13/1009 subtests failed. Changes made in the 'remove_getfd' branch to lib/Parrot/Ops2c/ Utils.pm are the likely source of these failures. When I reverted to the last prior revision of that module, all the build tools tests passed. I suspect that the merger/committer failed either to run 'perl Configure.pl --test' or 'make buildtools_tests' prior to 'make'. I can't remember the last time I ran these particular test targets, so that's easy (for me) to forgive. Can someone take a look at this? Thank you very much. kid51 The problem appears to be that at some point explicit return statements were added here, presumably to help follow that perl critic policy. However, they are bare returns, and are not taking advantage of the implicit return value that was originally present. (e.g. in sort_ops in Parrot/Ops2pm/Utils.pm). If the only thing checking for that return value is the tests, then I would recommend eliminating the tests to not bother checking the return value. Looks like the method is setting some internal state; we shouldn't be exposing that state outside our object,
Re: Complex planes
Mark Biggar wrote: Let's worry about getting principal values, branch cuts and handling signed zeros correct before dealing with the interaction of junctions and multi-valued complex functions. Indeed. BTW, two good references on this that we might want to plagiarizer.I mean borrow from are the Ada Refernece Manual and the Common LISP Reference Manual. Both go into great detail on this subject. I've just reviewed the Ada Reference Manual's take on this topic, and it did indeed address a few wrinkles that I overlooked. Basic rule: Complex.modulus = 0; Complex.arg ~~ -pi .. pi. I'm not fully up on the lingo; so I'm going to invent some: Number $x is 'indefinite' if it is defined but has a value of Inf, NaN, or the like. It is 'definite' if it is defined and not indefinite. If either .re or .im is indefinite, the complex number is indefinite. If signed zeroes are used, then a definite complex number can always be assigned to one of the four quadrants. (In particular, if .im == -0, the number falls in one of the lower quadrants, and .arg == -pi or -0, depending on whether .re is negative or positive, respectively; if .im == +0, the number falls in one of the upper quadrants, and .arg == pi or +0. It is impossible for .arg to be indefinite if both .re and .im are definite: complex zeroes are signed by a definite .arg.) Conjecture: signed zeroes should be accompanied by signed infinities: as with zeroes, the sign of a complex infinity is a definite argument. Without signed zeroes, a definite complex number can be assigned to one of the four quadrants, to the positive or negative real number axes, to the positive or negative imaginary number axes, or to the origin. Under this scheme, some modifications and caveats need to be stated: .arg ~~ -pi ^.. pi. (So if the number falls on the negative real number line, .arg == pi.) If the number is zero, .arg is indefinite. If the number is indefinite, .arg is indefinite. If .re is indefinite, then .im is indefinite, and vice versa. The first paradigm has fewer special cases than the second one, but has several redundancies of the same nature as signed zeroes; the second paradigm more closely reflects what a mathematician would expect when seeing a complex number, but has several incongruities that might give a programmer headaches. -- Jonathan Dataweaver Lang
Re: Complex planes
On 2008 Jul 16, at 18:48, Jon Lang wrote:
Moritz Lenz wrote:
Principle of least surprise:
Suppose sqrt(1) returns any(1, -1):
if sqrt($x) 0.5 { do something }
I can see the big, fat WTF written in the face of programmer who
tries
to debug that code, and doesn't know about junctions. It just won't
DTRT.
This is closely related to my original point. In particular, if
you're unwilling to have sqrt return junctions of distinct values, you
don't really want to mess with junctions of a single complex value on
different planes, either.
I suggest that the base library not bother with any of this; if
someone wants it they can load a FullComplex module or something like
that.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
[perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed Jul 16 16:56:20 2008, coke wrote: I suspect that the merger/committer failed either to run 'perl Configure.pl --test' or 'make buildtools_tests' prior to 'make'. I can't remember the last time I ran these particular test targets, so that's easy (for me) to forgive. (Well, I *could* have written these tests such that they would be included in 'make test' by default -- but lately it seems people are more interested in taking tests out of 'make test' than putting them in. ;-) The point is that if we make certain tests non-default, then the Parrot developers who are working on the files which those tests cover must run the tests prior to commit.) [snip] The problem appears to be that at some point explicit return statements were added here, presumably to help follow that perl critic policy. However, they are bare returns, and are not taking advantage of the implicit return value that was originally present. (e.g. in sort_ops in Parrot/Ops2pm/Utils.pm). IIRC, in the spring of 2007 my fellow Cage Cleaner went down this precise road, possibly with this very module. I.e., he added bare returns to subs that had quite well-defined final statements. And he got the same kind of test failures as we have here. But when I refactored tools/build/ops2c.pl into lib/Parrot/Ops2c/Utils.pm earlier that year, it was for the purpose of refactoring spaghetti code without changing its functionality or calling into questions the design decisions that, for better or worse, went in to it. So that meant that, yes, the final statement in =1 sub was (a) a statement that changed the internal state of some variable and (b) had a return value that, while defined, was not very meaningful. (Defined, but not very meaningful -- Does that describe the lives of anyone you know?) So if you really think lib/Parrot/Ops2c/Utils.pm could be better designed while achieving the same functionality, have a go at it! But just remember to run the buildtools_tests as you redesign it. (And run all the buildtools tests, because Parrot::Ops2pm::Utils depends on Parrot::Ops2c::Utils.) Thank you very much. kid51
[perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed Jul 16 18:53:05 2008, [EMAIL PROTECTED] wrote: So if you really think lib/Parrot/Ops2c/Utils.pm could be better designed while achieving the same functionality, have a go at it! But in the short run I would recommend simply reverting to the last prior version of the module. I suspect there was nothing in that branch that really required revisions in Parrot::Ops2c::Utils.
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed, Jul 16, 2008 at 9:53 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On Wed Jul 16 16:56:20 2008, coke wrote: I suspect that the merger/committer failed either to run 'perl Configure.pl --test' or 'make buildtools_tests' prior to 'make'. I can't remember the last time I ran these particular test targets, so that's easy (for me) to forgive. (Well, I *could* have written these tests such that they would be included in 'make test' by default -- but lately it seems people are more interested in taking tests out of 'make test' than putting them in. ;-) The point is that if we make certain tests non-default, then the Parrot developers who are working on the files which those tests cover must run the tests prior to commit.) [snip] The problem appears to be that at some point explicit return statements were added here, presumably to help follow that perl critic policy. However, they are bare returns, and are not taking advantage of the implicit return value that was originally present. (e.g. in sort_ops in Parrot/Ops2pm/Utils.pm). IIRC, in the spring of 2007 my fellow Cage Cleaner went down this precise road, possibly with this very module. I.e., he added bare returns to subs that had quite well-defined final statements. And he got the same kind of test failures as we have here. But when I refactored tools/build/ops2c.pl into lib/Parrot/Ops2c/Utils.pm earlier that year, it was for the purpose of refactoring spaghetti code without changing its functionality or calling into questions the design decisions that, for better or worse, went in to it. So that meant that, yes, the final statement in =1 sub was (a) a statement that changed the internal state of some variable and (b) had a return value that, while defined, was not very meaningful. (Defined, but not very meaningful -- Does that describe the lives of anyone you know?) So if you really think lib/Parrot/Ops2c/Utils.pm could be better designed while achieving the same functionality, have a go at it! But just remember to run the buildtools_tests as you redesign it. (And run all the buildtools tests, because Parrot::Ops2pm::Utils depends on Parrot::Ops2c::Utils.) Thank you very much. kid51 Attached is a patch which passes all tests by removing the tests for the explicit true value of these methods. -- Will Coke Coleda untest.patch Description: Binary data
[perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed Jul 16 19:25:46 2008, coke wrote: Attached is a patch which passes all tests by removing the tests for the explicit true value of these methods. Coke: I don't think we should accept this patch, for the simple reason that I think the changes made to lib/Parrot/Ops2c/Utils.pm were both incorrect and unnecessary. This patch presumes the correctness of those changes; I dispute that. In any event, I think we should hear from Barney before proceeding. Thank you very much. kid51
[perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
This module is written in Perl 5 and is called in a program written in Perl 5. In the work I've done in this project, I've taken the approach to return values which I think is more Perlish, namely, if a subroutine completes and does what you wanted it to, it should return a true value. A bare return returns an undef, which in Perl is false. False values (whether empty string, empty list, 0 or undef) should indicate some unsatisfactory completion of the subroutine. Having these subs end in a bare return to me connotes an unsatisfactory outcome of some sort. That's why I did not have them end in bare returns, and it's why I object to the changes that were made yesterday. Thank you very much. kid51
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT [EMAIL PROTECTED] wrote: This module is written in Perl 5 and is called in a program written in Perl 5. In the work I've done in this project, I've taken the approach to return values which I think is more Perlish, namely, if a subroutine completes and does what you wanted it to, it should return a true value. A bare return returns an undef, which in Perl is false. False values (whether empty string, empty list, 0 or undef) should indicate some unsatisfactory completion of the subroutine. Having these subs end in a bare return to me connotes an unsatisfactory outcome of some sort. That's why I did not have them end in bare returns, and it's why I object to the changes that were made yesterday. Not every function has a true/false return value. These methods that were refactored from the original script are only invoked once, and are just there to encapsulate code. They are not expected to return a true -or- false value. The one place they are invoked outside of the test suite treats them as a void return value and doesn't save the return value, let alone have a conditional based on it. Since there's no 'void' return in perl, undef is about as close as you can get. I'm done, and I didn't die. That said, we can agree to disagree on that point for now, and leave the tests unchanged for the moment... ... because we can change the bare 'return;'s to 'return 1;' for now. That avoids the implicit return value that we were unintentionally getting, and will get us one step closer to passing the perlcritic policy [Subroutines::RequireFinalReturn]. Thank you very much. kid51 -- Will Coke Coleda
Re: [perl #57026] [BUG]: Changes to Parrot::Ops2c::Utils in remove_getfd branch cause failures in buildtools_tests
On Wednesday 16 July 2008 19:54:57 James Keenan via RT wrote: This module is written in Perl 5 and is called in a program written in Perl 5. In the work I've done in this project, I've taken the approach to return values which I think is more Perlish, namely, if a subroutine completes and does what you wanted it to, it should return a true value. I don't consider that particularly Perlish; I prefer to throw exceptions on failure instead of adding an Everything's Okay! alarm to my code. Yet I only bring this up because it's not a practice I've seen consistently applied throughout our Perl 5 code. If it's a practice that enough committers want apply to our code, that's fine and I have no strong preference either way -- but it's news to me. A bare return returns an undef, which in Perl is false. That's not exactly true. Sometimes it returns an empty list. Having these subs end in a bare return to me connotes an unsatisfactory outcome of some sort. Me too, but for a different reason -- it's vestigial magical useless copy-and-paste non-functional code added to satisfy a poorly implemented Perl::Critic policy. We should be removing code that doesn't do anything useful instead of adding more of it. -- c
Re: encoding vs charset
Moritz Lenz wrote: 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. Yes, we can never assume Unicode as the character set, or restrict Parrot to only handling the Unicode character set. 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. The thing is, there's a tendency for data for a particular program or application to all be from the same character set (if, for example, you're parsing a series of files, munging the data in some way, and writing out a series of files as a result). We never want to force all data to be transformed into one canonical character set, because it significantly increases the cost of working in data from different character sets, and the chances of corrupting that data in the process. If someone is reading, modifying, and writing EBCDIC files, they shouldn't have to translate their data to an intermediate format and back again. Allison
