Re: Parrot 0.5.2 Released
Bob Rogers wrote: On behalf of the Parrot team, I'm proud to announce Parrot 0.5.2 P.e. nipalensis. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. The Windows setup is available on http://parrotwin32.sourceforge.net/ with a perl6.exe for the first time. François. Parrot 0.5.2 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.2 Highlights: * make perl6 uses the new pbc_to_exe tool to build a Perl 6 executable. It's still a ways from being a finished implementation of Perl 6, but we're working on that. Come join us! * Parrot now has a LOLCODE implementation! Not an enterprise-class computing language, you say? We don't expect anyone to use it for their next app, but at less than 500 lines of source code (and most of that in a subset of Perl 6), it demonstrates the power of the Parrot Compiler Toolkit. See http://lolcode.com/news/i-haz-a-parrot for more. Parrot 0.5.2 News: - Documentation + PDD27 (multiple dispatch) - debut of new design + Numerous small updates to glossary.pod, etc - Compiler Toolkit + NQP: optional, named, and named/required parameters + PIRC: cleanups + PAST: defined-or - Languages + New mk_language_shell.pl script creates language stubs + LOLCODE: new + Lua: various + Eclectus: start with support for local variables and procedures, use SXML as intermediate representation + Perl 6: list builtins, compiler directives, command-line options, etc. + make perl6 now builds a Perl 6 executable + punie: more builtins, control structures, code refactoring + pynie: builtin stubs, more tests - Implementation + New pbc_to_exe utility turns bytecode to executables + New set_outer method for subs + Further configuration refactoring for testability + All functions now completely headerized + Concurrency: interpreter schedulers - Deprecations + DYNSELF (changes to SELF; SELF to STATICSELF) + METHOD (replaced by renaming PCCMETHOD) + pmcinfo op (superseded by 'inspect') + get_attr, set_attr, and 8 other vtable methods + See DEPRECATED.pod for details - Miscellaneous + Many bug fixes + Minor speed enhancements with UTF-8 string handling + Debian packaging + consting, attribute marking, warnings cleanup, memory leaks plugged ... The next scheduled Parrot release will be five weeks from today, on 19 February 2008. Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
[perl #49828] [PATCH] Configure hanging on GNU m4 test under FreeBSD
# New Ticket Created by Bruno
# Please include the string: [perl #49828]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49828
---
osname= freebsd
osvers= 5.5-release-p11
arch= i386-freebsd-64int
cc= cc
---
Flags:
category=install
severity=medium
ack=no
---
Hello
I found parrot installer still hanging under FreeBSD (at least FreeBSD 5.5).
Its's probably because OS name isn't properly separated.
I found this change useful:
--- config/auto/m4.pm.bak Wed Jan 16 11:57:13 2008
+++ config/auto/m4.pm Wed Jan 16 11:57:30 2008
@@ -39,7 +39,7 @@
print \n if $verbose;
my $archname = $conf-data-get_p5('archname');
-my ( $cpuarch, $osname ) = split m/-/, $archname, 2;
+my ( $cpuarch, $osname ) = split m/-/, $archname, 3;
if ( !defined $osname ) {
( $osname, $cpuarch ) = ( $cpuarch, );
}
This was enough and the test was passed.
Regards, Bruno
---
Summary of my parrot 0.5.2 (r24906) configuration:
configdate='Wed Jan 16 10:58:04 2008 GMT'
Platform:
osname=freebsd, archname=i386-freebsd-64int
jitcapable=1, jitarchname=i386-freebsd,
jitosname=FREEBSD, jitcpuarch=i386
execcapable=1
perl=perl
Compiler:
cc='cc', ccflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN
-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -I/usr/local/include
-DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT
-DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-falign-functions=16 -mno-accumulate-outgoing-args -W -Wall
-Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdisabled-optimization
-Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit
-Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-endif-labels -Wno-shadow -Wno-unused -Wnonnull
-Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point
-Wsign-compare -Wstrict-aliasing -Wswitch -Wswitch-default -Wtrigraphs
-Wundef -Wunknown-pragmas -Wwrite-strings',
Linker and Libraries:
ld='cc', ldflags=' -Wl,-E -L/usr/local/lib',
cc_ldflags='',
libs='-lm -lcrypt -lutil -pthread -lreadline'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib'
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:
HOME =/home/bruno
LANG =pl_PL.ISO8859-2
LANGUAGE (unset)
LC_ALL =pl_PL.ISO8859-2
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH
=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/bruno/bin
SHELL =/bin/tcsh
[perl #49276] [BUG] http://smoke.parrotcode.org/smoke/ failing to display submitted smoke report
While the fix to my particular problem is simple enough, it is apparent that there's enough bit rot in tools/util/smokeserv-server.pl that it needs a refactoring. And since there are no unit/regression tests for this program, it's going to need a good phalanxing. Accordingly, I have created a 'smoke' branch in our repository as a location for doing this work. And I will be changing the name of this ticket. The assistance of anyone who has experience placing CGI programs on servers would be helpful. Among the things that we will probably need is a security audit of the program. Thank you very much. kid51
[perl #49828] [PATCH] Configure hanging on GNU m4 test under FreeBSD
Hi Bruno, I found parrot installer still hanging under FreeBSD (at least FreeBSD 5.5). Its's probably because OS name isn't properly separated. Could you test the patch from ticket 49780, http://rt.perl.org/rt3/Ticket/Display.html?id=49780 ? That patch looks like a more general solution. Best regards, Bernhard -- /* [EMAIL PROTECTED] */
Re: [perl #49828] [PATCH] Configure hanging on GNU m4 test under FreeBSD
Hello 2008/1/16, Bernhard Schmalhofer via RT [EMAIL PROTECTED]: Could you test the patch from ticket 49780, http://rt.perl.org/rt3/Ticket/Display.html?id=49780 ? That patch looks like a more general solution. I've testes it and works perfectly, thanks. Later I'll check it also against FreeBSD 7.0-RC1. Regards, Bruno
[perl #49832] Error making parrot-0.5.2 in MacosX
# New Ticket Created by Paco Linux
# Please include the string: [perl #49832]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49832
Hi:
I had this error with the 0.5.2 release and the latest snapshot (this is my
first bug report:) :
cc -I./include -g -pipe -pipe -fno-common -no-cpp-precomp
-I/usr/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
-DHASATTRIBUTE_UNUSED -falign-functions=16 -W -Wall -Waggregate-return
-Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment
-Wdisabled-optimization -Wformat-nonliteral -Wformat-security -Wformat-y2k
-Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winline
-Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type
-Wsequence-point -Wsign-compare -Wstrict-aliasing -Wswitch -Wswitch-default
-Wtrigraphs -Wundef -Wunknown-pragmas -Wwrite-strings -I/sw/include
-I/sw/include -I/sw/include -g -Wno-shadow -DHAS_JIT -DPPC
-DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;' docs
perl -MExtUtils::Command -e mkpath ops
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;' src/dynpmc
Cannot restore overloading on HASH(0x187fb74) (package
Parrot::Pmc2c::Emitter) at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_retrieve.al) line 323, at
/Users/paco/parrot/parrot/tools/build/dynpmc.pl line 199
make[1]: *** [all] Error 255
make: *** [dynpmc.dummy] Error 2
mini:~/parrot/parrot paco$ perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
Copyright 1987-2003, Larry Wall
Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
mini:~/parrot/parrot paco$ uname -a
Darwin mini.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST
2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc
mini:~/parrot/parrot paco$
mini:~/parrot/parrot paco$ gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Paco
[perl #49836] [BUG] segfault in ascii_compare
binWCYT2DxKuM.bin Description:
[perl #49780] [config] m4 doesn't hang, it does its job...
Barney: auto::m4 is one of a small number of 'auto' config step classes for which I have *not* yet written any unit tests in t/steps/. So feel free to apply your combination of Simon's and your patches whenever you've resolved the issues that Bruno raised on list. You're guaranteed to have all current tests passing ;=) Of course, if anyone would like to contribute some tests for this step class, be my guest! kid51
Re: [perl #49836] [BUG] segfault in ascii_compare
On Wednesday 16 January 2008 07:03:02 Will Coleda wrote: Here's (a new, I think) segfault that partcl exposes (r24918) build tcl. %../../parrot tcl.pbc t/cmd_after.t t/cmd_after.t Segmentation fault FYI, this command line isn't expected to do anything useful at the moment; I'm only expecting a single file name. Does it happen after a realclean of Parrot? What's the backtrace look like with the GC debug runcore? -- c
Re: [perl #49836] [BUG] segfault in ascii_compare
On Jan 16, 2008 1:45 PM, chromatic via RT [EMAIL PROTECTED] wrote: On Wednesday 16 January 2008 07:03:02 Will Coleda wrote: Here's (a new, I think) segfault that partcl exposes (r24918) build tcl. %../../parrot tcl.pbc t/cmd_after.t t/cmd_after.t Segmentation fault FYI, this command line isn't expected to do anything useful at the moment; I'm only expecting a single file name. Does it happen after a realclean of Parrot? Yes. What's the backtrace look like with the GC debug runcore? Very similar: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x000728f8 0x01128430 in ascii_compare (interp=0x29003e0, lhs=0x28ad1e4, rhs=0x28b0e5c) at src/charset/ascii.c:477 477 const int ret_val = memcmp(lhs-strstart, rhs-strstart, min_len); (gdb) bt #0 0x01128430 in ascii_compare (interp=0x29003e0, lhs=0x28ad1e4, rhs=0x28b0e5c) at src/charset/ascii.c:477 #1 0x0100b40a in string_equal (interp=0x29003e0, s1=0x28ad1e4, s2=0x28b0e5c) at src/string.c:1432 #2 0x01079f89 in STRING_compare (interp=0x29003e0, search_key=0x28ad1e4, bucket_key=0x28b0e5c) at src/hash.c:157 #3 0x0107acdb in parrot_hash_get_bucket (interp=0x29003e0, hash=0x2911060, key=0x28ad1e4) at src/hash.c:977 #4 0x0117b77a in Parrot_Hash_exists_keyed_str (interp=0x29003e0, pmc=0x287aca8, key=0x28ad1e4) at ./src/pmc/hash.pmc:887 #5 0x0106b881 in is_loaded (interp=0x29003e0, path=0x28ad1e4) at src/dynext.c:169 #6 0x0106c294 in Parrot_load_lib (interp=0x29003e0, lib=0x2e7ca18, initializer_unused=0x0) at src/dynext.c:551 #7 0x011da6bf in do_loadlib (interp=0x29003e0, lib=0x2960db0 'tcl_ops') at compilers/imcc/imcc.y:822 #8 0x011dbb0a in yyparse (yyscanner=0x2997330, interp=0x29003e0) at compilers/imcc/imcc.y:637 #9 0x011e67bb in compile_string (interp=0x29003e0, s=0x307c000 .HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/src/returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\nsp..., yyscanner=0x2997330) at compilers/imcc/imcc.l:1182 #10 0x011f996e in imcc_compile (interp=0x29003e0, s=0x307c000 .HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/src/returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\nsp..., pasm_file=0, error_message=0xbfffee68) at compilers/imcc/parser_util.c:839 #11 0x011f9bf7 in imcc_compile_pir_ex (interp=0x29003e0, s=0x307c000 .HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/src/returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\nsp...) at compilers/imcc/parser_util.c:1018 #12 0x01091fca in pcf_P_Jt (interp=0x29003e0, self=0x287a4e0) at src/nci.c:2645 #13 0x0115533c in Parrot_NCI_invoke (interp=0x29003e0, pmc=0x287a4e0, next=0x2b166d8) at ./src/pmc/nci.pmc:206 #14 0x01141b17 in Parrot_Compiler_invoke (interp=0x29003e0, pmc=0x287a4e0, code_ptr=0x2b166d8) at ./src/pmc/compiler.pmc:38 #15 0x0100df13 in Parrot_invokecc_p (cur_opcode=0x2b166d0, interp=0x29003e0) at src/ops/core.ops:432 #16 0x010b1b55 in runops_gc_debug_core (interp=0x29003e0, pc=0x2b166d0) at src/runops_cores.c:241 #17 0x01082ce8 in runops_int (interp=0x29003e0, offset=3) at src/interpreter.c:877 #18 0x0108376d in runops (interp=0x29003e0, offs=3) at src/inter_run.c:104 #19 0x010839a8 in runops_args (interp=0x29003e0, sub=0x2871260, obj=0x302ec48, meth_unused=0x0, sig=0x120befc vP, ap=0xb11c à\020\002ÿÿÿ) at src/inter_run.c:230 #20 0x01083ab4 in Parrot_runops_fromc_args (interp=0x29003e0, sub=0x2871260, sig=0x120befc vP) at src/inter_run.c:299 #21 0x0106d49e in Parrot_runcode (interp=0x29003e0, argc=3, argv=0xb274) at src/embed.c:886 #22 0x011e86fb in imcc_run_pbc (interp=0x29003e0, obj_file=0, output_file=0x0, argc=3, argv=0xb274) at compilers/imcc/main.c:792 #23 0x011e90b0 in imcc_run (interp=0x29003e0, sourcefile=0xb33e tcl.pbc, argc=3, argv=0xb274) at compilers/imcc/main.c:1075 #24 0x2497 in main (argc=3, argv=0xb274) at src/main.c:62
[perl #49802] [TODO] tclsh binary segfaults.
bineZDhpov4CW.bin Description:
[perl #49846] [PATCH] test_more.pir does not export skip()
# New Ticket Created by Mark Grimes # Please include the string: [perl #49846] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49846 It appears that runtime/parrot/include/test_more.pir does not export 'skip'. I'm not sure if this was done on purpose, but I have not seen any issues when running tests with it exported. The attached (simple) patch fixes it. -Mark mgrimes (at) cpan [dot] org Index: runtime/parrot/include/test_more.pir === --- runtime/parrot/include/test_more.pir(revision 24854) +++ runtime/parrot/include/test_more.pir(working copy) @@ -17,7 +17,7 @@ .local pmc exports, curr_namespace, test_namespace curr_namespace = get_namespace test_namespace = get_namespace [ 'Test'; 'More' ] -exports = split , plan diag ok is is_deeply like isa_ok +exports = split , plan diag ok is is_deeply like isa_ok skip test_namespace.export_to(curr_namespace, exports)
Re: [perl #49846] [PATCH] test_more.pir does not export skip()
On Wednesday 16 January 2008 08:49:43 Mark Grimes wrote: It appears that runtime/parrot/include/test_more.pir does not export 'skip'. I'm not sure if this was done on purpose, but I have not seen any issues when running tests with it exported. The attached (simple) patch fixes it. Thanks, applied as r24921. -- c
[perl #43335] [TODO] config/auto/revision.pm: Write unit tests
I overlooked resolving this 2-1/2 months ago. It was effectively dealt with in: r22702 | jkeenan | 2007-11-04 11:09:27 -0500 (Sun, 04 Nov 2007) | 3 lines
Extending Parrot NCI callback functionality
Right now, Parrot's support for NCI callbacks (C code calling back into PIR code) is relatively limited. In particular, there are at least the following limitations: 1. The return type must be void (C library does not expect a response). 2. The callback must have exactly two arguments (from both the C and PIR perspectives). 3. One of these arguments must be a user data pointer, provided by the PIR code when it registers the callback with the C library, and handed back by the C code to the PIR code during every callback. 4. The C code must treat the user data pointer as entirely opaque (no modification or assumed structure). 5. The other argument's type can vary, but is much more limited than an arbitrary (normal) NCI argument. I am starting to implement a GLUT and OpenGL binding for Parrot. GLUT is extremely callback-oriented. You essentially can't do anything beyond open the top-level window until callbacks are functional. You can't even draw in that window -- the rendered image never actually appears, and in fact the window itself is simply transparent with just the chrome showing. Unfortunately, none of the GLUT callbacks fall within the current limitations on Parrot NCI callbacks. I was thus beginning to look at improving the Parrot NCI code accordingly, but soon realized I didn't know how to get around some pretty fundamental problems (at least, not in pure C code). It turns out there's a good reason that limitations #3 and #4 exist. What actually gets registered with the external C library is a pointer to a C function in src/inter_cb.c. This function calls a chain of other functions. First, they check that the user data argument has not been obviously corrupted, and that the interpreter state is still sane. Next, they pull the Sub PMC and signature for the PIR function that should be called *from properties of the user data argument*. A little more sanity checking and a switch statement later, and this PIR Sub is called using Parrot_runops_fromc_args_event(). And therein lies the problem. The callback entry point is compiled C code. There could be dozens of callbacks registered by the PIR code, but only *one* set of C functions that handles all of them. In order to have a single compiled Parrot function that brokers all these different callbacks from C to PIR, Parrot cheats. Parrot adds several properties to the user data parameter before handing it off to the C library, and when the C library calls back, Parrot reads these properties to figure out which PIR function should get called. But this cheat doesn't work if the C library's callbacks don't all support a completely opaque user data parameter. And guess what? Not a single one of the GLUT callbacks is of this form. In fact, several of the most important GLUT callbacks have *no parameters at all*, and all of the callback parameters have defined meanings on the C side. So ... how can Parrot support callbacks of the types that GLUT uses? The trick of putting magical properties on a special user data parameter won't work anymore. I've been tanking on this for a while, and come up with several possible schemes. My first idea was that each time a new callback was registered, Parrot would copy a tiny shim function and then poke the address(es) of the data it needed to figure out what PIR routine to call directly into the copied shim code. The shim copy could then be handed off to the C library callback registration. When a callback came, the shim copy would then magically call the right PIR function, since it had all the information it needed hardcoded. A variant of this involved having a global registry of callbacks, so that instead of poking a pile of data into the copied shim, Parrot would simply need to poke in the callback number (one integer). When the callback came in, the shim copy would then use this single integer to look up the info it needed in the global registry. But I don't know how to portably do either kind of compiled code poking in pure C. (Not that I know it can't be done -- I just personally don't know how.) So my next idea was to have a shim function that did nothing but call another function, thus putting its own address on the stack. The other function would then reach up above its own stack frame and grab that return address, using *that address* to look up the needed information in a global callback registry. By making copies of this simple shim every time a new callback was registered, each copy would get its own address, and everything would magically work. This was certainly better than the previous ideas, because it didn't involve poking anything into the shim code, just being able to copy it. But I still don't know how to do that in pure portable C. My guess is that you could declare another function (which need not do anything) in some special way so that it is guaranteed to be compiled into the object code directly after the magic shim. Subtracting the address of
Rakudo.org is up live
http://www.rakudo.org/ Right now it's just a blog, but we can add more more more. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
